Recovery and Restart Procedures › CICS Abend › CICS Emergency Restart Environmental Considerations

CICS Emergency Restart Environmental Considerations

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:

• There is greater integrity or a higher degree of integrity and more automation for CICS and CA Datacom/DB MUF restarts from system abends.
• Substantial delays can occur on subsequent updates while records are in an in-doubt state.
• CICS must be restarted and connected to CA Datacom/DB to clear in-doubt conditions, if it was the CICS that abended.
• If the CA Datacom/DB MUF abended but CICS remained running, only the CA Datacom/DB MUF must be restarted and reconnected to CICS to eliminate in-doubt states.
• Only those transactions in the middle of a two-phase commit when the system abend occurs are affected. Here the term system abend can mean that CICS abended, or the MUF abended, or both abended. The term middle as used here is a complex term that must be considered for each MUF involved between its Phase 1 request (LOGPR) and its Phase 2 request (COMIT). For the same task, the two-phase commit may be at different phases for different MUFs involved. Only those MUFs for a given task that are between LOGPR and COMIT are in-doubt, while there can be other MUFs records for this same task that would not be in-doubt from the system abend.
• When CICS and CA Datacom/DB are reconnecting and in-doubt status conditions are being resolved, message DC00501I, DC00502E, DC00503I, or DC00504I is generated to inform you about what actions were taken by CA Datacom/DB for each in-doubt MUF/unit of work.
• A CICS COLD START does not clear an in-doubt condition in CA Datacom/DB.

  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.

• The next two paragraphs explain the steps involved in manually re-synchronizing CA Datacom/DB for a cold start. Remember that these steps should only be done after the interrogation phase has been completed. CA Datacom CICS Services provides a message to warn the site that a cold start has been done and what units of work need to be researched from the perspective of CA Datacom/DB.
  • The CA Datacom/DB Utility (DBUTLTY) COMM STATUS function must be run. The site has to decide on an individual case by case basis whether this unit of work is to be committed or backed out. The site must run a COMM REQCOMIT or a COMM REQROLBK (see the CA Datacom/DB DBUTLTY Reference Guide) for each cold-started sequence number after determining whether it was committed in CICS or backed out in CICS.
  • COMM REQCOMIT and COMM REQROLBK can only be run after CICS has been brought up and reconnected to CA Datacom/DB.

Note: The term log records:

• In z/OS environments means "MVS LOGGER records for CICS."
• In VSE environments means "records in the CICS journal files."