Items to include in a batch DL/I program

When you use a batch DL/I program with Db2, you must include certain items in your program.

A batch DL/I program can issue:

  • Any IMS batch call, except ROLS, SETS, and SYNC calls. ROLS and SETS calls provide intermediate backout point processing, which Db2 does not support. The SYNC call provides commit point processing without identifying the commit point with a value. IMS does not allow a SYNC call in batch, and neither does the Db2 DL/I batch support.

    Issuing a ROLS, SETS, or SYNC call in an application program causes a system abend X'04E' with the reason code X'00D44057' in register 15.

  • GSAM calls.
  • IMS system services calls.
  • Any SQL statements, except COMMIT and ROLLBACK. IMS and CICS® environments do not allow those SQL statements; however, IMS and CICS do allow ROLLBACK TO SAVEPOINT. You can use the IMS CHKP call to commit data and the IMS ROLL or ROLB to roll back changes.

    Issuing a COMMIT statement causes SQLCODE -925; issuing a ROLLBACK statement causes SQLCODE -926. Those statements also return SQLSTATE '2D521'.

  • Any call to a standard or traditional access method (for example, QSAM, VSAM, and so on).

The restart capabilities for Db2 and IMS databases, as well as for sequential data sets that are accessed through GSAM, are available through the IMS Checkpoint and Restart facility.

Db2 allows access to both Db2 and DL/I data through the use of the following Db2 and IMS facilities:

  • IMS synchronization calls, which commit and abnormally terminate units of recovery
  • The Db2 IMS attachment facility, which handles the two-phase commit protocol and enables both systems to synchronize a unit of recovery during a restart after a failure
  • The IMS log, which is used to record the instant of commit

In a data sharing environment, DL/I batch supports group attachment or subgroup attachment. You can specify a group attachment name instead of a subsystem name in the SSN parameter of the DDITV02 data set for the DL/I batch job.

Requirements for using Db2 in a DL/I batch job

Using Db2 in a DL/I batch job requires the following changes to the application program and the job step JCL:

  • Add SQL statements to your application program to gain access to Db2 data. You must then precompile the application program and bind the resulting DBRM into a package.
  • Before you run the application program, use JOBLIB, STEPLIB, or link book to access the Db2 load library, so that Db2 modules can be loaded.
  • In a data set that is specified by a DDITV02 DD statement, specify the program name and plan name for the application, and the connection name for the DL/I batch job.

    In an input data set or in a subsystem member, specify information about the connection between Db2 and IMS. The input data set name is specified with a DDITV02 DD statement. The subsystem member name is specified by the parameter SSM= on the DL/I batch invocation procedure.

  • Optionally specify an output data set using the DDOTV02 DD statement. You might need this data set to receive messages from the IMS attachment facility about indoubt threads and diagnostic information.

Program design considerations for using DL/I batch

Address spaces in DL/I batch:
A DL/I batch region is independent of both the IMS control region and the CICS address space. The DL/I batch region loads the DL/I code into the application region along with the application program.
Commits in DL/I batch:
Commit IMS batch applications frequently so that you do not use resources for an extended time.
SQL statements and IMS calls in DL/I batch:
DL/I batch applications cannot use the SQL COMMIT and ROLLBACK statements; otherwise, you get an SQL error code. DLI/I batch applications also cannot use ROLS, SETS, and SYNC calls; otherwise the application program abnormally terminates.
Checkpoint calls in DL/I batch:
Write your program with SQL statements and DL/I calls, and use checkpoint calls. The frequency of checkpoints depends on the application design. All checkpoints that are issued by a batch application program must be unique. At a checkpoint, DL/I positioning is lost, Db2 cursors are closed (with the possible exception of cursors that are defined as WITH HOLD), commit duration locks are freed (again with some exceptions), and database changes are considered permanent to both IMS and Db2.
Application program synchronization in DL/I batch:
You can design an application program without using IMS checkpoints. In that case, if the program abnormally terminates before completing, Db2 backs out any updates, and you can use the IMS batch backout utility to back out the DL/I changes.

You can also have IMS dynamically back out the updates within the same job. You must specify the BKO parameter as 'Y' and allocate the IMS log to DASD.

You could have a problem if the system on which the job is run fails after the program terminates but before the job step ends. If you do not have a checkpoint call before the program ends, Db2 commits the unit of work without involving IMS. If the system fails before DL/I commits the data, the Db2 data is out of synchronization with the DL/I changes. If the system fails during Db2 commit processing, the Db2 data could be indoubt. When you restart the application program, use the XRST call to obtain checkpoint information and resolve any Db2 indoubt work units.

Recommendation: Always issue a symbolic checkpoint at the end of any update job to coordinate the commit of the outstanding unit of work for IMS and Db2.
Checkpoint and XRST considerations in DL/I batch:
If you use an XRST call, Db2 assumes that any checkpoint that is issued is a symbolic checkpoint. The options of the symbolic checkpoint call differ from the options of a basic checkpoint call. Using the incorrect form of the checkpoint call can cause problems.

If you do not use an XRST call, Db2 assumes that any checkpoint call that is issued is a basic checkpoint.

To make restart easier, use EBCDIC characters for checkpoint IDs.

When an application program needs to be restartable, you must use symbolic checkpoint and XRST calls. If you use an XRST call, it must be the first IMS call that is issued, and it must occur before any SQL statement. Also, you must use only one XRST call.

Synchronization call abends in DL/I batch:
If the application program contains an incorrect IMS synchronization call (CHKP, ROLB, ROLL, or XRST), causing IMS to issue a bad status code in the PCB, Db2 abends the application program. Be sure to test these calls before placing the programs in production.