The following CA Datacom/DB log commands require special consideration.
This section contains the following topics:
Exclusive CA Datacom/DB Applications
Primary and Secondary Exclusive Control
There is no spawning in CA Datacom/DB Version 14.0 and CA Datacom CICS Services Version 14.0. Whenever possible, applications should avoid issuing the CA Datacom/DB log commands. Instead, use the appropriate EXEC CICS SYNCPOINT or EXEC CICS SYNCPOINT ROLLBACK. This recommendation is based on keeping all the resources of the transaction in synchronization with each other.
Starting in CA Datacom CICS Services Version 14.0, all user issued CA Datacom/DB log commands that checkpoint user data (COMIT, ROLBK, LOGCP, LOGCR, and LOGTB) are replaced with a CICS SYNCPOINT or CICS SYNCPOINT ROLLBACK. This is needed to help ensure data integrity between resource managers within a single transaction. There are no exceptions.
Applications issuing LOGCP, LOGCR, COMIT, ROLBK, or LOGTB cannot run with mixed releases of CA Datacom/DB MUF Version 12.0 and Version 14.0 in the same CICS. This is another reason for using CICS SYNCPOINT.
Note: You can run with mixed releases of CA Datacom/DB Version 12.0 and CA Datacom CICS Services Version 14.0.
LOGIT, LOGLB, LOGDR, and LOGDW do not checkpoint user data, therefore they are not replaced with a CICS SYNCPOINT.
For exclusive CA Datacom/DB applications that have no other user data resource managers, there is no effective change, but CA Datacom CICS Services Version 14.0 issues a SYNCPOINT(ROLLBACK) instead. In some cases where no locks or updates occurred, then no internal log command is issued to CA Datacom/DB. But for those applications where there are additional user data resource managers involved, a SYNCPOINT or SYNCPOINT ROLLBACK occurs against all resources, not just against CA Datacom/DB. In previous releases only CA Datacom/DB would be affected by the user log command. Therefore, an application issuing a user log command in CA Datacom CICS Services Version 14.0 results in SYNCPOINT of all other data resources involved in this transaction including DB2 and VSAM.
Careful consideration must be made before migrating a production environment from r11 to Version 14.0 that contains user issued log commands.
The LOGCP command allows primary exclusive control to cross a SYNCPOINT boundary.
Primary exclusive control is requested with a command that acts as a prerequisite for the UPDAT and DELET commands, such as RDUKX or SELFR with UPDATE-INTENT=Y. Primary exclusive control is dropped when the record is updated or deleted or released with the RELES or RELFL commands.
Secondary exclusive control is the enqueuing of logical records that takes place when a transaction backout task issues a maintenance request, such as add, update or delete. When a transaction backout batch job or online task updates rows, these rows are not available to any other task until the batch job or online task has finished or has taken a checkpoint. In general, if another task issues an update read for a row updated by this batch job or online task, then that task must wait for the batch job or online task to complete or checkpoint. This means an online processor may have to wait for a batch job to finish.
CA Datacom CICS Services Version 14.0 still supports legacy applications issuing user log commands LOGCP, LOGCR, and LOGTB. Version 14.0 still issues the SYNCPOINT or SYNCPOINT ROLLBACK, but preserves the log command's original intent. The following is a detailed explanation for each user issued log command.
CA Datacom CICS Services can support connections to several different CA Datacom/DB MUFs in the same CICS. The desired connections are described by listing the SIDs that point to the various CA Datacom/DB MUFs and are compiled in the DBCVTPR assembly. The first one in the list is known as MUF01 and is the default CA Datacom/DB MUF.
In this section all nine user-issued log commands are listed, however LOGCP and LOGCR each have two sections, one with a meaningful work area and one without a meaningful work area. View the one which is applicable to your application.
Each command section contains the following:
This section does not describe what the commands mean. For command meanings, see the CA Datacom/DB manuals.
COMIT is replaced with an EXEC CICS SYNCPOINT. If there are any errors during the SYNCPOINT, this info is passed back in the DB RC of the user's application request area, and a backout occurs. Except the backout cannot occur if the error occurred during Phase 2. In this case, the records are to be committed.
When no updates have occurred and no records are locked for update, SYNCPOINT is still issued but no internal log request is sent to the CA Datacom/DB MUF.
If at the time the application issues the user COMIT request, there are update requests on multiple resource managers, then CICS SYSNCPOINT invokes a two-phase commit. If threads are locked, both the CA Datacom/DB thread and the corresponding CA Datacom CICS Services thread are released. All record locks are released.
LOGCP with a work area of 8 bytes of low-values or 8 blanks, is replaced with an EXEC CICS SYNCPOINT. However, the primary locks with primary exclusive control, remain in effect after the SYNCPOINT, just as in previous releases without the SYNCPOINT.
If there are any errors during the SYNCPOINT, this info is passed back in the DB RC of the user's application request area and a backout occurs.
If no updates have occurred and there are no record locks, then the SYNCPOINT is still issued but no internal log request is sent to CA Datacom/DB MUF.
If there are update type requests on multiple resource managers at the time the application issues the user LOGCP request with a work area of binary zeros or blanks, then CICS SYSNCPOINT results in a two-phase commit.
The CA Datacom/DB threads and the corresponding CA Datacom CICS Services threads are not released for a LOGCP request that has a work area of binary zeros or blanks if there are any primary exclusive controls in effect at the time of the request. Otherwise, the threads are released on any locked thread connections to a CA Datacom/DB MUF where all primary exclusive control associated with this task on this MUF has been dropped due to updates or releases.
LOGCP with a work area other than 8 bytes of low-values or 8 blanks is a forward-looking command. Therefore it is a reference point command and the default CA Datacom/DB MUF must be involved in the SYNCPOINT. Likewise as in the case of the LOGIT or LOGLB, if the default CA Datacom/DB MUF is not connected, a DB RC 36 is returned to the application without issuing the SYNCPOINT even if there are other CA Datacom/DB MUFs connected. The primary exclusive control locks remain in effect after the SYNCPOINT, just as in previous releases without the SYNCPOINT.
If no updates and no record locks for update have occurred, then the SYNCPOINT is still issued and an internal log request is sent to the default CA Datacom/DB MUF.
If any resource other than the default CA Datacom/DB MUF (MUF01) had record updates or locks this automatically becomes a two-phase commit, even if there were no record locks or updates on the default CA Datacom/DB. This includes a non-default CA Datacom/DB, DB2, or other database.
CA Datacom/DB and CA Datacom CICS Service threads remain locked after the SYNCPOINT. They are not released, but all updated record locks and secondary exclusive controls are released. The CA Datacom CICS Services and CA Datacom/DB threads are not released until after a future SYNCPOINT, task termination, or task ABEND.
LOGCR with a work area of 8 bytes of low-values or 8 blanks, is treated like a COMIT. It is replaced with an EXEC CICS SYNCPOINT. If there are any errors during the SYNCPOINT, this info is passed back in the DB RC of the user's application request area and a backout occurs.
If no updates have occurred and no records are locked for update, the SYNCPOINT is still issued but no internal log request is sent to the CA Datacom/DB MUF.
If there are update requests on multiple resource managers at the time the application issues the user LOGCR request with a work area of binary zeros or blanks, then the CICS SYSNCPOINT results in a two-phase commit.
Any existing CA Datacom/DB threads and the corresponding CA Datacom CICS Services threads are released for a LOGCR request with a work area of binary zeros or blanks. All record locks are also released.
LOGCR with a work area other than 8 bytes of low-values or 8 blanks is a forward-looking command and therefore is a reference point command. The default CA Datacom/DB MUF must be involved in the SYNCPOINT that is issued on behalf of this type of LOGCR. Likewise as in the case of LOGIT and LOGLB, if the default CA Datacom/DB MUF is not connected, a DB RC 36 is returned to the application without issuing the SYNCPOINT, even if there are other CA Datacom/DB MUFs connected to this CICS.
If there are any errors during the SYNCPOINT, this info is passed back in the DB RC of the user's application request area and a backout occurs releasing all associated threads.
If no updates or record locks for updates have occurred, then the SYNCPOINT is still issued with an internal log command against the default to CA Datacom/DB MUF.
If any resource other than the default CA Datacom/DB MUF (MUF01) had record updates or locks, this automatically becomes a two-phase commit even if there were no record locks or updates on the default CA Datacom/DB. This includes a non-default CA Datacom/DB, DB2, or other database.
CA Datacom/DB and CA Datacom CICS Services threads remain locked after the SYNCPOINT. They are not released for other CICS transactions. All data record locks are released.
LOGDW and LOGDR call DCCTFPR to determine which CA Datacom/DB MUF is used based on DBID. This is just as in previous releases of CA Datacom CICS Services.
LOGDW and LOGDR are not replaced with SYNCPOINT. They are issued without alteration.
LOGDW and LOGDR cause a thread to be locked after the request until a future CICS SYNCPOINT, task termination, or ABEND occurs.
The LOGIT and LOGLB commands request reference-points. These commands are issued only against the default CA Datacom/DB MUF known as MUF01. If the default CA Datacom/DB MUF is not connected, then the user application receives a DB RC (return code) 36 regardless of other CA Datacom/DB MUFs connected to this CICS.
The default CA Datacom/DB MUF must be connected for LOGIT or LOGLB to be successful. Thus the user knows where to find all reference points for all transactions in that CICS. The LOGIT or LOGLB causes a lock of both a CA Datacom/DB thread and a CA Datacom CICS Services thread.
If there is not a thread already locked for this task from the default CA Datacom/DB MUF, it must now acquire one. This thread remains locked until a future SYNCPOINT, task termination, or task ABEND occurs causing the thread to be released.
LOGTB is replaced with an EXEC CICS SYNCPOINT ROLLBACK but the CA Datacom/DB MUF retains the same TSN (Transaction Sequence Number) that existed before the SYNCPOINT ROLLBACK. All record locks are released but the CA Datacom/DB threads and the CA Datacom CICS Services threads are locked if a TSN had been created. Any return code error during the SYNCPOINT ROLLBACK is eventually backed out.
ROLBK is replaced with EXEC CICS SYNCPOINT ROLLBACK. There are no known error conditions on backout. All errors are eventually backed out. However, there are setup conditions that must be met in order for backout to occur, such as URT TXNUNDO=YES and CA Datacom/DB logging parameters. Otherwise the ROLBK result is a commit of the data rather than a backout of the data.
All threads locked by this CICS transaction or task are released. All record locks are released.
|
Copyright © 2015 CA Technologies.
All rights reserved.
|
|