Abends

All programs can abnormally end (ABEND) at one time or another. Most applications have some sort of recovery processing to try to avoid actually terminating the application. VTAM® and TCP/IP are fairly typical in this respect, and usually attempt to recover before they terminate.

If there is no other indication of a problem, check whether a dump was taken. For an ABEND0C4 or ABEND0A9, usually an SVC dump of the address space is taken. In general, for complete diagnosis of a VTAM or TCP/IP problem, CSA must be dumped.

From the dump, the location of the failure can be determined. This information is often included in a dump summary, formatted at the top of the dump. This information can be used to check in INFOSYS (if INFOSYS is available at your site) for known problems in this area. If INFOSYS is not available or a fix cannot be found, then contacting the IBM® Support Center or IBM Service with the following information often resolves the problem.

  • Abend code
  • Failing module name

This information can be gathered from the dump, or sometimes from the console log messages that are issued at abend time. If the module name is not included in the dump summary information, then locate the PSW address (second word of the PSW) in the dumped storage. Work backwards through the dump (towards zero) until an eyecatcher is encountered. The eyecatcher includes the module name. VTAM module names all start with 'IST'. TCP/IP module names all start with 'TC'. (The eyecatcher is alphanumeric data that is written at the front of the module. It can be read from the EBCDIC conversion area on the right side of the dump. For example, in the dump, the module name could be x'C9E2E3D6D9C6C2C1'. In the EBCDIC conversion area, you would see, 'ISTORFBA'.)

  • Offset of PSW into this module

Usually, before the eyecatcher is an x'47....' instruction, which branches around the eyecatcher and into the module code. This instruction is the start of the module. Subtract the address of this instruction from the PSW address to determine the offset. Remember that this is in hex, not decimal. If the module is in LPA, an LPA map can be generated. The LPA map indicates the start of the module. Work out the offset by using this start address.

  • Latest maintenance to hit this module

This information can be gathered either from the dump, or by using SMP/E. Again, find the eyecatcher in the dump. This information normally includes an assembly date and the latest PTF to be applied to the module. Write down both the assembly date and the PTF number.

  • Registers at the time of the abend

This information can be taken either from the console log or the dump. Register 15 sometimes contains a return code that helps problem diagnosis; for example, on an ABEND0A9.

  • Recent maintenance that is applied

PTFs or APARs that were recently applied might contribute to the circumstances that caused the problem.

  • Recent changes to the system

In general, problems occur only after changes are made to a system. Keep an open mind when you look at recent changes. Even changes that appear unconnected can be the cause of the problem.

  • Frequency of the abend

How often the abend occurred can give some idea of the magnitude of the problem. If the abend is occurring frequently, it indicates that something fairly fundamental is wrong. If it is a one-time occurrence, it might be an obscure set of circumstances that caused the problem.

IBM Support might request more information. The console log around the time of the abend and the dump should be kept in case further diagnosis of the problem requires more information from the dump.

Abends in VTAM

VTAM abends fall into two categories: those where there is an abend in the VTAM address space, and those where the abend occurs in the VTAM code in a user (like DDF) address space.

The link pack area (LPA) has VTAM code, which is accessible by all address spaces. VTAM has its control blocks in the common service area (CSA). These too, are accessible by all address spaces. In this way, each address space can do VTAM processing in its own address space. In general, this is I/O processing: sending and receiving data across the application interface. In this way the DDF address space (ssnmDIST) might abend in a VTAM module and cause a dump of the DDF address space (ssnmDIST) to be taken.

VTAM has several z/OS® abend codes that are reserved for VTAM's use only. These are ABEND0A7, 0A8, 0A9, 0AA, 0AB, 0AC, and 0AD. The most commonly occurring of these abends is ABEND0A9. The value in general-purpose register 15 (GPR15) gives some indication of the problem.

Sometimes the ABEND0A9 is preceded by an ABEND0C4. Always look for an indication of a previous error. This could be another abend, or an error message to the user or the console. It is not necessarily a VTAM message, and might not occur immediately before the abend. LOGREC is a good source for finding abends that might have been missed on the console by the operators. It is important to start diagnosing a problem when the first sign of trouble occurs, as later problems are often part of the aftermath of the original problem. Recovery routines normally try the failing process again before eventually terminating.