When the amount of storage actually allocated is less than the amount
that should be allocated, the message DMSABN149T xxxx DOUBLEWORDS OF SYSTEM STORAGE HAVE BEEN DESTROYED appears on the terminal. If the amont of storage actually allocated is
greater than the amount that should be allocated, the message DMSABN150W nnn (HEX xxx) DOUBLEWORDS OF SYSTEM STORAGE WERE NeT RECOVERED appears on the terminal.
A DEBUGGING PROCEDURE: When a CMS abend occurs, use the DEBUG subcommands-or-Cp-Commands to examine the PSW and specific areas of low
storage. For instructions on how to use the debug commands, see "CMS Debugging Commands" in this section. For instructions on how to
use the CP commands, see an "An Overview of VM/370 Commands that can be Used for Debugging" in this section. See Figure 7 for a comparison of
the CP and CMS debugging facilities.
The following procedure may be useful in determining the cause of a CMS abend:
1. Display the PSi. (Use the CP DISPLAY command or CMS debug PSW subcommand.) Compare the PSW instruction address with the current CMS load map trying to determine the module that caused the abend.
The CMS storage-resident nucleus routines reside in fixed storage
locations.
Also check the interruption code in the PSW. 2. Examine areas of low storage. The information in low storage can
tell you more about the cause of the abend.
Contents Contains the name of the last module
storage via the LOADMOD command.
loaded into LASTTMOD Contains the name of the last module loaded into the
transient area .• LASTCMND Contains the name of the last command issued. PREVCMND Contains the name of the next-to-last command issued. LASTEXEC Contains the name of the last EXEC procedure. PREVEXEC Contains the name of the next-to-last EXEC procedure. DEVICE Identifies the device that
interrupt.
caused the last I/O The low storage areas examined depend on the type of abend. Once you have identified the module that caused the abend, examine
the specific instruction. Refer to the listing.
4. If you have not identified the problem at this time, take a dump by
issuing the debug DUMP subcommand. Refer to "Reading CMS Abend Dumps" for information on reading a CMS dump. If you can reproduce
the problem, try the CP or CMS tracing facilities.
22 IB! VM/370 Systs: Programmer's

Page of GC20-1807-7 As Updated Aug 1, 1979 by TNL GN25-0492
The abnormal termination of an operating system (such as as or DOS) running under VM/370 appears the same as termination of the operating
system on a real machine. Refer to publications for that operating system for debugging information. However, all of the CP debugging
facilities may be used to help you gather the information you need.
Because certain operating systems (OS/VS1, OS/VS2, and DOS/VS) manage
their virtual storage themselves, CP commands that examine or alter
virtual storage locations should be used only in virtual=real storage
space with OS/VS1, OS/VS2, and DOS/VS. If a dump was taken, it was sent to the virtual printer. Issue a CLOSE command to the virtual printer to have the dump print on the real
printer.
The VMDUMP command dumps virtual storage to a specified virtual
machine's reader spool file. Installations that have installed the
VM/Interactive Problem Control System (IPCS) Extensions program product
may use it to process the dump. Other installations may process the
dump with a user-written program.
If you choose to run a standalone dump program to dump the storage in
your virtual machine, be sure to specify the NOCLEAR option when you
issue the CP 1PL command. At any rate, a portion of your virtual
storage is overlaid by CP's virtual IPL simulationa If the problem can be reproduced, it may be helpful to trace the
processing using the CP TRACE command. Also, you can set address stops,
and display and alter registers, control words (such as the PSW), and
data areas. The CP commands can be very helpful in debugging because you
can gather information at various stages in processing. A dump is static
and represents the system at only one particular time. Debugging on a
virtual machine can often be more flexible than debugging on a real
machine. VM/370 may terminate or reset a virtual machine if a non-recoverable
machine check occurs in that virtual machine. Hardware errors usually
cause this type of virtual machine termination. The following message:
DMKMCH616I MACHINE CHECK; USER userid TERMINATED
appears on the processor console.
If the message:
DMKMCT621I MACHINE CHECK; AFFINITY SET OFF appears, then a machine check has occurred on the attached processor,
and the attached processor is no longer being used. The virtual machine
is placed into console function mode and can be made to continue
processing on the main processor by the entry of a BEGIN command.
Channel checks no longer cause the virtual machine to be reset as
they did in earlier releases of VM/370. If the problem appears to be
associated with attempts to recover from a channel check, see the
channel model-dependent functions described in the System Quig.§. Part 1. Debugging with VK/370 23