PH63103: CICS REGIONS CONNECTED VIA IPIC IPCONN HAVE PARTNER TASKS BOTH STUCK IN IS_RECV WAITS FOR EACH OTHER CAUSING THEM TO HANG

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You are running CICS TS and have 2 CICS regions connected
  via an IPIC connection. You notice tasks in the 2 regions
  that have been suspended in IS_RECV waits for over an hour.
  Looking at dumps taken from both of these regions during
  this time, we find the corresponding tasks using the
  conversations ID or CONV ID.
  These tasks both show they are stuck in IS_RECV waits
  to each other.
  
  Looking at the stacks for these tasks, here are the program
  names:
  NAME                           NAME
  DFHISXM INIT_XM_CLIENT         DFHEPC
  DFHISIS                        DFHISIS
  DFHISIS_INITIALIZE_RECEIVER    DFHISIS_CONVERSE
  DFHISZA                        DFHISZA
  DFHISZA_RECEIVE_REQUEST        DFHISZA_RECEIVE_RESPONSE
  DFHISSR                        DFHISSR
  DFHISSR_RECEIVE_REQUEST        DFHISSR_RECEIVE_RESPONSE
  DFHISSR_PREPARE_FOR_RECEIVE    DFHISSR_PREPARE_FOR_RECEIVE
  DFHISSR_WAIT_FOR_DATA          DFHISSR_WAIT_FOR_DATA
  
  When purging one of these tasks, the IPIC Connection goes
  into FREEing status.
  
  There is a bug in the code that involves a timing window.
  It causes the CISR task to copy the data into the ISQA
  instead of the ISSB. The attaching of the task and
  CISR receiving the data into the ISQA interleave
  resulting in the attached task thinking it has to
  wait for data to arrive. CISR has actually received
  all the data into the ISQA.
  
  Additional symptom(s): KIXREVACC
  IPCONN FREEing ACQuired status HANG HUNG
  ISRECV mirror task RECEIVE
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS Users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Two tasks in regions connected via      *
  *                      IPIC can become stuck in IS_RECV        *
  *                      suspends waiting on each other.         *
  ****************************************************************
  Two tasks in regions connected via IPIC can become stuck in
  IS_RECV suspends waiting on each other.
  The task in the client region issues a recoverable request to
  the server region and is now waiting for a response.
  The task in the server region is waiting for the initial data
  for the request to be sent by the client region.
  
  The transaction in the client region issues a recoverable work
  request to the server region. In the server region, a long
  running mirror is in use (specified in the IPCONN definition
  with attribute MIRRORLIFE(UOW)). The client transaction then
  issues an EXEC CICS SYNCPOINT. This causes the mirror
  transaction in the server region to end. The ISSB being used for
  the conversation is freed by this ending mirror task as part of
  task clean up. This process is held up, and this opens a timing
  window allowing the client transaction to send in a subsequent
  recoverable request to the server region. This subsequent
  request is part of the same conversation between these regions,
  so will require the same ISSB that is still in use by the first
  mirror task.
  As the first mirror has been held up in freeing the ISSB, this
  new request will be queued against the ISSB and will have use
  of this once it has been freed by the first mirror task.
  An ISQA is obtained to queue this allocate, and the request data
  is stored in this ISQA control block.
  
  A timing window has been discovered in which CISR interleaves
  with the ending mirror task, this results in CISR updating the
  ISQA after the ending mirror task has copied the information
  from this to pass on to the task waiting for the ISSB.
  
  This results in the newly attached mirror task waiting for the
  initial request data, which has in fact already been received
  by CISR and is held in the ISQA.
  

Problem conclusion

• The code has been updated so that once processing has begun to
  attach a request that is queued against an ISSB, the flag used
  to indicate that an allocate is queued is reset.
  

Temporary fix

Comments

APAR Information

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

  PH62798

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

  UI99111 UI99112

Modules/Macros

• DFHISAL  DFHISRR
  

Fix information

• Fixed component name

  CICS TS Z/OS V6

• Fixed component ID

  5655YA100

Applicable component levels

• R400 PSY UI99112

     UP24/11/20 P F411

• R500 PSY UI99111

     UP24/11/23 P F411

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.