The following information is saved in the RLOG file of each respective subtransaction during the two-phase commit:
“Transaction in PTC state”: if a subtransaction of the transaction involved is in the PTC state
“Transaction terminated with FINISH” or “Transaction terminated with FINISH WITH CANCEL“: if the primary subtransaction was terminated with FINISH or FINISH WITH CANCEL.
See section “Ensuring cross-configuration consistency with a two-phase commit”.
Since the RLOG file is maintained on a session-specific basis, it may not be possible to check the configuration of the primary subtransaction after a normal DBH termination to determine how the primary transaction was terminated. Consequently, information on how the transaction terminates is also saved in the DB status file, which is maintained on a configuration-specific basis.
The PTC state is a critical phase of the two-phase commit. The DBH load parameter PP PTCSYNCH can be used to control how a subtransaction in the PTC state is handled.
The database administrator should therefore avoid changing the PTCSYNCH value to ABORT or COMMIT unless he or she can make an informed decision about the cross-configuration consistency (see also section “Terminating the PTC state”).
The PTC state has a significant effect:
during the session
during a warm start
on terminating the DBH
on the application program when the logical connection is lost
Effects of the PTC state during a session
During a session, the PTC state has a significant effect when:
restarting UDS-D mode after a normal or abnormal termination.
altering the database configuration (see section “Altering the DB configuration: notes for UDS-D”).
If there are subtransactions in the PTC state, the databases involved cannot be detached consistently from the DB configuration.writing a checkpoint (see “Writing checkpoints (CHECKPOINT)”).
When checkpoints are to be written, it is important to ensure that the connection to the configuration of the primary subtransaction or to openUTM exists. This is because UDS/SQL will only write checkpoints for a database if all transactions that have updated this database have terminated.
If attempts to write checkpoints or to detach or attach databases have already been initiated, but cannot be completed because of subtransactions in the PTC state, the database administrator can:
use &SYNCHRONIZE DISTRIBUTION to have the secondary subtransactions check how the primary subtransaction was terminated. If UDS/SQL cannot determine how this occurred, the secondary subtransaction remains in the PTC state.
use DISPLAY USERS to check the transaction IDs of the subtransactions in the PTC state and then terminate these transactions with the following DAL commands:
ABORTtransaction-id,OPTION=PTC
or
COMMITtransaction-idIf the database administrator intervenes with ABORT,OPTION=PTC or COMMIT, cross-configuration consistency or the consistency between UDS/SQL and openUTM cannot be guaranteed (see section “Terminating the PTC state”).use %TERM
to abort the session and then restart without the affected database.
Effects of the PTC state during a warm start
In the case of a warm start, all open transactions are rolled back. Subtransactions in the PTC state, if any, are handled in accordance with the DBH load parameter PP PTCSYNCH for a warm start.
If the value of this parameter has been set to WAIT for a primary subtransaction, the database involved is not attached during a warm start until openUTM requests the termination of the transaction.
If the PP PTCSYNCH parameter is set to WAIT for a secondary subtransaction, UDS/SQL will try to reach the associated primary subtransaction. The following conditions must be satisfied for this purpose:
UDS-D mode must have been started in the respective configurations of the primary and secondary subtransactions.
The distribution tables must reflect the conditions on the network.
There must be one configuration with the configuration name under which the primary subtransaction was running before the session abort.
This configuration may have a different composition or be located on another host, provided the distribution tables have been adjusted accordingly.The DB status file must be present in the respective configurations of the primary and secondary subtransactions.
If the state of the associated primary subtransaction cannot be determined, the secondary subtransaction remains in the PTC state, and the database in question is not attached.
Figure 26 shows the processing sequence of a warm start when there are secondary subtransactions in the PTC state.
Figure 26: Warm start with secondary subtransactions in the PTC state
Following a session abort, the databases DB-A1, DB-A2 and DB-A3 are to be started in the configuration CONF-A.
The databases DB-A2 and DB-A3 require a warm start, since the secondary subtransaction STT-C, which was initiated in the application program AP-C of the configuration CONF-C, is still in the PTC state. The RLOG file and DB status file for CONF-C contains an entry to indicate whether the primary subtransaction PTT-C was terminated with FINISH or FINISH WITH CANCEL.
During the warm start of configuration CONF-A, a transaction in the PTC state is found in the RLOG file.
The master task passes the warm start information stored in the RLOG file to the UDS-D task.
The UDS-D task uses the warm start information to determine the host processor and the configuration of the primary subtransaction associated with STT-C. It then sends a message to the remote UDS-D task with a request to determine how the primary transaction was terminated.
This message is passed by the remote UDS-D task to its master task.
The master task checks the DB status file to determine how the primary transaction was terminated. If this file is not current, it looks in the RLOG file.
6. and 7.
The result is passed to the UDS-D, and then forwarded on to the UDS-D task of the secondary subtransaction.
8. The UDS-D task passes the result to the master task.
9. The secondary subtransaction STT-C is terminated in the same way as the primary subtransaction.
10. The UDS-D task of CONF-A contacts all configurations listed in its distribution table to notify them that the configuration CONF-A may be addressed again.
11. Since the secondary subtransaction STT-A in the configuration CONF-B is still in the PTC state, the UDS-D task of CONF-B sends a message to the UDS-D task of the primary subtransaction to determine the state of the primary subtransaction.
12. and 13.
See 4. and 5.
14. and 15.
See 6. and 7.
16. Depending on the result, the UDS-D task sends the FINISH or FINISH WITH CANCEL request to the server task.
17. The termination of the transaction is logged in the RLOG file.
If a secondary subtransaction in the PTC state cannot be terminated in the same way as its primary subtransaction in a warm start, the secondary subtransaction remains in the PTC state, and the database in question is not attached during the warm start. The database administrator is informed of the other subtransactions involved by means of a message.
If there are databases that cannot be attached during a warm start because of a subtransaction in the PTC state, you will need to wait until the configuration of the primary subtransaction can be accessed again or until openUTM requests the termination of the transaction. Alternatively, you may also use the DAL command MODIFY to set the PTCSYNCH value for a warm start to ABORT or COMMIT.
Effects of the PTC state on terminating the DBH
DBH termination with CLOSE RUN-UNITS or CLOSE CALLS
UDS-D waits until all secondary subtransactions in the PTC state are terminated automatically or until openUTM requests the end of the transaction.
If the transactions to not terminate automatically, the database administrator can:
use &SYNCHRONIZE DISTRIBUTION to have the secondary subtransactions check how the primary subtransaction was terminated. If UDS/SQL cannot determine how this occurred, the secondary subtransaction remains in the PTC state.
use DISPLAY USERS to check the transaction IDs of the subtransactions in the PTC state and then terminate these transactions with the following DAL commands:
ABORTtransaction-id,OPTION=PTC
or
COMMITtransaction-idIf no further subtransactions are open, the DBH is terminated.
If the database administrator terminates the subtransactions with ABORT,OPTION=PTC or COMMIT, cross-configuration consistency or the consistency between UDS/SQL and openUTM cannot be guaranteed (see section “Terminating the PTC state”).
use %TERM to abort the session
Subtransactions in the PTC state remain in the PTC state. The special aspects to be noted for a warm start in this case can be found under “Effects of the PTC state during a warm start”.
Following a session abort, databases that were rendered inconsistent during the session should be attached with a warm start as soon as possible to ensure proper communication between the DB configurations.
Effects of the PTC state on an application program when a logical connection is lost
If the logical connection to a remote configuration is lost during the termination phase of a distributed transaction and cannot be established again, the effects on the application program will depend on which phase of the two-phase commit the primary subtransaction is in.
The user task has sent the PETA statement to the secondary subtransactions, but the primary subtransaction itself has not yet terminated.
The application program receives status code 122, “Transaction prematurely canceled”, from the connection module.The application program has initiated a FINISH that was executed successfully.
In this case, the application program receives status code 000: “DML statement executed successfully“, from the connection module.In the configuration of primary subtransaction, the transaction is treated as terminated, regardless of whether or not a secondary subtransaction in the PTC state still exists in a remote configuration.
If the FINISH of the primary subtransaction executes with errors, the application program receives the status code of the failed FINISH.