How To Use VM/SP Facilities To Debug
Abend
CP Abend Once the problem and the area where it occurs are identified, you can gather
the information needed to determine the cause of the problem. The type of
information you want to look at varies with the type of problem. The tools
used to gather the information vary depending upon the area in which the prob­
lem occurs. For example, if the problem is a loop condition, you will want to
examine the PSW. For a CP loop, you have to use the operator's console to
display the PSW, but for a virtual machine loop you can display the PSW via
the CP DISPLAY command.
The following sections describe specific debugging procedures for the various
error conditions. The procedures tell you what to do and what debug tool to
use. For example, the procedure may say dump storage using the CP DUMP command. The procedure does not tell you how to use the debug tool. Refer
to "An Overview of VM/SP Commands That Can Be Used for Debugging" and "CMS Debugging Commands" sections for a detailed description of each
debug tool, including how to invoke it.
Three types of abnormal terminations (ABEND) can occur on VM/SP: CP abends, CMS abends, or virtual machine abends. The following description
provides guidelines for debugging each type of ABEND.
When the VM/SP Control Program abnormally terminates, a dump is taken.
This dump can be directed to tape or printer, or dynamically allocated to a
direct access storage device. The output device for a CP abend dump is speci­
fied by the CP SET DUMP command. See the "Abend Dumps" section for a
description of the SET DUMP command. Use the dump to determine why the control program terminated and then
determine how to correct the condition. See the "Reading CP Abend Dumps" discussion for detailed information on reading a CP abend dump. Reason for the Abend: CP will terminate and take an abnormal termination
dump under three conditions:
1. Program Check in CP Examine the PROPSW and INTPR fields in the prefix storage area (PSA) to determine the failing module.
2. Module Issuing an SVC 0 Examine the SVC old PSW (SVCOPSW) and abend code (CPABEND) fields in the Prefix Storage Area to determine the module that issued the
SVC 0 and the reason it was issued. CP ABEND contains an abnormal termination code. The first three charac­
ters identify the failing module (for example, abend code TRC001 indi­
cates DMKTRC is the failing module).
Introduction to Debugging 475

eMS Abend
476 VM/SP System Programmer's Guide
3. Operator forcing a CP system restart on Processor Console
Examine the old PSW at location X'08' to find the location of the instruc­
tion that was executing when the operator forced a CP system restart. The
operator forces a CP system restart when CP is in a disabled wait state or
loop. (Refer to your processor manual for the appropriate method to force
a CP system restart.)
Note: The same conditions that cause an abnormal termination on a
uniprocessor configuration cause an abnormal termination on an attached
processor.
Examine Low Storage Areas: The information in low storage specifies the status
of the system at the time CP terminated. Status information is stored in the PSA. You should be able to tell the module that was executing by looking at
the PSA. Refer to the appropriate save area (SA VEAREA, BALRSA VE, or
FREESA VE) to see how that module started to execute. The PSA is described
in VM / SP Data Areas and Control Block Logic, Volume 1.
Examine the real and virtual control blocks to find the status of I/O operations.
Figure 67 on page 504 shows the relationship of CP Control Blocks.
Examine the CP internal trace table. This table can be extremely helpful in
determining the events that preceded the abend. The "CP Internal Trace Table" description tells you how to use the trace table.
The values in the general registers can help you to locate the current 10BLOK and VMBLOK and the save area. Refer to "Reading CP Abend Dumps" for
detailed information on the contents of the general registers.
If the program check old PSW (PROPSW) or the SVC old PSW (SVCOPSW) points to an address beyond the end of the resident nucleus, the module that
caused the abend is a pageable module. Refer to "Reading CP Abend Dumps" to find out how to identify that pageable module. Use the CP load map that
was created when the VM/SP system was generated to find the address of the
end of the resident nucleus.
When CMS abnormally terminates, any ABEND exit routines established via
the ABNEXIT macro receive control. These exit routines allow you to bypass
CMS abend recovery and continue processing elsewhere. If no routine exists or
the exit routine returns to eMS, the following error message appears on the
terminal:
DMSAEN148T SYSTEM ABEND xxx CALLED FROM yyyyyy
where xxx is the abend code and yyyyyy is the address of the instruction caus­
ing the abend. The DMSABN module issues this message. Then, CMS waits
for a command to be entered from the terminal.
Because CMS is an interactive system, you will probably want to use its debug
facilities to examine status. You may be able to determine the cause of the
abend without taking a dump.
The debug program is located in the resident nucleus of CMS and has its own
save and work areas. Because the debug program itself does not alter the sta-