LASTEXEC PREVEXEC DEVICE
Contains the name of the last CMS EXEC procedure.
EXEC 2 and System Product Interpreter do not update
this field.
Contains the name of the next-to-Iast CMS EXEC pro­
cedure. EXEC 2 and System Product Interpreter do not
update this field.
Identifies the device that caused the last I/O interrupt.
The low storage areas examined depend on the type of
abend.
3. 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 prob­
lem, try the CP or CMS tracing facilities.
Virtual Machine Abend (Other than eMS)
The abnormal termination of an operating system (such as OS or DOS) running
under VM/SP 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/VSl, 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/VSl, OS/VS2, and DOS/VS. If a dump was taken, it was sent to the virtual printer. Issue a CLOSE com­
mand 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 stand-alone dump program tobdump the storage in your
virtual machine, be sure to specify the NOCLEAR option when you issue the CP IPL command. At any rate, a portion of your virtual storage is overlaid by CP's virtual IPL simulation.
If the problem can be reproduced, it may be helpful to trace the processing
using the CP TRACE or CP PER commands. 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 repres­
ents the system at only one particular time. Debugging on a virtual machine
can often be more flexible than debugging on a real machine. VM/SP 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
Introduction to Debugging 481
Unexpected Results
Unexpected Results in CP
appears on the processor console.
If the message:
DMKMCT621I 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
early 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 VM / SP Planning Guide and Reference.
The type of errors classified as unexpected results vary from operating systems
improperly functioning under VM/SP to printed output in the wrong format.
If an operating system executes properly on a real machine but does not exe­
cute properly with VM/SP, a problem exists. Also, if a program executes
properly under control of a particular operating system on a real machine but
does not execute correctly under the same operating system with VM/SP, a
problem exists.
First, there are conditions (such as time-dependent programs) that CP does not
support. Be sure that one of these conditions is not causing the unexpected
results in CPo Refer to the VM/SP Planning Guide and Reference for a list of
the restrictions.
Next, be sure that the program and operating system running on the virtual
machine are the same as those that ran on the real machine. Check for:
The same job stream
The same copy of the operating system (and program)
The same libraries
If the problem still is not found, look for an I/O problem. Try to reproduce the
problem, while tracing all CCWs, SIOs, and interrupts via the CP TRACE or
CP PER commands. Compare the real and virtual CCWs from the trace. A
discrepancy in the CCWs may indicate that one of the CP restrictions was vio­
lated, or that an error occurred in the Control Program. Unexpected Results in a Virtual Machine
482 VM/SP System Programmer's Guide
When a program executes correctly under control of a particular operating sys­
tem on a real machine but has unexpected results executing under control of
the same operating system with VM/SP, a problem exists. Usually you will
find that something was changed. Check that the job stream, the operating sys­
tem, and the system libraries are the same.
If unexpected results occur (such as TEXT records interspersed in printed out­
put), you may wish to examine the contents of the system or user disk files. Non-CMS users may execute any of the utilities included in the operating sys-
Previous Page Next Page