PH30794: DFHLG0001 0C4 DURING NORMAL CICS SHUTDOWN

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The DFHLG0001 0C4 occurs under a CSXM task that is quiescing
  the RM domain. The 0C4 is caused by a wild branch from
  DFHL2CHS +x'660' (base). This wild branch is caused by an
  overlay of +x'100' into DFHL2CHS's kernel stack. DFHL2CHS
  had just returned from a call to Lock Manager to acquire the
  LGChain lock. The lock had not been immediately available so
  the task had been suspended. While suspended, the 2 words in
  DFHL2CHS's kernel stack +x'100' were overlaid.
  
  The problem appears be due to a race between the RM domain
  quiesce task, and the termination of a CISR task. The RM domain
  quiesce task, module DFHRMLKQ, is behaving as if all other tasks
  have, at that point, completed.
  
  Additional Symptom(s) Search Keyword(s):
  RMLK RMUW LINKSET_CHAIN CLASS_CHAIN DFHRM0132
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: CICS issues message DFHLG0001           *
  *                      and produces a LG0001 dump during       *
  *                      CICS shutdown.                          *
  ****************************************************************
  CICS is being quiesced by a PERFORM SHUTDOWN. This resumes
  various system transactions to complete their work and
  terminate. One of these is CISR. As an EOT TRUE (VIDCTRUE) is
  defined to CICS, CISR calls this then needs to log the fact
  that the RMI RMLK for this TRUE can be deleted. Before the RMLK
  is removed from the all_links_chain however, CSXM calls
  DFHRMDM to quiesce the recovery manager domain. This issues
  method call rmcd_quiesce_class, to iterate through any remaining
  RMLK objects and issue DFHRM0132 messages as appropriate. CSXM
  finds the RMLK for CISR's VIDCTRUE TRUE, and moves it from the
  all_links_chain to a private chain anchored from DFHRMLKQ's
  stack entry. CSXM then continues on, and eventually loses
  control trying to write to DFHLOG. At this time, DFHL2CHS's
  stack entry occupies the storage where DFHRMLKQ's stack entry
  had previously resided.
    When CISR is resumed, it tries to unchain the RMLK from the
  doubly linked list of RMLK objects held on the all_links_chain.
  This modifies the storage where it believes these two pointers
  reside - however this is actually storage within DFHL2CHS's
  stack entry and not within the RMLK chain.The kernel stack frame
  for DFHL2CHS at +X'100' is corrupted.
    The corruption causes a bad branch to be taken from DFHL2CHS.
  The bad branch causes a program check with R14 pointing back
  into DFHL2CHS. This results in the various error messages and
  abends reported by CICS.
  KEYWORDS: DFHLG0001 DFHLG0734 DFHSM0102 LG0001 LG0734 SM0102
           0001 0734 0102 LG SM msgdfhlg0001 msgdfhlg0734
           msgdfhsm0102
  

Problem conclusion

• DFHRMDM has been changed to process any remaining RMLK
  control blocks at a later point in CICS termination.
  

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:

  UI73617 UI73618

Modules/Macros

• DFHRMDM
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R200 PSY UI73618

     UP21/01/27 P F101

• R300 PSY UI73617

     UP21/01/27 P F101

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.