What tools and service aids are available?

This topic provides an overview of the tools and service aids in more detail. The tables that follow contain a brief description of each tool or service aid, some reasons why you would use it, and a reference to the topic or document that covers the tool or service aid in detail. (Most of the detailed information on tools and service aids is in this document.) The tools and service aids are covered in three tables; the dumps, traces, or service aids are listed in order by frequency of use.

Table 1 lists each type of dump and gives an overview of how they can be used.

Table 1. Description of dumps
Type of dump Description
ABEND Dump Use an ABEND dump when ending an authorized program or a problem program because of an uncorrectable error. These dumps show:
  • The virtual storage for the program requesting the dump.
  • System data associated with the program.
The system can produce three types of ABEND dumps, SYSABEND, SYSMDUMP, and SYSUDUMP. Each one dumps different areas. Select the dump that gives the areas needed for diagnosing your problem. The IBM® supplied defaults for each dump are:
  • SYSABEND dumps - The largest of the ABEND dumps, containing a summary dump for the failing program plus many other areas useful for analyzing processing in the failing program.
  • SYSMDUMP dumps - Contains a summary dump for the failing program, plus some system data for the failing task. SYSMDUMP dumps are the only ABEND dumps that you can format with IPCS.
  • SYSUDUMP dumps - The smallest of the ABEND dumps, containing data and areas only about the failing program.

Reference: See ABEND dump for detailed information.

Transaction Dump (IEATDUMP) Similar to SNAP dumps, an application can issue an IEATDUMP macro to dump virtual storage areas of interest if the application is running. However, the result is an unformatted dump that must be analyzed using IPCS. See Transaction dump for details.
SNAP Dump Use a SNAP dump when testing a problem program. A SNAP dump shows one or more areas of virtual storage that a program, while running, requests the system to dump. A series of SNAP dumps can show an area at different stages in order to picture a program's processing, dumping one or more fields repeatedly to let the programmer check intermediate steps in calculations. SNAP dumps are preformatted, you cannot use IPCS to format them.

Note that a SNAP dump is written while a program runs, rather than during abnormal end.

Reference: See SNAP dump for detailed information.

Stand-Alone Dump Use a stand-alone dump when:
  • The system stops processing.
  • The system enters a wait state with or without a wait state code.
  • The system enters an instruction loop.
  • The system is processing slowly.

These dumps show central storage and some paged-out virtual storage occupied by the system or stand-alone dump program that failed. Stand-alone dumps can be analyzed using IPCS.

Reference: See Stand-alone dump for detailed information.
SVC Dumps SVC dumps can be used in two different ways:
  • Most commonly, a system component requests an SVC dump when an unexpected system error occurs, but the system can continue processing.
  • An authorized program or the operator can also request an SVC dump when they need diagnostic data to solve a problem.

SVC dumps contain a summary dump, control blocks and other system code, but the exact areas dumped depend on whether the dump was requested by a macro, command, or SLIP trap. SVC dumps can be analyzed using IPCS.

Reference: See SVC dump for detailed information.

Table 2 lists each type of trace and gives an overview of how they can be used.

Table 2. Description of traces
Trace Description
Component Trace Use a component trace when you need trace data to report an MVS™ component problem to the IBM Support Center. Component tracing shows processing within an MVS component. Typically, you might use component tracing while recreating a problem.

The installation, with advice from the IBM Support Center, controls which events are traced for a component.

Reference: See Component trace for detailed information.
GFS Trace Use GFS trace to collect information about requests for virtual storage through the GETMAIN, FREEMAIN, and STORAGE macro.

Reference: See GETMAIN, FREEMAIN, STORAGE (GFS) trace for detailed information.

GTF Trace Use a GTF trace to show system processing through events occurring in the system over time. The installation controls which events are traced.

GTF tracing uses more resources and processor time than a system trace. Use GTF when you are familiar enough with the problem to pinpoint the one or two events required to diagnose your system problem. GTF can be run to an external data set as well as a buffer.

Reference: See The Generalized Trace Facility (GTF) for detailed information.

Master Trace Use the master trace to show the messages most recently issued. Master trace is useful because it provides a log of these messages in a dump. These can be more pertinent to your problem than the messages accompanying the dump itself.

Reference: See Master trace for detailed information.
System Trace Use system trace to see system processing through events occurring in the system over time. System tracing is activated at initialization and, typically, runs continuously. It records many system events, with minimal detail about each. The events traced are predetermined, except for branch tracing.

This trace uses fewer resources and is faster than a GTF trace.

Reference: See System trace for detailed information.

Table 3 describes the service aids and how they can be used.

Table 3. Description of service aids
Service Aid Description
AMATERSE Use the AMATERSE service aid to create a compact image of diagnostic data sets. The compact image helps to use less space while retaining materials and prepare for efficient transmission of materials from one site to another, such as to send the materials to IBM support.
AMBLIST Use AMBLIST when you need information about the content of load modules and program objects or you have a problem related to the modules on your system. AMBLIST is a program that provides lots of data about modules in the system, such as a listing of the load modules, map of the CSECTs in a load module or program object, list of modifications in a CSECT, map of modules in the LPA (link pack area), and a map of the contents of the DAT-on nucleus.

Reference: See AMBLIST: Map load modules and program objects for detailed information.

Common Storage Tracking Use common storage tracking to collect data about requests to obtain or free storage in CSA, ECSA, SQA, and ESQA. This is useful to identify jobs or address spaces using an excessive amount of common storage or ending without freeing storage.

Use RMF™ or the IPCS VERBEXIT VSMDATA subcommand to display common storage tracking data.

References:
DAE Use dump analysis and elimination (DAE) to eliminate duplicate or unneeded dumps. This can help save system resources and improve system performance.

Reference: See Dump suppression for detailed information.

IPCS Use IPCS to format and analyze dumps, traces, and other data. IPCS produces reports that can help in diagnosing a problem. Some dumps, such as SNAP and SYSABEND and SYSUDUMP ABEND dumps, are preformatted, and are not formatted using IPCS.

Reference: See z/OS MVS IPCS User's Guide for detailed information.

Logrec Data Set Use the logrec data set as a starting point for problem determination. The system records hardware errors, selected software errors, and selected system conditions in the logrec data set. Logrec information gives you an idea of where to look for a problem, supplies symptom data about the failure, and shows the order in which the errors occurred.

Reference: See Recording logrec error records for detailed information.

SLIP Traps Use serviceability level indication processing (SLIP) to set a trap to catch problem data. SLIP can intercept program event recording (PER) or error events. When an event that matches a trap occurs, SLIP performs the problem determination action that you specify:
  • Requesting or suppressing a dump.
  • Writing a trace or a logrec data set record.
  • Giving control to a recovery routine.
  • Putting the system in a wait state.

Reference: See the SLIP command in z/OS MVS System Commands for detailed information.

SPZAP Use the SPZAP service aid to dynamically update and maintain programs and data sets. For problem determination, you can use SPZAP to:
  • Fix program errors by replacing a few instructions in a load module or member of a partitioned data set (PDS).
  • Insert an incorrect instruction in a program to force an ABEND or make a SLIP trap work.
  • Alter instructions in a load module to start component trace.
  • Replace data directly on a direct access device to reconstruct a volume table of contents (VTOC) or data records that were damaged by an input/output (I/O) error or program error.

Reference: See SPZAP: Modify data in programs and VTOCs for detailed information.
Parent topic: Selecting tools and service aids