This chapter describes an IBM CICS Transaction Server (TS) modern batch scenario where a Java batch application is developed to reduce the batch window. The Java batch accesses data in VSAM or IBM DB2 without the need to stop the online transactions that access to the same data. The Java batch application may come from a new requirement or may be rewritten from existing business logic. We review the architecture and the implementation of the modern batch Java solution.

There are two approaches to using Java batch processing:

In this approach, you can leave existing batch processes as they are, but engineer new requirements in the Java batch model. If a batch application has complex algorithms and huge calculations, needs to access to the data controlled by CICS TS where the data access is either in share mode, or holds the exclusive lock or a short time, the application is a good candidate for modern batch processing.

Re-engineering is not an easy thing to do, but IBM provides tools to help Java interact with structured data. For more information, see Chapter 8 in the IBM Redbooks publication titled IBM CICS and the JVM server: Developing and Deploying Java Applications, SG24-8038:

In this section, we introduce the architecture to use modern batch processing.

Figure 11-1 on page 115 shows the architecture of how a Java batch works with CICS TS. At the front, enterprise schedulers such as IBM Tivoli Workload Scheduler can be used to schedule a batch request from z/OS JCL. The JCL is submitted to WSGRID client that is provided by WebSphere Application Server and is used to interact with Java batches and to integrate the batch system with the enterprise schedules. The WSGRID client reads the job properties from XML Job Control Language (xJCL) and then sends the request to the job scheduler in WebSphere Application Server. The job scheduler then schedules the job to endpoints (batch containers) in CICS TS.

To allow a CICS TS region to become a job endpoint for a WebSphere Java batch dispatching server, CICS TS TS Feature Pack for Modern Batch V1.0 must be installed. After a Java batch application is deployed in a CICS TS batch container, CICS TS communicates with the WebSphere Application Server dispatcher function host and port. That lets the dispatcher know that the endpoint is present and what batch application is deployed.

The batch container provides batch data streams (BDS) as a means of externalizing data access from the job step. For more information, see “Batch data streams provided by CICS” in the IBM Knowledge Center:

In addition, the CICS Feature Pack for Modern Batch provides access to the full set of JCICS APIs. For more information about JCICS services and examples, see “JCICS API services and examples” in the IBM Knowledge Center:

Now, let’s focus more on how to access to VSAM files, because VSAM is the most common data source for batch processing. CICS TS JCICS services support reading and updating a VSAM file but do not support opening or closing a file. So, if the file is not owned by the Java batch region but it owned by another CICS TS region for online transactions, you have two solutions:

This solution is shown in Figure 11-1 on page 115. Here, we route all of the file work by function shipping to a FOR running in a normal z/OS LPAR to complete the file read and update.

In this method, the Java workload is in a zNALC-enabled LPAR, and the workload for file operations is included in a normal z/OS LPAR. You do not need to care about file open and close, and the best thing is that modern batches can run concurrently with online transactions.

RLS is another solution that enables modern batch to work concurrently with online transactions and thus reduces the batch window. RLS is a VSAM data set access mode introduced in DFSMS and supported by CICS. RLS enables VSAM data to be shared, with full update capability, between many applications running in many CICS regions. With RLS, CICS regions that share VSAM data sets can reside in one or more IBM MVS™ images within an MVS sysplex.

FOR and RLS are preferred solutions for Java modern batch processing. You can select a solution based on the existing VSAM access method used by your online transactions.

To achieve the high availability, you can set up two or even more batch containers for the same batch application. The batch containers can be deployed in the same CICS region or in separate CICS regions in the same LPAR, or even in CICS regions in separate LPARs. All of the batch containers send the heartbeat information to the job scheduler at regular intervals. So, from the view of the job scheduler, all of these batch contents are candidates to run the same batch applications. After one container fails, the job scheduler cannot hear the heartbeat from that container, so all of the requests go to the live ones.

Even if you select only one batch container, CICS modern batch processing can achieve better availability than the traditional batch processing by using checkpoints. In the traditional batch, you usually store a backup copy of the master file before running the batch, restore the file after a failure, and then rerun the batch. In the modern batch, the batch container creates checkpoints. The batch application can be restarted from the last successful checkpoint in the event of a failure. This reduces the time to recover from a failure, so it improves availability.

CICS Feature Pack for Modern Batch supports SSL client authentication to secure the communication between the batch container and the job scheduler. You can turn on the security setting in the batchcontainer-config.xml file. For more information, see “Configuring the batch container” in the IBM Knowledge Center:

After the SSL handshake, the job scheduler can schedule the job to the batch containers in CICS. The batch containers use TCPIPService to listen to the requests from the job scheduler. Then, URIMAP is used to route the request to the batch applications. In the URIMPAP definition, you can define the transaction ID and the user ID to run the batch applications. The default transaction is CBCR. Make sure that the transaction is running under an ID that has enough authority to access the resource. As online transactions, the security of the resource is controlled by External Security Manager, which in most cases is IBM RACF®.

In this section, we describe basic steps to develop a Java batch application, deploy it in CICS TS, and schedule it. The IBM Redbooks publication titled New Ways of Running Batch Applications on z/OS: Volume 1 CICS Transaction Server, SG24-7991, includes more detailed information about how to use IBM Rational Application Developer to develop a Java batch application and to schedule it:

To use the CICS Feature Pack for Modern Batch, you must have the correct versions of software and service installed. Your environment must comply with the following prerequisites:

CICS TS TS Feature Pack for Modern Batch is installed by using the SMP/E RECEIVE, APPLY, and ACCEPT commands. The program number for CICS TS Feature Pack for Modern Batch is 5655-Y50, and the FMID is HCIF51B. You can use the sample jobs that are provided to perform part or all of the installation tasks, or you can use the SMP/E dialogs to perform the SMP/E installation steps.

For details about the installation procedure, see the Pubilcation Information web page for CICS Transaction Server Feature Pack for Modern Batch V1.0 Program Directory, GI13-3324:

Detailed steps are described in “Configuring the CICS Feature Pack for Modern Batch” in the IBM Knowledge Center:

You can develop applications with IBM Rational Application Developer or the CICS Explorer SDK. Rational Application Developer is a preferred IDE to develop the batch application. But if you do not have Rational Application Developer, you can use the Eclipse platform with CICS TS Explore SDK at no charge.

The two most important things that you need to develop are XML Job Control Language (xJCL) and Java class to implement the job step logic.

If you have Rational Application Developer, you can set up a batch project to easily generate xJCL and a Java class template to implement your batch job steps, using a GUI.

Figure 11-2 shows an example of the generated xJCL from Rational Application Developer. The xJCL describes how to run a batch job and defines the input and output streams to that batch job. In the xJCL, you can define batch job steps, checkpoint algorithms, results algorithms, batch data streams (BDS) and batch job return codes. For more information, see “The batch programming model” in the IBM Knowledge Center:

Figure 11-3 shows an extract of the generated Java class for the Batch Job Step. This class is where the code for the job step will be added.

After you get the generated Batch Job Step implementation class, you can add your specific business logic there. Batch steps are implemented as plain old Java object (POJO) classes that implement the interface, com.ibm.websphere.batch.BatchJobStepInterfance. Batch job steps are performed sequentially. Callback methods in the BatchJobStepInterface allow the grid endpoints to run batch steps when they run batch jobs. For more information, see “Batch job steps” in the IBM Knowledge Center:

If you do not have Rational Application Developer, you need to develop the xJCL and the job step Java classes manually. Create a Java project to, first, add additional JARs in the build path and then to write a Java class for each job step and write a xJCL file to describe how to run the job. For detailed steps, see “Developing the sample application with CICS Explorer SDK” in the IBM Knowledge Center:

First, export the application as a Java archive (JAR) file that contains the compiled Java classes. Then, follow these steps to install the application in CICS:

Before you submit the xJCL, make sure that the default application name is the same as the application name that you specified in the batchcontainer-config.xml file. Then you can submit this xJCL from any supported enterprise scheduler. For example, if you use the Job Management Console, log on to the web interface, specify the path to the xJCL on your local workstation, and then submit the xJCL to the job scheduler. Figure 11-4 shows how to submit a job from the Job Management Console.

A message confirms that the job has been submitted successfully and provides the job ID. When a job is successfully submitted, the job scheduler has identified at least one batch container that claims to be able to run the job. The scheduler chooses a batch container and dispatches the job to it.

You can examine the log for the job to see which batch container the scheduler has chosen to dispatch the job to. Figure 11-5 shows a job log from the Job Management Console.

These steps show how to develop a batch application, to deploy it and to schedule it, see the detailed steps in the IBM Redbooks publication titled New Ways of Running Batch Applications on z/OS: Volume 1 CICS Transaction Server, SG24-7991: