IBM Support


A fix is available


You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • A customer may experience an ABEND0E0 PIC33 (Invalid Linkage
    Stack Entry Type) or PIC34 (Stack Operation Exception) during
    the end stages of RTM2 as it drives abnormal task termination
    processing.  Due to the unique way that linkage stacks are
    managed under particular TSO environments, this error will only
    occur in a TSO user address space.  The impact of the error is
    limited to one or more ABEND0E0 errors occurring under a task
    that is already in resource manager processing, i.e. definitely
    terminating.  An abend in a resource manager can be retried
    within the scope of that resource manager (not back to mainline)
    and it does not prevent other resource managers from receiving
    control.  Therefore, the impact of this problem is quite small.
    The stage for the problem is set when a TCB in a TSO user
    address space suffers an abend under the following conditions:
    1) The TCB's mini-linkage stack has filled up so that the TCB
       is now running on the full-sized linkage stack.
    2) Either the LSEDEXMS or LSEDUNSS bit is on in the header of
       the full-sized linkage stack section.
    3) The TCB's Tcb_Keep_LS_Extent_Valid bit was on at the time
       the task began using the full-sized linkage stack, which
       caused linkage stack code to set up the mini and full-sized
       linkage stack sections with their validity bits LSET1FSHV
       and LSEH1BSEV on.  (This prevents the hardware from
       generating stack full and stack empty interrupts.  See
       APAR OA31571 and OA31565 for more information.)
    If the task continues with termination following the abend, RTM2
    module IEAVTSKT will logically make the linkage stack look empty
    before driving resource managers.  It resets Control Register 15
    (CR15, CReg15) as well as certain linkage stack-related
    pointers in the TCB/STCB and RB/XB to indicate an empty linkage
    stack.  However, it does not actually clear flags in the linkage
    stack header.  This logic assumes that, if a resource manager
    fills the mini-stack and requires an entry on the full-sized
    linkage stack, the "stack full" exception will cause the linkage
    stack FLIH IEAVLSIH to clear the header.  However, if the
    LSET1FSHV validity bit is set, no "stack full" exception will be
    generated, so no clearing of the header will take place.
    The implication of this linkage stack processing is
    that if an LSEDUNSS bit or LSEDEXMS bit was on when the
    TCB originally abended, it will remain residually on as resource
    managers use the linkage stack.  As a result, a resource manager
    that adds 6 or more entries to the linkage stack (thus filling
    the mini-linkage stack and forcing the
    use of the full-sized linkage stack) may suffer an invalid
    ABEND0E0 PIC33 (if LSEDEXMS is on) or PIC34 (if LSEDUNSS is on)
    when it issues the PR to remove the first entry on the
    full-sized stack.
    Note that this ABEND0E0 may produce a dump and/or logrec but has
    no other noticeable impact.
    Additional Symptoms:
    PURGE SERVICE . ABEND0E0 PSW pointing to loadmod ISGLCRTS+3E72.
    If LSEDEXMS is on, there will be an IRB in the RB chain
    somewhere prior to the first abend SVRB.
    Additional Symptoms:
    Ghost WTORs - WTOR is REPLY'd to and is no longer outstanding
    on the issuing system, but every other system in the SYSPLEX
    still shows the WTOR as outstanding (IEE112I).  Logrec should
    show numerous ABEND0E0 in CNZS1WTP with PSW pointing into
    Nucleus csect IEAVG720.
    Verification Steps:
    1) Obtain a dump of the ABEND0E0 PIC33 (RC33) or PIC34 (RC34).
       Verify that the abend occurred in a TSO user address space.
    2) Issue:  IP ST REGS
       Note the home ASID in the information at the top of the
       output.  Note CR15 which is the linkage stack pointer.
    3) Issue:  IP LIST xxxxxxxx-10 LEN(X'20') ASID(X'yyyy')
       where xxxxxxxx is the low order word of CR15, and yyyy
       is the hex Home ASID.  Output will look similar to the
       following example:
       LIST 7F500000. ASID(X'0025') LENGTH(X'30') AREA
       7F500000. 00000000 00000000 00000000 7F53CFA1
       7F500010. 49000FD0 01280000 00000000 00000000
       where the byte at +X'10' into the X'20'-byte display
       will contain a X'89' (LSEDUNSS bit is on) or a X'49'
       (LSEDEXMS bit is on) or a X'C9' (both bits are on).
       The 9 in the second nibble denotes a stack header.
       Additionally, the word at +X'C' into the X'20-byte
       display will contain a pointer with the lower order
       bit (LSEH1BSEV) on.
    4) Issue: IP LIST zzzzzzzz LEN(X'20') ASID(X'yyyy')
       where zzzzzzzz is the address at +X'C' in the above
       output, but with the low order bit turned off.  Also,
       yyyy is the hex Home ASID number.  Output will look
       similar to the following example:
       LIST 7F53CFA0. ASID(X'0025') LENGTH(X'20') ARE
       7F53CFA0. 0C000000 00000000 00000000 7F500011
       7F53CFB0. 0A000000 00000000 00010000 00000000
       Note that the word at +X'C' into this X'20' byte area
       has the last bit (LSET1FSHV) on, and the remainder of the
       word, disregarding the low order bit, points to the byte
       where we saw the X'89' earlier.  Also note that the byte
       at +X'10' into this X'20-byte area is a X'0A'. The 'A'
       indicates that this is a linkage stack trailer.
    5) The abending TCB's RB chain as viewed in SUMMARY FORMAT
       shows the TCB entering RTM2 for an error that preceded
       the ABEND0E0.
    6) The abending TCB has the following formatted underneath
       it in SUMM FORMAT:
       Task is terminating and its mainline processing will not run
         again (TCBDYING)
       Task is terminating and its mainline processing will not run
         again (TCBENDNG)
       The TCB also has TCBFE on.

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: JES2 users                                   *
    * PROBLEM DESCRIPTION: ABEND0E0 RSN33 OR RSN34                 *
    *                      during task termination                 *
    * RECOMMENDATION:                                              *
    During termination of a task which abended before EOT (End Of
    Task) processing started in a JES2 system, residual bits in
    the Linkage Stack may cause ABEND0E0 with interrupt codes
    of 33 or 34 during EOT processing.  RTM resets the Linkage
    Stack to 'empty' before calling EOT resource managers but
    the unstack or extract/modify suppression bits may still be
    on in previously-used Linkage Stack header records.

Problem conclusion

  • When initially resetting the Linkage Stack before calling EOT
    resource managers, RTM will reset the forward stack validity
    bits in the Linkage Stack, so that normal 'stack full'
    processing will take place and reset the unstack and
    extract/modify suppression bits in Linkage Stack header
    records as needed.

Temporary fix



APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    YesSpecatt / Pervasive / Xsystem

  • Submitted date


  • Closed date


  • Last modified date


  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UA75442 UA75443



Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

  • R780 PSY UA75442

       UP14/11/19 P F411

  • R790 PSY UA75443

       UP14/11/19 P F411

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"780","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"780","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
16 April 2015