Setting traps with SLIP, king of the mainframe debugging tools

One of the mainframe's distinguishing characteristics is its extensive debugging toolkit. One of the very best – and to my knowledge unique – mainframe debugging tools is SLIP.

 When distributed platform administrators hit a nasty problem, they are often left guessing until they contact the vendor. Systems programmers, on the other hand, have dumps, traces and online monitors that can peer into the very heart of the system. That's where serviceability level indication processing (SLIP) comes into play.  

SLIP: King of the mainframe debugging tools
The SLIP tool is a combination of hardware and software components that can interrupt a processor and record diagnostic data when designated conditions occur. A condition may be an error, system state or storage value. The information collected by SLIP can, in turn, be fed into other mainframe tools for analysis.

SLIP traps, set with the SET SLIP system command, consist of three parts: the trap, the conditions and the action.

Setting the trap
There are two types of traps. The first and simplest are error traps that capture various errors, abnormal ends (ABENDs), completion codes and console messages.  This kind of trap is useful when you need information at the time of an error before any recovery routines execute.

The second type, program Event recording (PER) traps, is more interesting; these attempt to catch situations that aren't necessarily errors yet. They might also collect information about an error whose origin may be obscured by subsequent events. An example would be a storage overlay that leads to another overlay that eventually causes an operation exception (0C1). Don't laugh; I've seen one. To squish that bug you need to see the cause of the original overlay that triggered the second.

 The three types of PER traps are:

1. Instruction Fetch (IF) traps spring when the CPU gets an instruction for execution from a designated address. This may be useful for capturing the flow of a program or getting a snapshot of storage at a certain point in its logic.
2. Storage Alteration (SA) traps fire when an instruction sets storage area to a certain value. This one is particularly handy for debugging storage overlays.
3. SLIP recognizes a Successful Branch (SBT) condition when the CPU executes a successful branch instruction within the range of addresses. This trap would be useful for understanding the conditions when a program goes down an unusual path or exits a loop.

Note that the SLIP documentation often refers to error trap types as non-PER traps.

Conditions for springing the SLIP trap
Getting the conditions right is the hardest part of setting a SLIP trap. If the conditions are too loose, it might spring at the wrong time. If it is off by so much as a bit, it may never fire. Due to the hardware overhead involved in PER traps, unduly broad conditions can seriously affect processor performance. Note that all of the qualifiers in the condition must be met for the trap to spring.

The easiest qualifiers are the job's name (JOBNAME) or address space ID (ASID). JOBNAME may be the better option as a job's or started task's ASID may change between runs. You can also monitor address spaces using a specific job step program (JSPGM).

Besides specifying the job, there are other parameters for designating the range of addresses that must contain the instruction to raise the condition. For instance, if the operating system manages the program to be monitored, one can use the private module (PVTMOD), LPA module (LPAMOD) or nucleus module (NUCMOD) to refer to the program by name. All the above parameters include sub-parameters for specifying ranges inside of the module. If the module isn't managed by the operating system – CICS, I'm looking at you – the ADDRESS parameter supplies the range containing the instructions where the error occurs.

To set SA traps you must specify parameters designating storage areas and the values they should be set to for the trap to spring.

The SLIP trap springs into action
Lastly, the SLIP trap must know what to do once the condition is met. The type of action depends on the error and the amount of disruption you're willing to suffer.

Perhaps the most invasive is the WAIT action that stores error data and places the system in a wait state. At that point, a programmer can examine storage contents through the hardware console or take a stand-alone dump (SADUMP). After the WAIT, the system can restart as long as the systems programmer didn't take any actions to spoil it.

A little less gut-wrenching is the SVC dump action. In this case, the address space under examination halts until dump services captures memory. The dumped information may also include any needed data spaces or companion address spaces. Because these dumps can be very large, the System Data (SDATA) parameter manages what goes into the dump.

The system tracing options are useful for capturing long, slowly building errors or for processes that cannot be disrupted. Here the SLIP writes selected information into a system trace record when the trap fires. The system trace information can be collected to disk dataset using another mainframe debugging tool, Generalized Trace Facility (GTF).

You can also do nothing. SLIP has a series of actions for that. For instance, many shops use the NODUMP action to suppress dumps for common ABEND's that don't require dumps.

As far as mainframe debugging tools go, SLIP can't be beat. Next time, we'll delve into the arcane, obscure SET SLIP command.

ABOUT THE EXPERT: Robert Crawford has been a systems programmer for 29 years. While specializing in CICS technical support, he has also worked with VSAM, DB2, IMS and other mainframe products. He has programmed in Assembler, Rexx, C, C++, PL/1 and COBOL. The latest phase in his career finds him an operations architect responsible for establishing mainframe strategy and direction for a large Insurance company. He lives with his family and works in south Texas.