gtpa2m1o | Application Programming |
A commit scope can be ended in the following ways:
This is the normal way to end a commit scope and causes all changes to be either written to the DASD surface, the recovery log, or reflected up to the next higher level commit scope.
This is the abnormal way to end the commit scope; all DASD changes are discarded with this method. The writing of changes to the DASD surface ends abnormally. Any release pool address requests that were made in the commit scope are discarded. Messages put to a queue through the MQPUT function are removed, and messages retrieved from a queue through the MQGET function are put back.
If the ECB either exits or causes a system error in the commit scope, an implied root commit scope rollback transaction is entered. If the ECB has suspended root scopes, these are also rolled back.
Commit scopes are processed according to the following rules:
When you enter a commit transaction on a commit scope, locks that are held at the commit scope level are either:
When you enter a commit transaction on the current commit scope, all pool addresses acquired while in the commit scope are:
When you enter a commit transaction on the current commit scope, all requests entered in the commit scope to release file pool addresses are:
When you enter a commit transaction on the current commit scope, all virtual file access (VFA) flush requests entered in the commit scope are:
When entering a commit transaction on the current commit scope, all requests entered in the commit scope to change any queues managed by the local TPF MQSeries local queue manager (MQPUT, MQPUT1, or MQGET functions) are passed up to the next highest commit scope.
When you enter a rollback transaction, the following processing takes place:
DASD locks that are obtained outside the commit scope are not affected by the rollback of a commit scope.
All pool addresses acquired while in the commit scope are released back to the TPF system if the general file system (GFS) is active. If the GFS is not active, the pool addresses are lost until the next time you run the recoup utility. Pool addresses that are obtained outside the commit scope are not affected by the rollback transaction.
All pool address releases that are entered while in the commit scope are ignored. The pool addresses, if acquired outside the commit scope, are still owned by the application.
All messages that were added to queues are removed from the queues and all system resources are released. All messages that were retrieved from the queues are restored to the queues.
All changes made by a nested scope become visible to the next higher level nested scope when you enter the commit transaction.
When you enter the commit transaction on the root scope, all the changes that were made become visible to all ECBs.
Changes made in a nested scope are not visible to higher level nested scopes, to other commit scopes, or to ECBs not running in a commit scope until you enter the commit transaction on the root commit scope.