Using the linkage stack to identify the failing module

You can sometimes use the technique described in this section to gather the information that the IBM® Support Center needs to resolve the CICS® system abend. However, you should normally use the summary information presented in the formatted output for the kernel domain storage areas.

This method is only valid if the abend has occurred in a module or subroutine that has a kernel linkage stack entry. This is the case only where the module or subroutine has been invoked by one of these mechanisms:

Routines that have been invoked by assembler language BALR instructions do not have kernel linkage stack entries. Having found which task was in error from the kernel’s task summary (see Finding which tasks are associated with the error), you need next to find out which module was in error. The module name is one of the things you need to give the IBM Support Center when you report the problem to them.

Find the task number of the task in error from the KE_NUM column, and use this as an index into the linkage stack entries. These are shown in the dump after the task summary.

Figure 3 shows a typical kernel linkage stack:

Figure 3. Example of a kernel linkage stack showing a task in error
KE_NUM @STACK   LEN  TYPE ADDRESS  LINK REG OFFS ERROR NAME
0031   0520A020 0120 Bot  84C00408 84C006D8 02D0       DFHKETA
0031   0520A140 01F0 Dom  84C0F078 84C0F18E 0116       DFHDSKE
0031   0520A330 0370 Dom  84CAA5A8 84CAACC2 071A       DFHXMTA
0031   0520A6A0 0330 Dom  84F25430 84F25CF6 08C6       DFHPGPG
                     Int     +00CC 84F254B6 0086       INITIAL_LINK
0031   0520A9D0 03C0 Dom  84F6C230 84E5DC40 0000       DFHAPLI1
                     Int     +0EEA 84F6C66E 043E       CICS_INTERFACE
0031   0520AD90 0108 Sub  0230B400 8230B8CA 04CA       DFHEIQSP
0031   0520AE98 0290 Sub  82136D90 82137178 03E8 *YES* DFHLDLD
       0520B128      Int     +08FC 82136F26 0196       LDLD_INQUIRE
       0520B128      Int     +128E 821376CE 093E       CURRENT_GET_NO_WAIT
0031   0520B128 0F70 Dom  84C6F8E0 84C72EA6 35C6       DFHMEME
                     Int     +2CB6 84C6FA4E 016E       SEND
                     Int     +1486 84C72684 2DA4       CONTINUE_SEND
                     Int     +350E 84C70DE4 1504       TAKE_A_DUMP_FOR_CALLER
0031   0520C098 03D0 Dom  84C52458 84C52F52 0AFA       DFHDUDU
                     Int     +08F4 84C5254A 00F2       SYSTEM_DUMP
                     Int     +1412 84C53212 0DBA       TAKE_SYSTEM_DUMP

The TYPE column in the example can contain any of the following entries:

Bot
This marks the first entry in the stack.
Dom
This marks a stack entry caused by a domain call.
Sub
This marks a stack entry caused by a subroutine.
Lifo
This marks a stack entry caused by a LIFO module.
Int
This marks a call to an internal procedure identified to the kernel.

A linkage stack for a task represents the sequence in which modules and subroutines have been called during execution of a task. It provides a valuable insight into the sequence of events up until the time of failure, and it also flags any program or subroutine that was executing when the error was detected.

The modules and subroutines are shown in the listing in the order in which they were invoked, so the first module you see is at the bottom of the stack, and the second module is next from bottom. You often see DFHKETA and DFHDSKE, respectively, in these two positions.

The last module or subroutine in the listing is at the top of the stack, and it represents the last call that was made before the dump was taken. Assuming that the system abend caused the dump to be taken, this is likely to be a routine associated with dump domain.

In the example shown, program DFHLDLD is shown to be in error. In this case, DFHLDLD is the module name that you would need to report to the IBM Support Center, together with the other information described in Using the PSW to find the offset of the failing instruction.

Note:
If module DFHAPLI is flagged in error, consider first whether an application is to blame for the failure. DFHAPLI is the Application Language Interface Program, and it is on the linkage stack whenever an application is being executed. If an application is the cause of the error, it is your responsibility to correct the problem.

Using the PSW to find the offset of the failing instruction

You can calculate the offset of the failing instruction from the PSW, although in practice you seldom need to because the offset is quoted in the storage report for the task. If you are not sure of the format of the PSW, or how to calculate the offset, see the z/Architecture Principles of Operation manual.

The Support Center also needs to know the instruction at the offset. Locate the address of the failing instruction in the dump, and find out what instruction is there. It is sufficient to give the hex code for the instruction, but make sure you quote as many bytes as you found from the PSW instruction length field.

Identify also the abend type from the program interruption code, so that you can report that, too. It might, for example, be ‘protection exception’ (interruption code 0004), or ‘data exception’ (interruption code 0007).

Finding the PTF level of the module in error

The IBM Support Center needs to know the PTF level of any module reported to them as being in error. You can find this in the loader domain program storage map summary, which you can get using the dump formatting keyword LD.

Figure 4 shows some entries from a typical program storage map summary.

Figure 4. Part of the loader domain program storage map summary
==LD: PROGRAM STORAGE MAP
PGM NAME ENTRY PT  CSECT   LOAD PT. REL. PTF LVL. LAST COMPILED  COPY NO. USERS     LOCN  TYP ATTRIBUTE R/A MODE APE ADDR
                                                                                                        OVERRIDE
DFHCSA   80049810 DFHKELCL 00049000 520  UQnnnnn  12/11/96 10.09    1       1       CDSA  RPL RESIDENT   -    -  07F16730
                  DFHKELRT 00049380 520  UQnnnnn  12/11/96 10.24
                  DFHCSA   00049608 0520 UQnnnnn  I  01/04 14.49
                  DFHCSAOF 00049AB8 0520 UQnnnnn  I  01/04 14.49
                  DFHKERCD 00049FE0 520  UQnnnnn  11/14/96 18.48
                  DFHKERER 0004A1B8 520  UQnnnnn  11/14/96 18.49
                  DFHKERRI 0004ABC0 520  UQnnnnn  02/05/97 08.23
                  DFHKESFM 0004AF58 520  UQnnnnn  12/11/96 10.25
                  DFHKESGM 0004B330 510  UQnnnnn  10/21/96 16.30
DFHTCP   8004D020 DFHTCP   0004D000 0520 UQnnnnn  I  11/12 10.10    1       1       CDSA  RPL RESIDENT   -    -  07F5C430
                  DFHTCORS 0004D278 0520 UQnnnnn  I  11/12 10.10
                  DFHTCCOM 0004D538 0520 UQnnnnn  I  11/12 10.10
                  DFHTCCSS 0004D8B0 0520 UQnnnnn  I  11/12 10.10
                  DFHTCTI  0004DA28 0520 UQnnnnn  I  11/12 10.10
                  DFHTCSAM 0004DAB0 0520 UQnnnnn  I  11/12 10.10
                  DFHTCAM  0004DEB8 0520 UQnnnnn  I  11/12 10.10
                  DFHTCTRN 0004ED30 0520 UQnnnnn  I  11/12 10.10
DFHTCTDY 0004FA30 DFHTCTDY 0004FA10 0520 UQnnnnn  I  04/02 19.16    1       1       CDSA  RPL RESIDENT   -    -  07F5C530
Note:
Entries made in the R/A MODE OVERRIDE columns are the value of the RMODE and AMODE supplied on the DEFINE_PROGRAM call for that program. If a REQUIRED_RMODE or REQUIRED_AMODE is not specified, a - (dash) symbol appears in the appropriate column. If AMODE_ANY or RMODE_ANY is specified, ‘ANY’ appears in the appropriate column. Other values are shown as specified.

Related concepts
Using dumps in problem determination
Related tasks
Looking at the kernel domain storage areas
Formatting system dumps
Related references
The system dump table
[[ Contents Previous Page | Next Page Index ]]