label code (reg) TYPCALL=SVC TYPCALL=BALR is any valid Assembler language label.
is the abnormal code (0 through- FFP) that appears in the DMSABN148T system termination message. is the register containing the abnermal termination
code.
specifies how control is passed to the abnormal
termination routine, DMSABN. Routines that do not
reside in the nucleus should use TYPCALL=SVC to
generate CMS SVC 203 linkage. Nucleus-resident
routines should specify TYPCALL=EALR so that a
direct branch to DMSABN is generated.
If a CMS SVC handler abnormally terminates, that routine can set an
abend flag and store an abend code in NUCON (the CMS nucleus
constant area). After the SVC handler has finished processing, the
abend condition is recognized,. The DMSABN abend routine types the
abend message, DMSABN148T, with the abend cede stored in NUCON. WHAT TO DO £MS TERMINATES: After an abend, two courses
of actIon are available in CMS. In addition, by signalling attention,
you can enter the CP command mode and use CP's debugging facilities. Two courses of action available in CMS are:
1. Issue the DEBUG command and enter the debug environment. After
using all the DEBUG subco •• ands that you wish, exit from the debug
environment. Then, either issue the RETURN command to return to DMSABN so that abend recovery will occur, cr issue the GO command
to resume processing at the point the abend occurred.
2. Issue a CMS command other than DEBUG and the abend routine, DMSABN, performs its abend recovery and then passes control to the DMSINT routine to process the command just entered.
The abend recovery function performs the follcwing: The SVC handler, DMSITS, is reinitialized, and all stacked save
areas are released.
2. "FINIS * * *" is invoked by means of SVC 202, to close all files,
and to update the .aster file directory.
3. If the EXECTOR module is in real storage, it is released.
4. All link blocks allocated by DMSSLN are freed.
5. All FCB pointers are set to zero.
6. All user storage is released.
7. The amount of system free storage which computed. This figure is compared with the amount
that is actually allocated.
8. The console input stack is purged.
be al:;"ocated is
of free storage Part 1. Debugging with VM/370 21

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