As online days get longer and batch windows shrink it becomes harder to run traditional VSAM-based CICS systems. There are several vendors with software that allow batch programs to access files open on CICS. Those inclined to roll their own solutions can use CICS' External Call Interface (EXCI) to do the same thing. For others, I propose the low tech solution of running CICS in batch.
Why run CICS in batch?
The primary knock against batch file sharing software is cost. Not only is there the original purchase price, but maintenance as well. I also know of some enterprises that got burned when the original vendor was bought out by another that promptly jacked up the price.
EXCI gets around the cost issue but has some "opportunities" of its own. Primarily, the application programmers must learn how to code to the EXCI application programming interface (API). This is easy enough using the EXEC interface that looks like a CICS LINK command, but bulk, high-performance work requires the call interface, which is a little trickier to manage.
Both solutions also present problems for their target regions, as they operate by turning batch I/O into CICS transactions. If not carefully planned, the batch-originated transactions may interfere with online processing by creating short-on-storage (SOS) and max task (MXT) conditions.
Running CICS in a batch job avoids many of these problems. The batch CICS is self-contained and any MXT or SOS problems will be isolated from online activity. The batch work runs in CICS so programmers can use a familiar API. While this works best for Record Level Sharing (RLS) datasets, it will support non-shared files as well. The systems programmer just has to define the files remotely from the batch CICS to the online regions along with the required connection.
How to run CICS in batch
The idea itself is rather simple: Provide a job control language (JCL) procedure or PROC the application programmers can use to ...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
start a CICS instance. The JCL should be able to be inserted into any step in a job and include lots of symbolic parameters. A clear set of standards for using the PROC would help everyone understand how it should be used. The batch region will most likely need its own resource definition online (RDO) groups and lists as well as tables. In some cases an isolated CICS System Definition (CSD) file might be warranted. System Initialization Tables (SIT) parameters must be tailored to the batch environment.
Probably the biggest decision about using a batch CICS region involves restart. If the batch regions are to be INITIAL started each time they can use temporary CICS system datasets to be thrown away at the end of a job, although there should be a provision to print the auxiliary trace and dump datasets lest something bad happens. Without restart you can also get away without defining a system or shunt log stream. If you require restart then you may allocate a pool of datasets and log streams on an application or job basis.
Recovery presents other issues. The presence or absence of a CICS log doesn't change the recovery attributes of RLS datasets and DB2 so a non-restartable CICS may leave in-doubt units of work in other resource managers. If you choose to support recovery, the rules will have to be carefully observed when the batch job runs.
You must also consider security. CICS will run in the batch job's context. Therefore, if CICS security is turned on, the job's ID must be authorized to use all the resources defined to it as well as system logon IDs (e.g., DFTCICS). It may be tempting to run the batch CICS without security, but then you must ensure that no one can log on.
Batch CICS and the Application
Finally, we come to the actual application. Ideally there will be one driving transaction, although more could execute to facilitate parallelism. The driver might read its input from a sequential file defined as an extrapartition transient data queue or VSAM file. It should be careful to take periodic syncpoints and record its progress with CICS log messages. Checkpointing on another dataset may be useful for restart. Also note that all of CICS' facilities are available if needed.
CICS can start the application through a Program List Table Program Initialization (PLTPI) program or with a sequential terminal. You may remember a sequential terminal is a special type of Terminal Control Table (TCT) device where CICS reads the input from a flat file instead of the network.
You have a couple of options for shutting down the batch CICS. The key is not shutting down early, as CICS will eventually kill any application tasks, whether they're through or not. The shutdown command may be issued from the driver transaction or perhaps a monitoring task that waits for the work to complete. Also remember that standard job step condition code checking won't work because CICS usually issues a zero return code. Therefore, the CICS piece of the application will need a technique to pass errors down the line.
Are you nuts?
Technically, no. We've been doing this for some time for one of our applications and have recently adapted it to other purposes to beat the batch window. I offer it as a low-tech solution that can be implemented quickly and cheaply for a pressing problem.
Happy holidays to everyone.
ABOUT THE AUTHOR:
[IMAGE]For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2..
