After the processor operator has collected the information, the
system programmer or system support personnel examine it. If the cause
of the loop is not apparent,
1. Examine the CP internal trace table to determine the modules that
may be involved in the loop.
2. If the cause is not
caused the loop entry
branch,.
yet determined, assume that a wild branch
and search the source code for this wild When a disabled loop in a virtual machine exists, the virtual machine
operator cannot communicate with the virtual machine's operating system.
That means that signalling attention does not cause an interrupt.
Enter the CP console function mode.
1. Use the CP TRACE command to trace the entire loop. Display general
and extended control registers via the CP DISPLAY command.
2. Take a dump via the CP DUMP command.
3. Examine the source code. Use the information just gathered, along with listings, to try to
find the entry into the loop_ !Qte: You can IPL a standalone dump program such as the BPS Storage
Print to dump the storage of your virtual machine. If you choose to use
a standalone dump program, be sure to specify NOCLEAR on the IPL
command. Also, be aware that the CP IPL simulation destroys a page of
storage in your virtual machine and the standalone dump alters your
virtual storage while the CP DUMP command does net.
However, if the operating system in the virtual machine itself
manages virtual storage, it is usually better to use that operating
system's dump program. CP does not retrieve pages that exist only on
the virtual machine's paging device. The virtual machine operator should perform the following sequence when
attempting to find the cause of an enabled loop:
1. Use the CP TRACE command to trace the entire loop. Display the PSi and the general registers.
2. If your virtual machine has the Extended Control (EC) mode and the
EC option, also display the control registers.
3. Use the CP DUMP command to dump your virtual storage. CMS users
can use the debug DUMP subcommand. A standalone dump may be used.
but be aware that such a dump destroys the contents of some areas
of storage.

4. Consult the source code to search for the faulty instructions, exam1n1ng previously executed modules if necessary. Begin by
scanning for instructions that set the condition code or branch en
it.
5. If the manner of loop entry is still undetermined. assume that a
wild branch has occurred and begin a search for its origin. WAIT No processing occurs in the virtual machine when it is in a wait state. When the wait state is an enabled one, an I/O interrupt causes
processing to resume. Likewise
r when the Contrel Program is in a wait
state, its processing ceases.
A disabled wait state usually results from a hardware malfunction.
During the 1PL process; normally correctable hardware errors may cause a
wait state because the operating system error recovery procedures are
not accessible at this point. These conditions are recorded in the
current PSW. CP may be in an enabled wait state with channel 0 disabled when it is
attempting to acquire more free storage. Examine EC register 2 to see
whether or not the multiplexer channel is disabled. A severe .achine
check could also cause a CP disabled wait state.
Three types of severe machine checks can cause the Control
Program to terminate or cause a CP disabled wait state. • An unrecoverable machine check in the control program • A machine check that cannot be diagnosed • Timing facilities damage A machine check error cannot be diagnosed if either the machine check
old PSi or the machine check interrupt code is invalid. These severe
machine checks cause the control program to terminate.
If a severe machine check or channel check caused a CP disabled wait
state, one of the following messages will appear: CHANNEL ERROR, RUN SEREP, RESTART SYSTEM MACHINE CHECK TIMING FACILITIES tAMAGE; RUN SEREP DMKMCT612i MACHINE CHECK TIMING FACILITIES DAMAGE; RUN SEREP Part 1. Debugging with VM/370 27