PM71194: TRANSACTION LOOPING IN DFHRMLSO BECAUSE OF THE RMLK CHAIN POINTING INTO ANOTHER UOW'S EMPTY ITERATOR 12/10/23 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The dumps show a UOW that has a chain of iterators for its
  RMLKs, and these chains have ended up pointing into another
  UOW's (empty) iterator chain. An empty chain has its prev and
  next pointers both the same and pointing at the same dummy point
  within the RMUW. DFHRMLSO then loops when going forward to the
  next entry.
  There appears to be what looks like stale data in the iterator
  pointers for two of the RMUWs in the system. We can see that
  HOP_StartIterator is called without first getting a lock which
  could lead to the issue that is being seen.
  This loop in DFHRMLSO also leads to a number of tasks entering
  LMQUEUE waits while waiting on the RMDMLOCK to be freed. The
  owner of this task will not relinquish control of the lock
  because it is currently looping in DFHRMLSO
  Additional Keywords: RMDMLOCK, DFHRMLSO, LOOP, 17CE , 17E2
  rmls_remove_link
  KIXREVNDB
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: A task hangs. SYSTRACE shows a loop in  *
  *                      DFHRMLSO.                               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  One task is running through SYNCPOINT on an open TCB. Another
  task is inquiring on UOWLINKs (which is not threadsafe so runs
  on the QR TCB). So the second task (unit of work) is browsing
  the RM links (RMLKs) for the first unit of work. Both these
  tasks use HOP_StartIterator and HOP_EndIterator macros to
  manipulate chains of iterators for the two units of work.
  These macros are not threadsafe, and since they are running
  on different TCBs they are able to interfere with one another.
  This leads to stale data in the iterator pointers for one of
  the units of work.
  In the reported problem, this led to a unit of work with
  chains of iterators for its RMLKs, pointing into another UOWs
  (empty) iterator chain. An empty chain has its previous and
  next pointers both the same and pointing at the same dummy
  location within the RMUW. Hence the code then loops going
  forwards on the next ptr.
  

Problem conclusion

• UK66252 UK67848 UK75374 UK75381
  Recovery Manager has been amended to get the RM domain lock
  prior to manipulating the iterator chains. This ensures a
  threadsafe syncpoint cannot interfere with an INQUIRE UOWLINK
  CICS SPI command.
  

Temporary fix

•             *********
              * HIPER *
              *********
  FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  PM75181 UK83064

Modules/Macros

•    DFHRMLKT DFHRMLSD DFHRMLSF DFHRMLSO DFHRMLSP
  DFHRMLSS DFHRMLSU
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R600 PSY UK83064

     UP12/11/03 P F211 ®

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.