PI80531: INTERMITTENT DELAY IN CICS INTER-REGION COMMUNICATION (MRO) FLOWS. CAN CAUSE LONGER THAN NECESSARY IRLINK WAITS.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• For CICS regions connected by a Connection definition
  specifying Accessmethod IRC or XM, there can be an intermittent
  delay in the flow of work.  For instance, consider an AOR and
  an FOR connected with a XM (or IRC) connection.  When a
  transaction on the AOR makes a remote file request, CICS will
  move data to the FOR where a new mirror transaction begins or
  an existing mirror transaction resumes. Until that mirror
  processes the request and sends a flow back, the AOR
  transaction waits in an IRLINK wait.  The problem is that
  sometimes the triggering of the new or existing mirror
  transaction does not happen immediately. If the new work
  arrives in a small timing window just as the receiving region
  (the FOR in our example) is deciding that there are no more
  dispatchable tasks to dispatch, then the receiving region (FOR)
  can enter an operating system wait without handling the newly
  arrived work. Then this newly arrived work is not handled until
  something else (like ICV, or another XM request, or I/O
  completion) wakes up the FOR.  This causes the waiting AOR
  transaction to wait longer in an IRLINK wait than it should.
  .
  This problem affects all types of transaction flows across CICS
  regions connected by XM or IRC (also known commonly as MRO ).
  For example, the problem can happen during transaction routing,
  function shipping, and DPL.  Also, the problem can happen on
  either side of the connection.  For example in the remote file
  function shipping example above, the problem can happen in the
  AOR when the FOR mirror sends data back to wake-up the waiting
  AOR transaction.
  .
  In theory, this problem can affect any 2 CICS regions that
  communicate over a XM or IRC connection.  But in practice, the
  problem is not noticeable on typical busy CICS regions where
  input arrives over multiple MRO sessions from multiple
  connected CICS regions.  The problem was noticed in a CICS AOR
  region that is the target of remote Starts from a single
  long-running transaction in a single connected region.  All the
  work in this AOR arrives over only one MRO session from that
  one long-running transaction in a connected region.  In that
  case, we were seeing approximately 1 0.3-second delay (that is
  1 three-tenths-of-a-second delay) every 5 or 10 minutes.
  .
  When the delay happens, the delay ends by something else
  causing the CICS region to wake-up.  A way to ensure that the
  CICS region will wake up quickly is to code ICV=100.  The 100
  is milliseconds.  ICV=100 means that a CICS region will only
  ever sleep for a maximum of 100 milliseconds at a time.  In
  that case, the delay caused by this problem would only ever
  last for a maximum of 100 milliseconds.
  Additional Symptom(s) Search Keyword(s): KIXREVGJT
  IRWAIT IRLINK
  

Local fix

• Use SIT parameter ICV=100 .
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS Users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Extended IRLINK waits for XM connected  *
  *                      CICS regions.                           *
  ****************************************************************
  * RECOMMENDATION: .                                            *
  ****************************************************************
  For Cross Memory ( XM ) connected CICS regions it is possible
  that a mirror transaction may be in an IRLINK wait for longer
  than expected and the MRO XM requests not being processed fast
  enough.
  The problem is happening when the CICS region enters partition
  exit when the z_anchor queue (MRO XM work) has work to do but
  the checking in DFHDSTCB has just been carried out and then
  the z_anchor queue was empty.
  The task is in a wait until something else wakes up the CICS
  region such as another task or ICV value expiring.
  
  Keyword: CICSPERF
  

Problem conclusion

• DFHDSTCB has a new check for z_anchor being non-zero and on the
  QR TCB to eliminate the possibility of entering a partition exit
  if new work has arrived on the z_anchor queue.
  

Temporary fix

Comments

APAR Information

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

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

  UI47298 UI47299 PI83340 PI83422

Modules/Macros

• DFHDSTCB
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R000 PSY UI47299

     UP17/05/20 P F705

• R900 PSY UI47298

     UP17/05/20 P F705

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.