IBM Support

PM10390: TASK HANGS IN TSQUEUE WAIT ON AN AUX TEMP STORAGE QUEUE.

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 task that is stuck in a TSQUEUE wait.  The
    'DS=1' summary in the dump shows the task like this:
    ---------------------------------------------------------------
    TSQUEUE  Q1234567         S 20:52:30.281
    ---------------------------------------------------------------
    In this example, the name of the queue is Q1234567 .  This is
    a recoverable, aux temp storage queue.
    .
    In the 'TS=1' verbx output, the Queue Lock Summary looks like
    this:
    ----------------------------------------------------------------
    Queue     Queue      Lock   Lock holder/waiters
    Name      Flags      Type  Tranid Trannum  Uowid
    Q1234567  AR-IP-LO-
                         Req    CSMI   85025   C5636591ACEC9293
                                CSMI   85025   C5636591ACEC9293
                         Own    CSMI   85025   C5636591ACEC9293
    ----------------------------------------------------------------
    This summary shows that task 85025 owns and is waiting for the
    Request lock.  And that it owns the Ownership lock.  It should
    never be the case that a task both owns and is waiting for the
    Request lock of a given queue.
    .
    The 'KE=1' verbx output shows that this task is in transaction
    backout.  The stack for this task looks like this:
    ----------------------------------------------------------------
    01BC  0120 Bot  A2301C00 A2301FBC 0003BC  DFHKETA
    01BC  0320 Dom  A231A640 A231A858 000218  DFHDSKE
    01BC  0820 Dom  A2342C38 A2343DD6 00119E  DFHXMTA
    01BC  0330 Dom  A90A5000 A90A5504 000504  DFHAPPG
               Int   +000350 A90A517C 00017C  FAST_INITIAL_LINK
    01BC  0D98 Lifo 2F3F4028 AF3F5EF6 001ECE  DFHMIR
    01BC  0198 Lifo 28FFF600 A8FFFA0A 00040A  DFHSPP
    01BC  0B50 Dom  A23D2458 A23D4EF6 002A9E  DFHRMUW
               Int   +000C4E A23D2654 0001FC  RMUW_BACKOUT_UOW_RTN
    01BC  0350 Sub  A23D7FB0 A23D855E 0005AE  DFHRMUWB
    01BC  0780 Sub  A23BA708 A23BAA9E 000396  DFHRMRO4
    01BC  0630 Dom  A8F6D538 A8F6E920 0013E8  DFHTSRM
               Int   +002C7A A8F6D794 00025C  END_BACKOUT
    01BC  0250 Sub  A8F7BD98 A8F7C4A2 00070A  DFHTSWQ
               Int   +0004B4 A8F7BF44 0001AC  APPEND_WAITER
    01BC  02D0 Dom  A230ED60 28D9DBDE 000000  DFHDSSR
               Int   +00149C A230F6A0 000940  POP_TASK
    --------------------------------------------------------
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All.                                         *
    ****************************************************************
    * PROBLEM DESCRIPTION: Recoverable temporary storage queue     *
    *                      remained locked after an abend ATSU.    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    This problem presented as DFHSM0131 ( CICS is under stress )
    followed by DFHTS1301 ( I/O error ) messages being issued and
    then a task hung because it was unable to acquire the TSQUEUE
    lock required for backout processing.
                                                                   .
    A TS queue was defined as RECOVERABLE. A START request was
    issued from an application and DFHTSPT acquired the request
    lock. But CICS returned an IOERR ( DFHTS1301 ) for the request.
    However, the TS request lock was not released as part of clean
    up processing. RM (Recovery Manager) required the lock for
    backout but was unable to acquire it so went into a wait. Other
    tasks requiring the lock also went into a wait.
    
    Keywords: abendATSD abendATSC TS1301 msgDFHTS1301 abendATSU
              ATSU
    

Problem conclusion

  • The affected temporary storage modules have been modified and
    will now release the request lock for recoverable temporary
    storage requests which have failed with a disaster response.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM10390

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    600

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-03-22

  • Closed date

    2010-04-06

  • Last modified date

    2010-05-04

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

    PM06045

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

    UK55733

Modules/Macros

  • DESTSAM  DESTSBR  DESTSDM  DESTSQR  DESTSQU
    DESTSRM  DESTSST  DFHSTTSH DFHSTTSX DFHSTUTS DFHTSAM  DFHTSAMA
    DFHTSAMC DFHTSAMD DFHTSAMM DFHTSAMT DFHTSBR  DFHTSDM  DFHTSDUC
    DFHTSDUF DFHTSDUS DFHTSGPS DFHTSPT  DFHTSQR  DFHTSQUC DFHTSQUD
    DFHTSRM  DFHTSST
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R600 PSY UK55733

       UP10/04/09 P F004

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:
04 May 2010