Commitment definition names
The system gives names to all commitment definitions that are started for a job.
The following table shows various commitment definitions and their associated names for a particular job.
| Activation group | Commit scope | Commitment definition name |
|---|---|---|
| Any | Job | *JOB |
| Default activation group | Activation group | *DFTACTGRP |
| User-named activation group | Activation group | Activation group name (for example, PAYROLL) |
| System-named activation group | Activation group | Activation group number (for example, 0000000145) |
| None | Explicitly named | QDIR001 (example of a system-defined commitment definition for system
use only). System-defined commitment definition names begin with Q. |
| None | Transaction | *TNSOBJ |
Only IBM® Integrated Language Environment® (ILE) compiled programs can start commitment control for activation groups other than the default activation group. Therefore, a job can use multiple commitment definitions only if the job is running one or more ILE compiled programs.
Original Program Model (OPM) programs run in the default activation group, and by default use the *DFTACTGRP commitment definition. In a mixed OPM and ILE environment, jobs must use the job-level commitment definition if all committable changes made by all programs are to be committed or rolled back together.
An opened database file scoped to an activation group can be associated with either an activation-group-level or job-level commitment definition. An opened database file scoped to the job can be associated only with the job-level commitment definition. Therefore, any program, OPM or ILE, which opens a database file under commitment control scoped to the job needs to use the job-level commitment definition.
Application programs do not use the commitment definition name to identify a particular commitment definition when making a commitment control request. Commitment definition names are primarily used in messages to identify a particular commitment definition for a job.
For activation-group-level commitment definitions, the system determines which commitment definition to use, based on which activation group the requesting program is running in. This is possible because the programs that run within an activation group at any point in time can only use a single commitment definition.
For transactions with transaction-scoped locks, the XA APIs and the transaction related attributes added to the CLI determine which commitment definition the invoking thread uses.