PH34810: DFHRM0001 0C4/AKEA OCCURRED IN MODULE DFHRMUW AT OFFSET X'625A'

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An 0C4 occurred for a long-running user task who had issued an
  EXEC CICS INQUIRE TASK command for another task# 12345. During
  processing of this command, the kernel stacks show DFHXMIQ
  called DFHRMUW for an INQUIRE_UOW request. The problem seems to
  be that by the time DFHRMUW is processing the INQUIRE_UOW call,
  task# 12345 had terminated and its TXN storage had been reused.
  
  CICS trace shows that the failing task had just come out of a
  wait for the RMDMLOCK. Task# 12345 had been valid when module
  DFHXMIQ was doing its checks. DFHXMIQ then called DFHRMUW for
  the INQUIRE_UOW request. On entry, DFHRMUW gets the RM domain
  lock. But the task had to wait for this lock. By the time the
  failing task got the RM domain lock, task# 12345 was gone and
  its TXN storage had been reused. So DFHRMUW then took the 0C4.
  
  Additional Symptom(s) Search Keyword(s): 35PAD164
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users                               *
  ****************************************************************
  * PROBLEM DESCRIPTION: DFHRM0001 0C4/AKEA in module DFHRMUW.   *
  ****************************************************************
  The customer issued an EXEC CICS INQUIRE TASK command passing
  the transaction number of another task in the CICS system.
  DFHXMIQ validated the txn before passing it to DFHRMUW to
  inquire upon items of recovery manager state associated with
  the transaction, such as its UOWid. While Recovery Manager
  was suspended, pending the RM domain lock, the transaction being
  inquired upon completed. The page containing the txn was freed
  back to storage manager and reused for another storage subpool.
    When DFHRMUW was able to proceed and use the txn reference to
  determine the recovery manager transaction token value (that is,
  the address of the RMUW), a program check occurred as the
  storage reference led to using an invalid address.
  KEYWORDS@ abends0c4 abend0c4 s0c4 oc4 rmuw uow
  

Problem conclusion

• DHRMUW has been changed to handle a program check in this
  area of code and return an response of rmuw_disaster and
  reason of rmuw_not_found in this case. DFHXMIQ has also been
  changed to treat this specific response as evidence of the 0C4
  and that the transaction no longer exists, so TASKIDERR
  (not found) is returned to the SPI.
    Note - the exception trace entry RM 0203 showing that the
  recovery routine has been driven will still be issued, should
  the same error recur after this fix has been applied.
  

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:

  UI75016

Modules/Macros

• DFHRMUW  DFHXMIQ
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R300 PSY UI75016

     UP21/04/22 P F104

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.