If your site connects to only one MUF and no other resources, emergency restart considerations have not changed compared to the previous release, and you therefore do not need the information in this section. When there is only one resource (not records) being updated, a single-phase commit is involved but no two-phase commits.
If your site has CA Datacom/DB transactions that also update other resources, such as the VSAM and DB2 products of IBM, or if more than one MUF is involved in the same transaction, this section contains important information.
We recommend that you always do a WARM START of CICS in a production environment, even if no more CICS production work is to be done at that time. The only WARM START exception to this might be if CA Datacom/DB is the only updating resource and it is using only one MUF, that is, it is not using VSAM, DB2, or DL/I, and so on.
Note: In an XRF environment, the CICS APPLID must be the same as the original CICS for the connection process to work.
Because CA Datacom CICS Services only runs in a CICS Transaction Server, CA Datacom CICS Services fully exploits the CICS two-phase commit protocol, including INDOUBTWAIT for both z/VSE and z/OS. It is a Best Practice to always use WARMSTART. For those sites already using the CICS WARM START recovery option, CA Datacom CICS Services works without requiring any additional steps to re-synchronize CA Datacom/DB with CICS. There can be additional steps required for those sites that choose to continue using the CICS COLD START recovery option.
If CICS or CA Datacom/DB abends while transactions are in two-phase commit, those records that were updated may exist in an in-doubt state. Such records are no longer available for updating by batch or online until the same CICS APPLID and CA Datacom/DB have reconnected with each other and all in-doubt states have been resolved. That is to say, records in an in-doubt state remain in that state and cannot be updated until the associated CICS APPLID is reconnected. In previous releases, when a CICS abend occurred records were either committed or backed out almost at once. For further information, see messages DC00501I, DC00502E, DC00503I, and DC00504I, including the example in DC00504I.
It is important to understand and test the ramifications of the previously discussed information before placing CA Datacom CICS Services into a production environment. To summarize, the changes of which you should be aware are as follows:
CICS COLD START requires a manual recovery. All CICS in-doubt log records are lost and therefore automated recovery is impossible. A manual recovery is often dangerous and time consuming. During this time, those in-doubt records cannot be updated by any task or job.
CA Datacom/DB has provided a way to manually resolve those in-doubt states. Sites must interrogate all other updateable resources (other CA Datacom and non CA Datacom) to determine if those other resources were committed, backed out, or mixed. This interrogation must take place on each task in question.
For example, a CICS abends while a given task containing DB2, VSAM, and CA Datacom/DB was in a SYNCPOINT. CICS was then cold started. The DB2 records then might be committed while the VSAM records were not, and MUF records are in-doubt. A decision would need to be made for both the VSAM and MUF records.
CICS COLD STARTs are therefore not recommended for production CICS systems.
Note: The term log records:
Copyright © 2015 CA Technologies.
All rights reserved.
|
|