By Patty Little, Programmer at IBM Corporation
At the recent SHARE in Orlando, Patty Little was awarded Best Session for her presentation, “SLIP Trap Bootcamp, Part 1 of 2” held during SHARE in Seattle. Congratulations, Patty!
Wouldn't it be great if we lived in a z/OS world where every time a software problem was experienced, the system automatically generated the perfect documentation needed to drive that problem to resolution? While this is a goal that IBM continually strives for, unfortunately this debugging utopia has not yet been achieved. However, the good news is that the z/OS debugger is armed with a powerful diagnostic tool, which greatly improves the odds of gathering the ideal diagnostic documentation should the problem reoccur. This tool is called Serviceability Level Indicator Processing (SLIP), and its purpose is to provide the ability to trap a specific problem and generate the precise documentation needed to resolve the problem.
The power of SLIP comes from its versatility. It offers a broad set of parameters that provide the ability to:
- Trap a variety of problem events;
- Filter the event being trapped based on the precise environmental conditions that characterize the problem;
- Generate diagnostic documentation specifically tailored to that problem; and
- Take action to protect the system from impact from the problem.
The events that can be trapped by SLIP processing fall into two categories: software events and hardware events. The part of SLIP processing that monitors hardware events is known as Program Event Recording (PER). Software events that can be trapped include abend completion codes, reason codes and messages. Hardware events that can be monitored by PER include storage alteration (SA) of a specified address range within an address space or data space, instruction fetch (IF) within a specified range of storage and successful branch (SB) to or within a specified range of storage. As an example of SLIP’s flexibility, ranges of storage being monitored can be hardcoded, specified as an indirect address or indicated by module name and offset.
SLIP offers a wide array of filtering options, allowing for precise definition of the environment for which documentation is to be gathered. Through the JOBNAME and ASID keywords, events can be narrowed down to those which occur in a particular job or address space. Additionally, SLIP provides the DATA keyword which allows comparisons to be made against storage or register content at the time the event is detected to ensure that the environmental data is consistent with the conditions being trapped. A less commonly known but powerful option is the MODE keyword which allows for filtering on factors related to the execution environment, such as execution key, problem state, disablement, spin locks held, SRB mode and more.
The SLIP ACTION keyword provides for the generation of various types of diagnostic data. The most common action to request on a SLIP is an SVC dump. There are supporting SLIP options that allow for specification of which address spaces and data spaces are to be included in the dump. SLIP provides an option to indicate what general areas of storage are to be dumped (e.g., SQA, CSA, RGN), as well as options that allow for explicit identification of specific ranges of storage to be included in the dump.
Another common action to be requested in a SLIP is GTF tracing. As with SVC dump processing, SLIP offers the capability of explicitly identifying ranges of storage to be traced. Less commonly known SLIP actions include the ability to force recording of an error to LOGREC and to write a system trace entry that can include up to six words of tailored data.
The power of SLIP goes far beyond its ability to gather documentation. With its REFBEFOR and REFAFTER action keywords, SLIP can actually be used to repair damaged areas of storage or to change register content of an executing program. But with this power comes danger. When used incorrectly, this same power can take down a system, so these SLIP options are to be used with care and under the guidance of someone knowledgeable in the coding of SLIP traps.
Perhaps the most significant reason that SLIP is the powerful tool that it is today is because z/OS development has been, and continues to be, committed to enhancing it. Dynamic PER capability was added years ago to allow a SLIP PER trap monitoring for a particular event to enable a new PER trap when that event occurs. Many a control block overlay has been successfully caught thanks to this robust and versatile design. The previously noted REFBEFOR/REFAFTER options provide another example of a SLIP enhancement that has proved its worth time and time again. More recently the SUBTRAP action was introduced, providing a simulated IF/THEN/ELSE capability for PER SLIP traps such that different actions can be taken under different conditions. And coming in z/OS R2.2, SLIP processing will be able to issue commands.
These are just a few examples of the innovative features that make SLIP the “go-to, can-do” debugging tool on the z/OS platform. It is a powerful and indispensable weapon in the z/OS debugger’s arsenal.
Patty Little started her IBM career 30 years ago. After a short stint as an RTM developer, she took a six-month temporary assignment in z/OS Level 2 software service. Twenty-seven years later, she is still there, enjoying the challenge of problem diagnosis in the Supervisor, RTM, SDUMP and SLIP components.