PK72561: MULTIPLE EXCI BATCH JOBS HANG CICS REGION

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• You have multiple CICS partitions with multiple EXCI jobs.
  Your CICS region hangs if you bring up two CICS partitions and
  then run a batch EXCI job which closes files in one of the
  regions first and then go against the other CICS partition.
  If however, you do an EXCI against a CICS you just brought up
  and then bring up another CICS and then do an EXCI against that
  CICS region, the jobs do not fail.  The hang would also not
  result iF each EXCI job was restricted to just accessing one
  CICS partition.
  CICS does not always clean up open connections.  There appears
  to be a window whereby communication between one CICS and
  EXCI batch can start before the first EXCI batch using the same
  NETNAME completes EOT and the sympathetic posting causes a SEND
  to stall.  DFHIRP will be updated to provide extra code to
  remove the duplicate XPCC control blocks that VSE say are the
  root cause of the problem.
  Additional Symptom(s) Search Keyword(s):
  KIXREVSWM  ABENDAZI2 AZI2 DFHMIR
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: CICS and batch hang when using EXCI.    *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Using EXCI may cause both CICS and batch to hang under certain
  circumstances.
  
  The problem can be encountered when two CICS partitions have
  the same MRO EXCI NETNAME for communicating with batch, and
  there are two batch EXCI jobs running, each of which is
  communicating with BOTH of the CICS partitions.
  
  DFHIRP has to check the XPCC connection status to ensure that
  the other end is still active as part of the XPCC
  FUNC=SEND and FUNC=RECEIVE CICS code. If it is not still active,
  then it assumes that it will re-connect at some time, so it
  issues an XPCC FUNC=CONNECT and then has to wait for the other
  side to connect.
  
  CICS ought to issue a FUNC=DISCONN before a re-connect to delete
  the XPCC CRCB control block, but it does not do that under all
  circumstances. The superfluous CRCB control block represents a
  connection that no longer exists.
  
  When a batch EXCI client terminates the EXCI communication
  using the call to DFHXCIS, an XPCC FUNC=TERMIN is performed,
  which posts the CICS side that it is working with to say that
  the other end has disconnected. Unfortunately, XPCC posts not
  only that CICS system, but also ANY CICS system that has an open
  connection, including the one represented by the original CRCB.
  
  This can happen just before CICS is due to issue an XPCC
  FUNC=SEND via the QR task (i.e. the CICS "maintask") which is
  now in active communication with the other batch job. CICS
  assumes that the EXCI client is in MRO LOGOFF/LOGON processing
  and issues a FUNC=CONNECT and waits for the other side to
  re-connect, which it is never going to do. So CICS hangs and
  that batch client also hangs as it is waiting for the CICS
  SEND before doing anything else.
  
  The CICS code is designed to re-connect correctly when the batch
  side that is actively working with does a legitimate
  disconnect. The problem occurs only on the SEND side and when
  CICS receives a "false" disconnected status due to the
  residual CRCB.
  

Problem conclusion

• DFHIRP has been changed so that an XPCC FUNC=DISCONN is issued
  before every "re-connect" XPCC FUNC=CONNECT.
  
  Routine IRTIDY has been changed to issue a DISCPRG and TERMIN
  instead of TERMPRG for EXCI jobs.
  

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:

  UK40866

Modules/Macros

•    DFHIRP   DFHIRPCL DFHIRPS
  

Fix information

• Fixed component name

  CICSTS FOR VSE

• Fixed component ID

  564805400

Applicable component levels

• RB0P PSY UK40866

     UP08/10/22 P E421

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.