IBM Support

PK72561: MULTIPLE EXCI BATCH JOBS HANG CICS REGION

A fix is available

Subscribe

You can track all active APARs for this component.

 

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":"BU011","label":"Systems - zSystems software"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.1.1","Edition":""}]

Document Information

Modified date:
14 May 2009