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
Note:
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.
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.