IBM Support

PM58836: CPSM BAD RESP TSQ TRACE ENTRIES FILL AUX TRACE, MAY CONTRIBUTE TO EYUCL0122E MAS COMMS BUFFER SHORTAGE.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A user CPSM API program is running every 10 minutes and
    attempting to delete CICS shared temporary storage queues
    (TSQ)s. It is sending the delete requests for multiple TSQs
    which are located on 40 different CICS regions in the CICSplex.
    Once the TSQ is successfully deleted, subsequent attempts
    to delete the same TSQ will fail with 'TSqueue cannot be found'
    The 'Bad RESP' trace entries are as follows:
    48 NSTQ NSGR CONL MAS Excp    200 BAD RESP CPSM CICSABCD LMAS
    17:01:44.19415 15:01:44.19415  2/10/12
    LOCAL storage +70 :
         Keyword             Data Queue      Req Data      Data
         Value               Type Dir        Opt Address   Value
    In: *FUNCTION            FUN              .  22F6E222  SETSHQ
        *DEBUG               CHR              .  22F6E226  NSGRNSTQ
         TSQUEUE_NAME        CHR              .
         TSPOOL_NAME         CHR              .
         LASTUSEDINT         BIN              .
        *DELETE              SDT              .
        *QTOKEN              QID              .  22F6E256
        *NAMELIST            NLS              .  22F6E25E
         VIEWMOD             VUE              .
    Out:*RESPONSE            RSP              .  22F6E224  00
        *REASON              RSN              .  22F6E225  00
        *RESP                CR1              .  22F6E24A  00000000
        *RESP2               CR2              .  22F6E24E  00000000
        *STATUS              STA              .  22F6E252  OK
        *EIBFN               EFN              .  22F6E254  8014
    
    EXEC CICS SET TSQNAME ACTION(DELETE) is being issued and is
    failing with the EIBRESP = 13 NOTFOUND RESP2=1
    The TSqueue canot be found
    .
    The trace entry issued by NSTQ is written when an attempt to
    delete a shared TSqueue is made but fails.
    The CMAS trace has 3072 of these trace entries.
    Shipping a trace entry to the CMAS does require the use of an
    SMTB which later ran out , leading to message :
    EYUCL0122E CICSABCD MAS communications buffer shortage has been
    detected
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICSPlex SM V4R1M0 and V4R2M0 Users      *
    ****************************************************************
    * PROBLEM DESCRIPTION: When the CPSM API or WUI is used to     *
    *                      delete shared TS queues (TSQSHR tables) *
    *                      in MASes, the auxtrace datasets for the *
    *                      MASes and the CMASes they connect to    *
    *                      may wrap with excessive exception       *
    *                      traces written by method EYU0NSTQ       *
    *                      (NSTQ) in the MASes.  The trace         *
    *                      information is as follows:              *
    *                                                              *
    *                        Method  Caller  TPID   Debug text     *
    *                        ------  ------  ----   ----------     *
    *                        NSTQ    NSGR     200   BAD RESP       *
    *                                                              *
    *                      Since the traces may be shipped to the  *
    *                      CMAS through communications, if many    *
    *                      delete requests are made within a short *
    *                      period of time, this may lead to a      *
    *                      shortage of communications buffers used *
    *                      to ship information between a CMAS and  *
    *                      its connected MASes.  If this occurs,   *
    *                      the CMAS or MAS that encounters the     *
    *                      shortage will issue message EYUCL0122E  *
    *                      and request that a dump be taken.  The  *
    *                      message and dump title will be similar  *
    *                      to the following:                       *
    *                                                              *
    *                        EYUCL0122E  MAS communications        *
    *                                    buffer shortage has       *
    *                                    been detected.            *
    *                                                              *
    *                        EYU0XZPT Dump,<jobname>,<cpsmname>,   *
    *                        <lpar>,<jobtype>,<tranid>,<tasknum>,  *
    *                        TRAC,EYU0CTBT,<mm/dd/yy>,<hh:mm:ss>   *
    ****************************************************************
    * 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.                               *
    ****************************************************************
    Shared TS queues may be accessibile from multiple MASes.  So if
    the API or WUI is used to delete these queues, it is highly
    likely that requests to delete the same queue will be sent to
    each MAS that reports the queue.  When this occurs, it is
    possible that a MAS will issue a delete request after another
    MAS's request to delete the queue has already been processed.
    When this occurs, method EYU0NSTQ will receive a NOTFND response
    from CICS, and issue an exception trace.
    

Problem conclusion

  • NSTQ has been updated to change the trace written for a NOTFND
    response to a request to delete a shared TS queue from an
    exception trace to a MAS component level 31 trace.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM58836

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    60M

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-02-23

  • Closed date

    2012-02-28

  • Last modified date

    2012-03-01

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

    PM58797

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

    UK76593 UK76594

Modules/Macros

  •    EYU0NSTQ
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R60M PSY UK76593

       UP12/03/01 P F202

  • R70M PSY UK76594

       UP12/03/01 P F202

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":"4.1","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":"4.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 March 2012