Problem Management

The ultimate goal of CRR problem management is to find all resources in an LUWID, determine the status of the resources, and then take action to make all the resources consistent.

This section describes the steps a CRR operator has to follow in the rare case of CRR not being able to complete a transaction. See Figure 1 for the example transaction in this CRR problem management scenario. In this scenario:
  • Application program on VM1 updates the protected resources on VM2 and VM4.
  • Application program on VM1 initiates a protected conversation with the application program on VM3.
  • Application program on VM3 updates the protected resources on VM5 and VM6.
In this scenario, let's assume:
  • The error occurs during the second phase of the two-phase commit.
  • The error is the loss of the protected conversation between VM1 and VM3.
  • The protected resources at VM2 and VM4 are committed.
  • VM3, VM5, and VM6 are in-doubt.
Figure 1. CRR Problem Management Scenario
CRR Problem Management Scenario
Note:
  1. Always examine the transaction tag before proceeding with any problem management steps. An application can write a transaction tag on to the CRR logs by using the Set Transaction Tag CSL routine (DMSSETAG) as described in z/VM: CMS Callable Services Reference. The transaction tags may identify a file that contains recovery procedures in the event of a error. Reading the recovery procedures could save the CRR operator a lot of work.
  2. When you enter a CRR QUERY LU or CRR QUERY LUWID command, from the CRR recovery server console, the console's screen may fill up with output. If you let the CRR recovery server console's screen fill up with output and you do not receive the message Operator command processing complete, you have tied up the CRR recovery server and the coordinated transactions cannot access the CRR recovery server. The CRR operator should scroll through the console's output, print the contents of the CRR recovery server console, and then examine the printed output. Scrolling through the console output frees up the CRR recovery server and makes it available for coordinated transaction processing. Assuming the server's console has been spooled using the SPOOL CONSOLE START command, you could print the contents of the console by using the SPOOL CONSOLE CLOSE command and then printing the reader file.

    You could also avoid filling up the CRR recovery server console by using SCIF and issuing commands from a secondary user console.