IBM Support

PK49713: TASKS HUNG IN TOR AFTER A SHORT ON STORAGE CONDITION WITH CAMSXSWX AS RESOURCE NAME

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • You have a TOR that goes into a a stress condition for short on
    storage (SOS).  After the  storage problem is relieved by
    dynamically increasing the EDSA you find that there are tasks
    not running.  They have a RESOURCE TYPE = USERWAIT and
    RESOURCE_NAME = CAMSXSWX.  It appears that while this CICS
    region was under stress, a GETMAIN was requested when CPSM was
    trying to send an exception trace entry to the CMAS, and the
    GETMAIN failed.
    These tasks were never resumed for clean up after the stress
    condition was relieved.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICSPlex SM V3R2M0 Users                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: When a short-on-storage (SOS) condition *
    *                      exists in a MAS, tasks that are sending *
    *                      a request to the CMAS to which the MAS  *
    *                      is connected may hang permanently.      *
    *                      This will result in resources needed to *
    *                      perform communications to the CMAS      *
    *                      being orphaned.  Depending upon how     *
    *                      long the SOS condition occurs, this can *
    *                      result in message EYUCT0105E and no     *
    *                      further communications to the CMAS,     *
    *                      even if the SOS condition is resolved   *
    *                      and the hanging tasks are purged.       *
    *                                                              *
    *                      The only way to reclaim the required    *
    *                      resources is to terminate and restart   *
    *                      the MAS agent in the MAS.               *
    ****************************************************************
    * RECOMMENDATION: After applying the PTF that resolves this    *
    *                 APAR, all MASes must be restarted.  Note     *
    *                 that the restarts do not need to occur at    *
    *                 the same time.                               *
    ****************************************************************
    When a request is shipped from a MAS to a CMAS, method EYU0CAMS
    (CAMS) is called to initiate the communication request.  CAMS
    allocates a transmit block (EYURCATB) from a free pool of
    transmit blocks, and then calls method EYU0CTBP (CTBP) to
    perform the transmission to the CMAS.  When the transmission is
    complete, CTBP will ensure that the EYURCATB is returned to the
    free pool and that the ECB that CAMS will wait on is POSTed, and
    then return to CAMS.  CAMS will verify that the ECB is posted,
    and if so will return the results of the transmission to its
    caller.
    
    If an SOS condition exists in the MAS, CAMS may not be able to
    call CTBP.  When this occurs, CAMS will notice that the ECB is
    not POSTed, and will call method EYU0XSWX (XSWX) to wait for the
    POST to occur.  Since CTBP was not called, the ECB will never be
    POSTed, and the EYURCATB will never be returned to the free
    pool.  If the SOS condition last for an extended period of time,
    the EYURCATB free pool may become exhausted.  When this occurs,
    message EYUCT0105E will be issued and all attempts to send
    requests to the CMAS will fail.
    

Problem conclusion

  • CAMS has been updated to recognize whether CTBP has been called.
    If it has not been called, CAMS will return the EYURCATB to the
    free pool, indicate that the request failed transmission, and
    return to its caller without waiting on the ECB.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

  • When a short-on-storage (SOS) condition
    exists in a MAS, tasks that are sending
    a request to the CMAS to which the MAS
    is connected may hang permanently.
    This will result in resources needed to
    perform communications to the CMAS
    being orphaned.  Depending upon how
    long the SOS condition occurs, this can
    result in message EYUCT0105E and no
    further communications to the CMAS,
    even if the SOS condition is resolved
    and the hanging tasks are purged.
    
    The only way to reclaim the required
    resources is to terminate and restart
    the MAS agent in the MAS.
    
    
    When a request is shipped from a MAS to a CMAS, method EYU0CAMS
    (CAMS) is called to initiate the communication request.  CAMS
    allocates a transmit block (EYURCATB) from a free pool of
    transmit blocks, and then calls method EYU0CTBP (CTBP) to
    perform the transmission to the CMAS.  When the transmission is
    complete, CTBP will ensure that the EYURCATB is returned to the
    free pool and that the ECB that CAMS will wait on is POSTed, and
    then return to CAMS.  CAMS will verify that the ECB is posted,
    and if so will return the results of the transmission to its
    caller.
    
    If an SOS condition exists in the MAS, CAMS may not be able to
    call CTBP.  When this occurs, CAMS will notice that the ECB is
    not POSTed, and will call method EYU0XSWX (XSWX) to wait for the
    POST to occur.  Since CTBP was not called, the ECB will never be
    POSTed, and the EYURCATB will never be returned to the free
    pool.  If the SOS condition last for an extended period of time,
    the EYURCATB free pool may become exhausted.  When this occurs,
    message EYUCT0105E will be issued and all attempts to send
    requests to the CMAS will fail.
    
    
    CAMS has been updated to recognize whether CTBP has been called.
    If it has not been called, CAMS will return the EYURCATB to the
    free pool, indicate that the request failed transmission, and
    return to its caller without waiting on the ECB.
    

APAR Information

  • APAR number

    PK49713

  • Reported component name

    CICSTS V3 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    50M

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2007-07-25

  • Closed date

    2008-02-15

  • Last modified date

    2008-03-03

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

    PK49383

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

    UK33701

Modules/Macros

  •    EYURCAEQ EYU0CAMS
    

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R50M PSY UK33701

       UP08/02/19 P F802

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":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.2","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"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":"3.2","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
03 March 2008