gtpa2m1n | Application Programming |
The following explains how commit scope processing affects DASD requests, pool file addresses, and TPF MQSeries support.
In the commit scope, all DASD requests are satisfied first from the current commit scope set and, then up the chain of nested scopes (from lowest to highest), and finally from outside the commit scope.
The TPF system first searches in the commit scope set for the record; if it is not found, normal DASD retrieval takes place from VFA or the DASD surface. Once it is found, the record is attached to the ECB. Find requests are not added to the commit scope.
The TPF system writes the record to the commit scope buffer; writing (or hardening) the data to the DASD surface occurs only when you enter the commit transaction. File requests are always added to the commit scope.
The action of the FILEC macro depends on the settings returned from the record ID attribute table (RIAT) and the RIAT user exit. These settings include the control of logging, record cache options, and VFA options. The FILEC actions that are controlled by the RIAT indicators are set at FILEC time, but do not take place until the record has been committed.
Record lock holding occurs at two levels: the ECB level and the commit level. Following a find-and-hold type macro, record locks are held at the ECB level. If an ECB releases a lock that is held at the ECB level using an unhold-type macro while in a commit scope, the lock is no longer held at the ECB level; it is then held at the commit level.
A record lock that is held at the commit level becomes held at the ECB level if the ECB in the commit scope, or a commit scope nested from the commit scope, issues a find-and-hold type macro.
A record lock that is held at the commit level becomes unheld when the root commit scope commits.
A record lock held at the ECB level is released if an ECB issues an unhold-type macro outside of a commit scope. Table 12 is a matrix that shows what happens when locks are held and released and the effect if they are held inside or outside the commit scope. See Unhold in commit scope in column 1 for an example of how to read the matrix.
Columns 2 and 3 represent current lock processing for the TPF system. This functions the same regardless of whether TPF transaction services processing is active.
Columns 4, 5, and 6 represent processing in the TPF system.
Table 12. Matrix of the Locking Scheme for DASD Inside and Outside a Commit Scope
WAITC will normally suspend the ECB until the requested I/O has completed. Most WAITC processing happens normally in a commit scope. One exception is FILNC and WAITC. FILNC-detected DASD surface errors that are currently reported on WAITC cannot be reported if the FILNC operation is in a commit scope because the actual filing of the record does not take place until you enter a commit transaction. Hardware errors, normally seen at WAITC completion, will not be returned.
TPF transaction services processing does not change the retrieval process for pool file addresses; that is, there is no change when an ECB gets a pool address from the TPF system. Nothing different happens for these addresses. When you enter a commit transaction, the retrieval process is still the same. However, these addresses will be released if you roll back the transaction.
The way release pool address processing works changes in a commit scope; the timing of the release of pool addresses is different. Because of the possibility of a rollback transaction, pool address release requests are held until the commit transaction is completed. This applies to both single releases and chain (RLCHA) releases.
Updates to local queues, which are managed by the TPF local queue manager, participate in the commit scope. The MQPUT, MQPUT1 and MQGET functions are part of the transaction that can be committed or backed out by the application. Updates to queues that are managed by a remote MQSeries server (via TPF MQSeries client support) do not participate in the commit scope and are processed outside the unit of work.
When an application issues an MQPUT or MQPUT1 function in an open commit scope, the message appears on the queue in an uncommitted state. No other ECBs can access the message unless the application commits the unit of work. The same ECB can see the message on the queue if it issues an MQGET function even though the commit scope is still open.
When an application issues an MQGET function while in an open commit scope, the message is retrieved from the queue and given to the application, but is not deleted from the queue until the application commits the unit of work. No other ECBs can access the same message until the root commit scope is rolled back.
When an application issues an MQGET function to a processor shared queue while in an open commit scope, the message is retrieved and deleted from the queue and given to the application. The message is put back on the queue if the transaction ends abnormally or if the application rolls back the transaction.
No other MQSeries APIs participate in the commit scope. For instance, a tx_rollback function does not imply that a queue that was opened is automatically closed.