Tip:
Highlight text to annotate it
X
The CICS TS Feature Pack for Modern Batch allows the development of Java Batch Applications
in a modern and intuitive Eclipse environment either using the CICS Explorer SDK or Rational
Application Developer. In this scenario, we'll use CICS Explorer to look at one of the supplied
sample applications, catalogue managers stock update to explore the components of a Modern
Batch application. Here we have our development workspace, in
the package Explorer view of the Java perspective we have a Java project. This contains the
various components of our Java Batch application. The build path must be configured on the project,
so we can access the necessary JARs of the application.
The Feature Pack has two required JARs: batchframework and pgcruntime. The application question requires
com.ibm.cics.batch for the use of CICS supplied data streams as well as com.ibm.cics.server
and com.ibm.record for using the JCICS API. Batch applications are broken down into one
or more job steps. To create a batch job step, we create a new Java class in the project,
implementing the batch job step interface found in the PGC runtime JAR. This interface
gives us a framework to build the application's business logic upon as shown in this class.
The Catalogue Manager Stock Update class contains our completed job step logic. Firstly, we
define some components as they are known to the application such as the input and output
streams. We use create job step to set up application resources, including the batch
data streams recently defined. We call destroy job step at the end of the job to clean up
and pass the return code to the caller, we also pass some additional logging information.
In the xJCL we can pass properties to the application, once we make these available
via the set properties method, we can use the get properties method to return the properties
to the batch job step. The business logic of the application is carried out within the
process job step method. In this application we read a record from the input file and the
record to be updated in the output file, we pass this information to a COBOL program to
perform business logic and to update the output file with a new value.
Set properties is called from the batch container to make the properties specified in the xJCL
available to the batch job step. Now that we have the application's business logic,
next component to explore is the xJCL for the application. The xJCL has elements for
expressing all of the information needed to define the batch job, which we'll look at
in more detail soon. For organizational purposes we've put this in a separate folder within
the project. At the start we have basic information, including
the application name, its job type and its scheduling mode. This is used by the job scheduler
to dispatch to an appropriate environment. Next we define the check-point algorithm,
these are used to determine how often CICS commits unit of work. Then we define the results
algorithm used to determine how return codes are handled.
Our example uses one job step, declared here. We point the Java class we just created, where
the application's business logic resides and we reference the check point algorithm above,
which we want to use. We then define our batch data streams: an input stream and an output
stream. These are Java objects, which provide a layer of abstraction for the data stream
processed by a batch step. This creates a well-defined interface, so the batch job step
can be easily changed to use a different resource type. We have the names as used by the job
step's Java class, the class for the data streams themselves and any properties required
or optional to be passed to the data stream. Finally, we declare any properties to be passed
to a job step as a whole. In this case enabling debug for additional information to be logged.
We now have our developed application; please see our next video for steps on exporting
the package application as a JAR and configuring your execution environment to enable the application
to run.