This figure shows an example of a job that uses multiple commitment definitions.
It indicates which file updates are committed or rolled back at each activation group level. The example assumes that all of the updates that are made to the database files by all of the programs are made under commitment control.
The following table shows how files are committed or rolled back if the scenario in the previous figure changes.
Additional examples of multiple commitment definitions in a job
| Change in scenario | Effect on changes to these files: | |||
|---|---|---|---|---|
| F1 and F2 | F3 and F4 | F5 and F6 | F7 | |
| PGMX performs a rollback operation instead of a commit operation (3= =COMMIT becomes ROLLBACK). | Still pending | Rolled back | Already committed | Rolled back |
| PGMZ performs a commit operation before returning to PGMX. | Still pending | Committed by PGMZ | Already committed | Committed |
| PGMZ attempts to start commitment control specifying CMTSCOPE(*ACTGRP) after updating file F7. The attempt fails because changes are pending using the job-level commitment definition. | Still pending | Still pending | Already committed | Still pending |
| PGMX does not start commitment control and does not open files F3 and F4 with COMMIT(*YES). PGMZ attempts to open file F7 with COMMIT(*YES). | Still pending | Not under commitment control | Already committed | File F7 cannot be opened because no *JOB commitment definition exists (PGMX did not create it). |