Dumps

SVC dump
An SVC dump provides a representation of the virtual storage for the system when an error occurs. Typically, a system component requests the dump from a recovery routine when an unexpected error occurs. However, an authorized program or the operator can also request an SVC dump when diagnostic dump data is needed to solve a problem. Complete details are found in SVC dump in z/OS MVS Diagnosis: Tools and Service Aids.
Transaction dump
A transaction dump provides a representation of the virtual storage for an address space when an error occurs. Typically, an application requests the dump from a recovery routine when an unexpected error occurs. Complete details are found in Transaction dump in z/OS MVS Diagnosis: Tools and Service Aids
Abend dump
An ABEND dump shows the virtual storage predominately for an unauthorized program. To produce a dump when one is requested for an error, a JCL DD statement of SYSUDUMP, SYSABEND or SYSMDUMP must be included in the input job stream. See z/OS MVS JCL Reference for more information. An operator can also request an ABEND dump while ending a program, an address space, or canceling a job. There are three types of abend dumps:
  • SYSMDUMP – Is an unformatted dump that requires IPCS to view and format. Unformatted dumping is sometimes more efficient because only the storage requested is written to the data set, which means the application can capture diagnostic data and be brought back online faster.
  • SYSABEND – The largest of the ABEND dumps, is a pre-formatted dump containing a summary dump for the failing program plus many other areas useful for analyzing processing in the failing program.
  • SYSUDUMP – The smallest of the ABEND dumps, containing data and areas only about the failing program.
Complete details are found in Abend dump in z/OS MVS Diagnosis: Tools and Service Aids.
SNAP dump
A SNAP dump shows virtual storage areas that a program, while running, requests the system to dump. A SNAP dump, therefore, is written while a program runs, rather than during abnormal end. The program can ask for a dump of as little as a one byte field to as much as all of the storage assigned to the current job step. The program can also ask for some system data in the dump. A SNAP dump is especially useful when testing a program. Complete details are found in Transaction dump in z/OS MVS Diagnosis: Tools and Service Aids
Stand-Alone dump
The other tools discussed in this chapter are used to collect data for individual work units on a system or a subset of components on a system. A stand-alone dump is used to collect diagnostic information about the entire system. Stand-alone dumps are not produced by z/OS® but by an either the IPCS SADMP dump data set utility or the AMDSADDD REXX utility. After a stand-alone dump is taken, because the system cannot resume usual processing, the IPL is of the stand-alone dump instead of z/OS.

The stand-alone dump program produces a stand-alone dump of storage that is occupied by either:

  • A system that is stopped. For example, your installation has a wait state with no processing, so you must capture a stand-alone dump to diagnosis it.
  • A stand-alone dump program that failed. Either the stand-alone dump program dumped itself — a self-dump —, or the operator loaded another stand-alone dump program to dump the failed stand-alone dump program.

The stand-alone dump program and the stand-alone dump together form what is known as the stand-alone dump service aid. The term stand-alone means that the dump is performed separately from usual system operations and does not require the system to be in a condition for normal operation. It is essential to perform a store status before taking a stand-alone dump because the program gets loaded over storage that might be needed in the dump.

For more information: