Updates to the notify object

 

The system updates the notify object with the commit identification of the last successful commit operation for that commitment definition.

For purposes of the notify object, these are considered uncommitted changes:

• An update to a record that is made under commitment control.

• A record that is deleted under commitment control.

• An object level change that is made to a local DDL object under commitment control.

• A read operation performed for a database file that was opened under commitment control. This is because file position is brought back to the last commitment boundary when a rollback operation is performed. If you perform a read operation under commitment control, the file position is changed and therefore, an uncommitted change then exists for the commitment definition.

• A commitment definition with one of the following resources that are added is always considered to have uncommitted changes:

  • An API commitment resource

  • A remote Distributed Relational Database Architecture™ (DRDA^® *) resource

  • A Distributed Database Management Architecture (DDM) resource

  • An LU 6.2 resource

  This is because the system does not know when a real change is made to the object or objects that are associated with these types of resources. Types of committable resources has more information about how you add and work with these types of resources.

The system makes updates to the notify object, based on the following ways that a commitment definition can end:

• If a job ends normally and no uncommitted changes exist, the system does not place the commit identification of the last successful commit operation in the notify object.

• If an implicit commit operation is performed for an activation-group-level commitment definition when the activation group is ended, the system does not place the commit identification of the last successful commit operation in the notify object.

  Implicit commit operations are never performed for the *DFTACTGRP or *JOB commitment definition

• If the system, job, or an activation group ends abnormally before the first successful commit operation for a commitment definition, the system does not update the notify object because there is no last commit identification. To differentiate between this condition and a normal program completion, your program must update the notify object with a specific entry before completing the first successful commit operation for the commitment definition.

• If an abnormal job end or an abnormal system end occurs after at least one successful commit operation, the system places the commit identification of that commit operation in the notify object. If the last successful commit operation did not specify a commit identification, then the notify object is not updated. For an abnormal job end, this notify object processing is performed for each commitment definition that was active for the job. For an abnormal system end, this notify object processing is performed for each commitment definition that was active for all jobs on the system.

• The system updates the notify object with the commit identification of the last successful commit operation for that commitment definition if all of the following events occur:

  • A nondefault activation group ends.

  • An implicit rollback operation is performed for the activation-group-level commitment definition.

  • At least one successful commit operation has been performed for that commitment definition.

  If the last successful commit operation did not specify a commit identification, then the notify object is not updated. An implicit rollback operation is performed for an activation-group-level commitment definition if the activation group is ending abnormally or errors occurred when closing the files that were opened under commitment control and that were scoped to that activation group. For more information about scoping database files to activation groups and how activation groups can be ended, see the reference book for the ILE language that you are using.

• If uncommitted changes exist when a job ends normally and at least one successful commit operation has been performed, the commit identification of the last successful commit operation is placed in the notify object and the uncommitted changes are rolled back. If the last successful commit operation did not specify a commit identification, then the notify object is not updated. This notify object processing is performed for each commitment definition that was active for the job when the job ended.

• If uncommitted changes exist when the ENDCMTCTL command is run, the notify object is updated only if the last successful commit operation specified a commit identification:

  • For a batch job, the uncommitted changes are rolled back and the commit identification of the last successful commit operation is placed in the notify object.

  • For an interactive job, if the response to inquiry message CPA8350 is to rollback the changes, the uncommitted changes are rolled back and the commit identification of the last successful commit operation is placed in the notify object.

  • For an interactive job, if the response to inquiry message CPA8350 is to commit the changes, the system prompts for a commit identification to use and the changes are committed. The commit identification that is entered on the prompt display is placed in the notify object.

  • For an interactive job, if the response to inquiry message CPA8350 is to cancel the ENDCMTCTL request, the pending changes remain and the notify object is not updated.

 

Parent topic:

System-initiated end of commitment control

 

Related concepts

Ending commitment control
Commitment control during activation group end
Commitment control during normal routing step end
Commitment control during abnormal system or job end
Types of committable resources
Commit notify object