PK07994: ABEND0C4 AT +X'4276' INTO DFHRMUW WHILE DOING CEMT INQ UOWENQ. 05/06/10 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DFHRM0001 ' abend0C4 at 4276 into DFHRMUW ' when doing a
  CEMT INQ UOWENQ.  Other symptoms include a stuck INFLIGHT
  UOW that may prevent trimming of DFHLOG .
     These things happen because an inflight UOW is left abandoned
  when a task abends.
     The task abended because of a storage overlay.  There were
  several program checks but here are the important messages
  that allow the UOW to get left stranded:
  +DFHPG0001  HICSPMB0 An abend (code ---/AKEA) has occurred
    at offset X'10D8' in module DFHPGPG.
  +DFHXM0001  HICSPMB0 An abend (code ---/APGB) has occurred
    at offset X'0FF8' in module DFHXMTA.
  -----------
     PGPGREC ( DFHPGPG's recovery routine ) is driven because
  there was a program check in  CEECCICS  when driven for
  Program_Check_Recovery.  PGPGREC would normally return to
  its caller, DFHXMTA , informing it of the abend.  But because
  of code in PGPGREC added by PQ95783 , PGPGREC attempts an
  unconditional call to UNLOCK the PGLOCK which it does not own.
  That results in the abendAPGB that cause the abend to percolate
  to its caller's ( DFHXMTA ) recovery routine.   When control
  is returned to DFHXMTA via it's recovery routine, it does not
  make the DFHRMUWM COMMIT call.  When that call is not made,
  the UOW is left stranded INFLIGHT and everything thing that
  should be backed-out or committed is left hanging.
  

Local fix

• Additional Symptoms: This can also manifest itself as a shutdown
  hang, where message DFHIR2321 IR23321 MSGDFHIR2321 may (but
  doesn't have to be) present.  Looking at a TCTTE, you will find
  a task number at +x'14' that no longer exists in the system. It
  may have abended hours or days ago, but due to the problem
  addressed by this APAR, cleanup never occurred successfully. A
  search through the Kernel Error Table may show the telltale APGB
  ABENDAPGB abend, as long as the table hasn't wrapped.  The
  MSGUSR can also be searched to look for this abend code.
  You can also look at Recover Manager in the dump and find the
  same task numbers that you saw in the TCTTE. They will show up
  to still be inflight.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: CEMT INQ UOWENQ can cause message       *
  *                      DFHRM0001 An abend (code 0C4/AKEA)      *
  *                      has occurred in module DFHRMUW.         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An application holding an ENQUEUE abends causing PG domains
  recovery routine to unconditionally call LM domain to UNLOCK
  a PGLOCK. However, at this point the program does not hold
  PGLOCK causing an exception in LM domain against the UNLOCK
  request.
  This exception is handled by issuing a RECOVERY_REQUEST to
  Kernel domain with abend APGB. The APGB abend gets percolated
  to TASK_REPLY's recovery routine which causes the task to
  terminate without COMMIT processing being done. As a result,
  the ENQUEUE owned by the task never gets DEQUEUED and so
  remains in the system.
  Later, a CEMT INQ UOWENQ command is issued which locates the
  outstanding ENQUEUE but when the Transaction Token associated
  with it is requested it returns a zero pointer. This is because
  the task that created the ENQUEUE has now completed and the
  transaction token pointer in the associated TASENTRY has been
  cleared. When the Transaction Token pointer is next referenced
  an S0C4 abend occurs because protected storage is being
  accessed.
  
  Additional Keywords: ABEND0C4 S0C6 ABEND0C6 AKEA APGB DFHIR2321
                       MSGDFHIR2321
  

Problem conclusion

• DFHPGCM has been changed to issue a domain call to LM to
  release the PGLOCK if pgcm_lock_status indicates the lock is
  held. Otherwise, an inline call to LM is made to release the
  lock. A successful call or failure with LMLM_NOT_LOCK_OWNER is
  ignored. Any other response results in a PGLOCK_DISASTER.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

  PK05470

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

  UK05672

Modules/Macros

•    DESPGAI  DESPGAQ  DESPGCM  DESPGDD  DESPGEX
  DESPGIS  DESPGLD  DESPGLK  DESPGLU  DESPGPG  DESPGRP  DESPGST
  DESPGUE  DESPGXM  DFHPGAI  DFHPGAQ  DFHPGDD  DFHPGEX  DFHPGIS
  DFHPGLD  DFHPGLE  DFHPGLK  DFHPGLU  DFHPGPG  DFHPGRP  DFHPGST
  DFHPGUE  DFHPGXE  DFHPGXM
  

Fix information

• Fixed component name

  CICSTS 3.1 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK05672

     UP05/07/28 P F507

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.