IBM Support

OA38811: XCF LOOP IN ISTTSCDX ISSUING ISGMSGCF DISCARD REQUESTS LEADS TO ABEND878 SISM SQA STORAGE EXHAUSTED

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as unreproducible in next release.

Error description

  • Infinite loop in module ISTTSCDX issuing XCF ISGMSGCF DISCARD
    requests to purge outstanding messages.  Eventually SQA is
    becomes exhausted leading to ABENDS878.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All using XCF connections.                   *
    ****************************************************************
    * PROBLEM DESCRIPTION: Infinite loop occurs in module          *
    *                      ISTTSCDX after an XCF INOP.             *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The problem is summarized as follows:
    
    1) An XCF link is established between two hosts within a
       sysplex.
    2) At some point, an XCF disconnect is received on one of
       the hosts.  Module ISTTSCBX takes down the XCF link by
       INOPing the connection with a reason code of 1.
    3) Meanwhile, the XCF connection still has inbound message
       to process. Module ISTTSCDX is in control processing
       within a loop which queries XCF, via the
       IXCMSGCP REQUEST(QUERYMSG) interface, to locate any
       inbound messages for this connection.
    4) As a result of the query, VTAM receives back 74 tokens
       from the query output.  There is also a flag indicating
       there are more messages to receive from XCF.
    5) Since the XCF link is coming down, VTAM issues a
       IXCMSGCP REQUEST(DISCARDMSG) to discard each inbound
       message.  Each DISCARDMSG request allocates an XCF SISM
       control block and schedules an SRB to drive the XCF
       MSGEXIT.  When the MSGEXIT SRB dispatches, XCF will discard
       the specific message.
    6) After the first set of 74 messages are processed, module
       ISTTSCDX continues to query XCF for more messages.  After
       do so, it appears the same exact entries are being returned.
       Module ISTTSCDX continues to issue DISCARDMSG requests,
       which in turn allocates more SQA storage.
    7) Examination of the dump taken at the time of the error showed
       hundreds of thousands of SISM control blocks queued to VTAM
       for processing.  Further analysis revealed the scheduled
       MSGEXIT SRBs were not getting dispatched.  It appears VTAM's
       main task was synchronously issuing an SVC purge (ISTTSCLR)
       for an unrelated channel (CUA).
    8) Module ISTTSCDX continues to issue XCF QUERYMSG and
       DISCARDMSG requests until SQA becomes exhausted an an
       ABEND878 occurs.
    

Problem conclusion

Temporary fix

  • *********
    * HIPER *
    *********
    

Comments

  • ISTAPNVT - Has been changed to define a new bit,
               APN_Sched_IMPAB, which means the Wake Up PAB
               should TPSCHEDule the XCF Inbound Message PAB.
    ISTTSCDX - Has been changed to recognize if the first
               message returned by XCF from a QUERYMSG
               function is the same one returned from the prior
               QUERYMSG.  If this occurs, module ISTTSCDX will
               set new flag, APN_Sched_IMPAB, and immediately
               exit the loop.  This allows other processes, like
               the XCF MSGEXIT SRBs to run.
    ISTTSCWU - Has been changed to schedule the XCF Inbound
               Message PAB if the APN_Sched_IMPAB bit is on.
    ISTTSCMA - Included for maintenance purposes only.
    

APAR Information

  • APAR number

    OA38811

  • Reported component name

    VTAM V4 MVS/ESA

  • Reported component ID

    569511701

  • Reported release

    1D0

  • Status

    CLOSED UR1

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-02-15

  • Closed date

    2012-03-06

  • Last modified date

    2012-05-02

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

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

    UA64486 UA64487 UA64488

Modules/Macros

  • ISTAPNVT ISTTSCDX ISTTSCMA ISTTSCWU
    

Fix information

  • Fixed component name

    VTAM V4 MVS/ESA

  • Fixed component ID

    569511701

Applicable component levels

  • R1B0 PSY UA64486

       UP12/04/17 P F204 Ž

  • R1C0 PSY UA64487

       UP12/04/17 P F204 Ž

  • R1D0 PSY UA64488

       UP12/04/17 P F204 Ž

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":"1D0","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSCY4DZ","label":"DO NOT USE"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1D0","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 May 2012