PK15268: DFHAP0001 ABEND (CODE 0C4/AKEA) AT OFFSET X'10E0' IN DFHD2CC PROCESSING DSNC DISCONNECT PLANNAME

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After migrating from CICS TS 1.3 to CICS TS 3.1, DSNC Disconnect
  planname request causes the following abends:
  DFHAP0001 An abend (code 0C4/AKEA) has occurred at offset
            X'10E0' in module DFHD2CC.
  DFHPG0001 An abend (code ---/AKEA) has occurred at offset
            X'0F96' in module DFHPGPG.
  DFHXM0001 An abend (code ---/APGB) has occurred at offset
            X'0FF8' in module DFHXMTA.
  DFHAP0002 A severe error (code X'318C') has occurred in module
            DFHD2EX1.
  The DSNC task, created for the DISCONNECT request, fails with
  an abend0C4 in DFHD2CC, in the DISCONNECT_PROTECTED_THREADS
  routine. DFHD2CC is removing a CSUB from the DB2 entry's free
  protected chain. The 0C4 occurs on a ST instruction (50B0 204C)
  at offset x'10E0' because Reg2 is zeroes. Reg2 is loaded from
  CSB_RCT_PTHREAD_PREV (Reg10 +x'48'). Reg10 is correctly pointing
  to a CSUB, but offset x'48' (the free protected chain previous
  pointer) is zeroes.
  .
  This CSUB was just used by the previously created task. This
  task is currently suspended in an LMQUEUE suspend for the
  PTHREAD lock (D2S_PTHREAD_LOCK). DFHD2EX1, in routine MOVE_CSUB
  is requesting the protected thread lock, prior to moving the
  CSUB from the active chain back to the free protected chain.
  .
  It appears that this task first acquired the PTHREAD lock, and
  was removing the CSUB from the DB2 entry free protected chain,
  running on the QR TCB. Simultaneously, the DSNC DISCONNECT task
  was running on the D2 TCB, browsing through the DB2 entries.
  The DSNC task found a matching plan and loads the CSUB address
  from the DB2 entry +'B4' (rct_free_prot_thread_chain). If the
  CSUB address is not zero, DFHD2CC then goes to acquire the
  PTHREAD lock (but it has already loaded the CSUB address). The
  prior task has just finished moving the CSUB from the free
  protected chain to the active thread chain, and begins it's DB2
  work. The DSNC task is now able to acquire the PTHREAD lock, but
  it doesn't reload the CSUB address. DFHD2CC now tries to remove
  the CSUB from the free protected chain, but it's pointer at
  +x'48' is zeroes -- it's no longer on the free protected chain.
  DFHD2CC needs to reload the CSUB address after acquiring the
  PTHREAD lock. The problem wouldn't happen in CICS 1.3 because
  the DSNC task would have been running on the QR TCB, not the D2
  TCB, and so the requests would have been single-threaded.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All.                                         *
  ****************************************************************
  * PROBLEM DESCRIPTION: DFHAP0001 Abend (CODE 0C4/AKEA) at      *
  *                      offset X'10E0' in DFHD2CC.              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The problem is happening when one task is removing a CSUB from
  the free protected chain running on the QR TCB. At the same time
  a DSNC DISCONNECT task running on the D2 TCB loads this CSUB
  address. If the CSUB address is non-zero then it will acquire
  the PTHREAD lock, but before it gets the PTHREAD lock the first
  task completes the removal of the CSUB from the free protected
  chain and so its CSB_RCT_PTHREAD_PREV address is nulls. When
  the CSUB pointed to by this field is then attempted to be
  updated the 0C4 occurs.
  It is also possible to suffer a severe error (code X'3255') in
  module DFHD2D2 when a CSUB has been placed on the free
  connection chain but another task tries to use this CSUB before
  it has been terminated.
  
  Keywords: msgDFHAP0001 AP0001 0001 AKEA abendS0C4 S0C4
            msgDFHAP0002 DFHAP0002 AP0002 INVALID_TCB
            csb_tcb_address
  

Problem conclusion

• DFHD2CC has been changed in DISCONNECT_PROTECTED_THREADS to only
  update the CSUB address when it holds the PTHREAD lock.
  DFHD2CC has also been changed to issue the TERMINATE_THREAD
  call before the CSUB is added to the free connection chain.
  

Temporary fix

• 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:

  UK11089 PK18933

Modules/Macros

•    DESD2CC  DFHD2CC
  

Fix information

• Fixed component name

  CICSTS 3.1 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R400 PSY UK11089

     UP06/01/27 P F601

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.