Nucleus Load Map
Load Map
D T2CF158.10 «<--Display where the interrupt happened
2CF150 C01858CO DOF81BFF 000007F6 50C3D9C1 * ..... 8 ..... 6&CRA* 2CF160 E2C8189F 47FOC1E2 45EOAAB8 078745EO *SH ... OAS ........ * B 2CF15A «<--Continue as if no interrupt happened
Each time the eMS resident nucleus is loaded on a DASD and an IPL can be per­
formed on that DASD, a load map is produced as a printer spool file. Save this
load map. It lists the virtual storage locations of nucleus-resident routines and
work areas. Transient modules are not included in this load map. When debugging'
eMS, you can locate routines using this map. For information on obtaining a load
map, see "Generating a eMS Nucleus" in the VM/SP Installation Guide.
The load map of a disk-resident command module contains the location of control
sections and entry points loaded into storage. It may also contain certain messages
and card images of any invalid cards or replace cards that exist in the loaded files.
The load map is contained in the third record of the MODULE file.
This load map is useful in debugging. When using the Debug environment to ana­
lyze a program, use the program's load map to help in displaying information.
There are two ways to get a load map.
1. When loading relocatable object code into storage, make sure that the MAP
option is in effect when the LOAD command is issued. Since MAP is the
default option, just be sure that NOMAP is not specified. A load map is then
created on the primary disk each time a LOAD command is issued.
2. When generating the absolute image form of files already loaded into storage,
make sure that the MAP option is in effect when the GENMOD command is
issued. Since MAP is the default option, just be sure that NOMAP is not spec­
ified. Issue the MODMAP command to type the load map associated with the
specified MODULE file on the terminal. The format of the MODMAP com­
mand is: I MODmap
where:
filename
filename
is the module whose map is to be displayed. The file type must be MODULE. Reading eMS Abend Dumps
If an abend dump is desired when eMS abnormally terminates, the terminal opera­
tor must enter the DEBUG command and then the DUMP subcommand. The
dump formats and prints:
General registers
Debugging With eMS 529

Extended control registers
Floating-point registers
Storage boundaries with their corresponding storage protect key
Current PSW Selected storage Storage is printed in hexadecimal representation, eight words to the line, with
EBCDIC translation at the right. The hexadecimal storage address corresponding
to the first byte of each line is printed at the left.
When CMS can no longer continue, it abnormally terminates. To debug CMS, first
determine the condition that caused the abend and then find why the condition
occurred. In order to find the cause of a CMS problem, you must be familiar with
the structure and functions of CMS. Refer to "Part 2: Conversational Monitor System (CMS)" for functional information. The following discussion on reading CMS dumps refers to several CMS control blocks and fields in the control blocks.
Refer to the VM / SP Data Areas and Control Block Logic, Volume 2 for details on CMS control blocks. Figure 71 on page 531 shows the eMS control block
relationships. You also need a current CMS nucleus load map in order to analyze
the dump. 530 VM/SP System Programmer's Guide