Commitment control for batch applications

 

Batch applications might or might not need commitment control. In some cases, a batch application can perform a single function of reading an input file and updating a master file. However, you can use commitment control for this type of application if it is important to start it again after an abnormal end.

The input file is an update file with a code in the records to indicate that a record was processed. This file and any files updated are placed under commitment control. When the code is present in the input file, it represents a completed transaction. The program reads through the input file and bypasses any records with the completed code. This allows the same program logic to be used for normal and starting-again conditions.

If the batch application contains input records dependent on one another and contains switches or totals, a notify object can be used to provide information about starting again. The values held in the notify object are used to start processing again from the last committed transaction within the input file.

If input records are dependent on one another, they can be processed as a transaction. A batch job can lock a maximum of 500 000 000 records. You can reduce this limit by using a Query Options File (QAQQINI). Use the QRYOPTLIB parameter of the Change Query Attributes (CHGQRYA) command to specify a Query Options File for a job to use. Use the COMMITMENT_CONTROL_LOCK_LEVEL value in the Query Options File as the lock limit for the job.

Any commit cycle that exceeds 2000 locks probably slows down system performance noticeably. Otherwise, the same locking considerations exist as for interactive applications, but the length of time records are locked in a batch application might be less important than in interactive applications.

 

Parent topic:

Commitment control concepts

 

Related concepts

Commit notify object
Managing transaction size

 

Related reference

Change Query Attributes (CHGQRYA) command