A fix is available
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 number
PK72561
Reported component name
CICSTS FOR VSE
Reported component ID
564805400
Reported release
B0P
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2008-09-22
Closed date
2008-10-20
Last modified date
2009-05-14
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.
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.1.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
Document Information
Modified date:
14 May 2009