Control registers (if available) Program Status Word
The STORE STATUS command can save certain information contained in low
storage.
When debugging, you may find it advantageous to alter storage, registers, or the PSW and then continue execution. This is a good procedure for testing a proposed
change. Also, you can make a temporary correction and then continue to ensure
that the rest of execution is trouble-free. A procedure for using the STORE ST A­ TUS command when debugging is as follows:
Issue the STORE STATUS command before entering a routine you wish to
debug.
When execution stops (because an address stop was reached or because of
failure), display the extended logout area. This area contains the status that
was stored before entering the routine.
Issue STORE STATUS again and display the extended logout area again. You
now have the status information before and after the failure. This information
should help you solve the problem.
Altering the Contents of Real Storage Use the STCP command to alter the contents of real storage. The STCP command
cannot alter the real PSW or real registers.
Modifying or Dumping CMS MODULE, LOADLIB, or TXTLIB Files Use the ZAP command to modify or dump MODULE, LOADLIB, or TXTLIB
files. ZAP can be used to modify either fixed-or MODULE files. ZAP makes use of control records to control processing. These records can be
submitted either from the terminal or from a disk file. Using the VER and REP control records, you can verify and replace records or instructions in a control sec­
tion (CSECT). Using the DUMP control record, you can dump all or part of a
CSECT, an entire member of a LOAD LIB or TXTLIB file, or an entire module
file. For a complete description of the ZAP command, see the VM / SP Operator's
Guide.
Debugging CP in a Virtual Machine
CP Internal Trace Table
Many CP problems can be isolated without standalone machine testing. It is possi­
ble to debug CP by running it in a virtual machine. In most instances, the virtual
machine system is an exact replica of the system running on the real machine. To
set up a CP system on a virtual machine, use the same procedure that is used to
generate a CP system on a real machine. However, remember that the entire pro­
cedure of running service programs is now done on a virtual machine. Also, the
virtual machine must be described in the real VM/SP directory. See VM / SP Oper­
ating Systems in a Virtual Machine for directions on how to set up the virtual
machine. CP has an internal trace table that records events that occur in the real machine.
The events that are traced are:
External interruptions
SVC interruptions
Introduction to Debugging 501

Program interruptions • Machine check interruptions I/O interruptions • Free storage requests
Release of free storage • Entry into scheduler
Queue drop
Run user requests Start I/O Unstack I/O interruptions
Storing a virtual CSW Test I/O Halt Device • Unstack 10BLOK or TRQBLOK
NCP BTU (Network Control Program Basic Transmission Unit) • Spinning on a lock (attached processor or multiprocessor environment) SIGP (X'13') I · Clear Channel instruction IUCV communications SNA console communication services DIAGNOSE X'80' Start I/O fast release
Simulated I/O interruptions
Clear I/O An installation may optionally specify the size of the CP trace table. To do so, use
the SYSCOR macro instruction in module DMKSYS. Information on using this
macro instruction is in the VM / SP Planning Guide and Reference.
If an installation does not specify the trace table size or the size specified is smaller
than the default size, CP assigns the default size.
For each 256K bytes (or part thereof) of real storage available at IPL time, one
page (4096 bytes) is allocated to the CP trace table. Each entry in the CP trace
table is 16 bytes long. There are trace table entries for each type of event
recorded. The first byte of each trace table entry, the identification code, identifies
the type of event being recorded. Figure 67 on page 504 describes the format of
each type of trace table entry. The entry shown in Figure 67 for IUCV communi­
cations illustrates the general format of an IUCV entry. See the section "IUCV Trace Table Formats" for the formats of trace table entries for each IUCV func­
tion, and for a description of each field in the trace table entry.
In addition, some trace table entries are generated by ECPS:VM/370. The first bit
of these entries is set to 1 to indicate the entry was generated by the hardware
assist. For example, a trace table entry of type X'86' (FREE) is the same as an
entry of type X'06'. The only difference is that the first entry was generated by the
hardware assist.
The trace table is allocated by the main initialization routine, DMKCPI. The first
event traced is placed in the lowest trace table address. Each subsequent event is
recorded in the next available trace table entry. Once the trace table is full, events
are recorded at the lowest address (overlaying the data previously recorded there).
Tracing continues with each new entry replacing an entry from a previous cycle. Use the trace table to determine the events that preceded a CP system failure. An
abend dump contains the CP internal trace table and the pointers to it. The 502 VM/SP System Programmer's Guide