PH55988: CICS REGION USING A TEMPORARY STORAGE SERVER GETS TASKS BACKED UP ON RESOURCE TYPE TSSHARED OR TSPOOL REGION GOES MAXTASK

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Region using a Temp Storage Server reaches MAXTASK.  Reviewing a
  
  dump at the time  of the MAXTASK shows 10 tasks suspended on
  
  resource type TSSHARED, then many other tasks suspended on
  resource type TSPOOL.
  
  The tasks suspended in the TSSHARED waits have sent a request
  to the Temp storage server and are waiting for their
  request to be processed.
  A dump of the temporary storage server showed many tasks, from
  many different regions waiting for there request to
  be processed.
  The problem is a task at the head of the queue is waiting for a
  buffer lock  for the temp storage queue, and the buffer
  
  lock is actually free, so it will never get it.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: An AXM task waited on a free AXM        *
  *                      lock. All other requests within the     *
  *                      shared TS server for this queue waited  *
  *                      for the queue lock. No new requests     *
  *                      could come in.                          *
  ****************************************************************
  The customer had many tasks all driving shared temporary storage
  work at the same time, within a shared TS server region.
    A task held the queue buffer lock while it completed the CF
  request. It then needed to release the lock on the queue buffer.
  This had to first locate the buffer, which requires acquiring
  the pool lock.
    Another task owned the pool lock. It has just added itself to
  the list of waiters for the shared temporary storage queue. It
  had only just added itself to the wait list when the task owning
  the queue went to release it. Many other tasks were queued
  behind it, waiting for the specific buffer lock owned by the
  first task.
    The first task has to wait for the buffer pool lock (which
  serializes all buffer access) so it unposts the ECB and calls
  the WAIT routine. Before it gets to the WAIT routine however,
  the second task releases the pool lock using the inline UNLOCK
  expansion which fails to post the ECB.
    This results in the first task waiting forever for the (free)
  buffer pool lock, and the other tasks waiting forever for the
  locked queue buffer.
    Once every CICS client region had its ten MAXREQs active, no
  new work could enter the shared TS server.
  

Problem conclusion

• The inline UNLOCK code expansion has been changed to ensure that
  the ECB is posted if it is currently unposted.
  

Temporary fix

Comments

APAR Information

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

  PH55930

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

  UI95016

Modules/Macros

• AXMBF
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R400 PSY UI95016

     UP23/12/21 P F312

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.