In large enterprises, the most complex and mission-critical business applications are entrusted to z/OS because of its unrivaled security and reliability. In any complex environment, however, unexpected errors and unplanned failures are bound to occur. When they do, there is an immediate need to understand the problem, find/fix the root cause, and prevent future errors. If you can apply automation to the remediation, you might classify as a Mainframe Champion, as defined in the latest BMC Mainframe Survey.

Fortunately, z/OS programmers have access to a large set of debugging tools, including dumps, traces, log records, and more. The ability to leverage these tools, particularly system dumps, is an important part of a programmer’s job description and a daily workflow.

As with all operating systems, z/OS is unique in both its ability to debug and the way debugging is performed. This was the focus of our November educational webinar, presented by DTS CTO Steve Pryor.

While it is a vast subject, there are aspects of Dumps and Debugging exclusive to z/OS, which is where Pryor spends most of the hour-long session. In-depth examples can be found in the slide deck from the presentation, available for download here.

What can an ABEND Tell You?

ABENDs (abnormal terminations) are of two types – User ABENDs (generated from an application or utility) and System ABENDs (caused by an error performing a system-related function). Debugging user abends requires an understanding of what the program is trying to do and what condition is indicated by the user abend, as specified in the program or utility documentation. System abends occur when a system function, such as obtaining virtual storage or other resources, fails, or when an instruction cannot correctly be executed. Typically, application programmers are called upon to resolve user abends, while system abends are addressed by the system programmer or storage administrator.

Most abends will be accompanied by a formatted dump, placed on either a SYSUDUMP or SYSABEND dataset, or for a larger system-related problem, a SYSMDUMP dataset . Many abends are related to supervisor call (SVC) instructions. In these cases, the last two digits of the abend code will identify the SVC. This can be a useful clue as to which type of system function failed and how to attack the problem.

In addition to SVCs, Program Exceptions indicate that the CPU cannot continue operation due to a problem with the instruction being executed. Program exceptions can be identified in many different ways, which are also covered in the webinar.

Common Error Types
What are the most common error types encountered in z/OS? From addressing errors and data errors to instruction errors and others, such as timing, loop and wait errors, each is identifiable if you know what you are looking for.

While an ABEND is a “hard” error, errors such as “incorrect output” are logic errors, which are more difficult to debug and require more in-depth knowledge of the application.

You’ve Identified the Error – now What?

Once the source of the error is known, what tools are available? The most common are discussed in the webinar, what they do and what to expect from them. This includes a brief conversation about sending the dump to IBM when necessary.

At closing, Pryor recommends a number of reference materials available and the types of issues covered in each.

More about Dumps and Debugging Tools in our webinar: “We’ve Got a Problem: An Introduction to z/OS® Dumps and Debugging Tools” is a 60-minute informative and educational look at an important topic in the mainframe space. If you weren’t able to attend, you can view it on-demand and download a copy of the slide deck used in the presentation by using this link.