DB batch processing

Data that a DB batch program can access

A DB batch program can access full-function databases, Db2 for z/OS® databases, GSAM databases, and z/OS files. A DB batch program cannot access DEDBs or MSDBs.

Using DB batch processing

Batch programs are typically longer-running programs than online programs. You use a batch program when you have a large number of database updates to do or a report to print. Because a batch program runs by itself—it does not compete with any other programs for resources like databases—it can run independently of the control region. If you use data sharing, DB batch programs and online programs can access full-function databases concurrently. Batch programs:

• Typically produce a large amount of output, such as reports.
• Are not executed by another program or user. They are usually scheduled at specific time intervals (for example, weekly) and are started with JCL.
• Produce output that is not needed right away. The turnaround time for batch output is not crucial, as it usually is for online programs.

Recovering a DB batch program

Include checkpoints in your batch program to restart it in case of failure.

Issue checkpoints in a batch program to commit database changes and provide places from which to restart your program. Issuing checkpoints in a batch program is important, because commit points do not occur automatically, as they do in MPPs, transaction-oriented BMPs, and IFPs.

Issuing checkpoints is particularly important in a batch program that participates in data sharing with your online system. Checkpoints free up resources for use by online programs. You should initially include checkpoints in all batch programs that you write. Even though the checkpoint support might not be needed then, it is easier to incorporate checkpoints initially than to try to fit them in later. And it is possible that you might want to convert your batch program to a BMP or participate in data sharing.

To issue checkpoints (or other system service calls), you must specify an I/O PCB for your program. To obtain an I/O PCB, use the compatibility option by specifying CMPAT=YES in the PSBGEN statement in your program's PSB.

GSAM DB's are not backed out but are repositioned during the BMP's restart process through the XRST call. The XRST call repositions the dataset pointers to the checkpoint ID specified in the call. When the application starts-up, it will pick-up from that point and go forward. The checkpoint ID specified in the XRST call should be the same one that the non-GSAM DBs would have been backed out to, through either dynamic or batch backout.

The type of storage medium for the system log determines what happens when a DB batch program terminates abnormally. You can specify that the system log be stored on either DASD (direct access storage device) or tape.

If the system log is stored on DASD, using the BKO execution parameter you can specify that IMS is to dynamically back out the changes that the program has made to the database since its last commit point.

Related Reading: For information on using the BKO execution parameter, see IMS Version 15.4 System Definition.

Dynamically backing out database changes has the following advantages:

• Data accessed by the program that failed is available to other programs immediately. If batch backout is used, other programs cannot access the data until the IMS Batch Backout utility has been run to back out the database changes.
• If data sharing is being used and two programs are deadlocked, one of the programs can continue processing. Otherwise, if batch backout is used, both programs fail.

IMS performs dynamic backout for a batch program when an IMS-detected failure occurs, for example, when a deadlock is detected. Logging to DASD makes it possible for batch programs to issue the SETS, ROLB, and ROLS system service calls. These calls cause IMS to dynamically back out changes that the program has made.

Related Reading: For information on the SETS, ROLB, and ROLS calls, see the information about recovering databases and maintaining database integrity in IMS Version 15.4 Database Administration.

If a batch application program terminates abnormally and the batch system log is stored on tape, you must use the IMS Batch Backout utility to back out the program's changes to the database.