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. The lock limit value is cached internally for each commitment definition the first time a journaled resource is placed under commitment control. If the lock limit is changed after that point, the cached value must be refreshed for it to become effective for that commitment definition. Any call to the Retrieve Commit Information (QTNRCMTI) API refreshes the cached value in the calling job. The new value will not apply to transactions that started before the cache is refreshed.

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.