IBM Support

PK65373: DFHIR2321 AT SHUTDOWN BECAUSE EXCI SESSION NOT FREED AFTER TIMEOUT

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The problem is as follows :
    - Batch program issues a link to PGMWAIT
    - EXCI session RG1 is acquired
    - task 00037is started and the program issues EXEC CICS DELAY
      with a two minutes interval
    - after 30 seconds the TIMEOUT parm in DFHXCOPT fires causing
      the RG1 session to be disconnected (NORMAL DISCONNECTION
      RECEIVED)
    - immediately session RG2 is acquired because of a second
      command issued by the batch (EXEC CICS LINK to program
      PGMNULL) and data are passed in the TIOA (NEW CONNECT WITH
      INPUT RECEIVED). The taskno is always 00037, so no actions
      are done by CICS because the task is in wait status.
    - after two minutes interval completes the task 00037 is
      resumed and it send the response to batch via IRC SWITCH
      SUBSEQUENT TO SYSTEM(DFHGEN), but it gets RC x'24' SET
      FOOTPRINT FAILED (IRERRCFT). IRERRCFT is set when CONNECTION
      is removed or disabled, as RG1 is.
    - At this point AZI4 abend is issued, transaction is abended
      and recovery is performed.
    - finally all is cleared but RG2 session that remains there
      waiting and will cause subsequent DFHIR2321 at shutdown.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Message DFHIR2321 at CICS shutdown      *
    *                      because TCTE_TRANNUM set in EXCI        *
    *                      session following timeout of            *
    *                      previous Transactional EXCI request.    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    Following the time-out of a Transactional EXCI request (DPL
    request from EXCI job without SYNCONRETURN and CICS region
    specifies RRMS=YES), the EXCI job sends another Transactional
    EXCI request in the same UOW to the same CICS region.
    
    When DFHCRNP receives the 2nd request it allocates the next
    unused session and issues the RXUW PUT_CLIENT_REQUEST request to
    RRS. It returns the task number and UR_Token of the existing
    CICS task processing this Unit of Work.
    DFHCRNP fills in TCTE_TRANNUM and TCTEURAD in the new session
    assuming that task is ready to process this request.
    
    However this task is in an unknown state and although the pipe
    has been disconnected on the EXCI side the session is still in
    use on the CICS side. When eventually the original task that has
    timed out completes it finds the link broken and abends AZI4.
    
    As part of Syncpoint's BACKOUT_UOW processing it informs RRS to
    BACKOUT this UOW and also DISConnects the original session.
    However because this task knows nothing about the second
    session nothing is done to tidy it up, leaving TCTE_TRANNUM
    still set.
    
    At shutdown, CICS finds this session with TCTE_TRANNUM set and
    thinks there is a task attached and issues message DFHIR2321
    preventing shutdown.
    
    Additional Keywords
    msgDFHIR2321 IR2321 AbendAZI4
    

Problem conclusion

  • The DFHRXUW domain gate PUT_CLIENT_REQUEST has been changed
    to replace the NO value for NEW_UR with one of 3 new values
    NO_AND_READY, NO_AND_NOT_READY or NO_AND_NOTASK.
    
    NO_AND_READY is returned if the application task processing
    this UOW is suspended with a RESOURCE_TYPE of RRMSEXIT & a
    RESOURCE_NAME of GET_CLIENT_REQ.
    
    DFHCRNP has been changed to fill in TCTE_TRANNUM & TCTEURAD in
    the new session only if the parameter NEW_UR returned from the
    PUT_CLIENT_REQUEST request is YES or NO_AND_READY.
    
    When NO_AND_NOT_READY or NO_AND_NOTASK are returned the session
    will be left as present for the EXCI job to Time-out the request
    However this time the DFHIR TYPE=DISC request issued from the
    EXCI side will tidy up the session because it doesn't contain
    TCTE_TRANNUM.
    
    
    The documentation in the following manuals has been changed :-
    
    (1) CICS Transaction Server for z/OS
        Version 3 Release 1
        CICS Diagnosis Reference
        Document Number GC34-6899-00
    
    Change section 3.31.1.3.2 which deals with the output parameters
    for the RXUW gate, PUT_CLIENT_REQUEST function as follows :-
    Replace
     NEW_UR Indicates whether a new UR has been created for this
            request. It can have one of these values:
     YES  indicates that a new UR has been created.
     NO   indicates that the request was associated with an
            existing UR.
    With
     NEW_UR Indicates whether a new UR has been created for this
            request. It can have one of these values:
     YES indicates that a new UR has been created
     NO_AND_READY
        indicates that the request was associated with an existing
        UR and that task is ready to receive the request.
     NO_AND_NOT_READY
        indicates that the request was associated with an existing
        UR but that task is NOT ready to receive the request.
        This usually occurs when the original request has timed out
        and another Transactional EXCI request in the same RRS UOW
        has been sent by the EXCI job.
     NO_AND_NOTASK
        indicates that the request was associated with an existing
        UR but that task has not Expressed an Interest in that UOW
        yet.
        This could occur when the original request has been held by
        Max Task or TRANCLASS (TCLASS) limits and has timed out,
        and another Transactional EXCI request in the same RRS UOW
        has been sent by the EXCI job.
    
    
    (2) CICS Transaction Server for z/OS
        Version 3 Release 2
        CICS Diagnosis Reference
        Document Number GC34-6862-01
    
    Change section 3.28.1.5 which deals with the
        RXUW gate, PUT_CLIENT_REQUEST function as follows :-
    Replace
       NEW_UR Indicates whether a new UR has been created for this
              request. Values for the parameter are:
       NO
       YES
    
    With
     NEW_UR Indicates whether a new UR has been created for this
            request. It can have one of these values:
     YES indicates that a new UR has been created
     NO_AND_READY
        indicates that the request was associated with an existing
        UR and that task is ready to receive the request.
     NO_AND_NOT_READY
        indicates that the request was associated with an existing
        UR but that task is NOT ready to receive the request.
        This usually occurs when the original request has timed out
        and another Transactional EXCI request in the same RRS UOW
        has been sent by the EXCI job.
     NO_AND_NOTASK
        indicates that the request was associated with an existing
        UR but that task has not Expressed an Interest in that UOW
        yet.
        This could occur when the original request has been held by
        Max Task or TRANCLASS (TCLASS) limits and has timed out,
        and another Transactional EXCI request in the same RRS UOW
        has been sent by the EXCI job.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

  •  **** PE09/09/08 FIX IN ERROR. SEE APAR PK87588  FOR DESCRIPTION
    ž**** PE09/09/08 FIX IN ERROR. SEE APAR PK87588  FOR DESCRIPTION
    

APAR Information

  • APAR number

    PK65373

  • Reported component name

    CICSTS V3 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    400

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2008-05-02

  • Closed date

    2008-11-13

  • Last modified date

    2009-09-25

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK41496 UK41497

Modules/Macros

  •    DESRXAS  DESRXCON DESRXCT  DESRXDM  DESRXDUF
    DESRXEC  DESRXEH  DESRXEX  DESRXLG  DESRXRM  DESRXSM  DESRXSV
    DESRXSVC DESRXTRI DESRXUR  DESRXUW  DFHCRNP  DFHRXASA DFHRXASC
    DFHRXASM DFHRXAST DFHRXCON DFHRXCTC DFHRXDM  DFHRXDMA DFHRXDMC
    DFHRXDMD DFHRXDMM DFHRXDMT DFHRXDUF DFHRXECC DFHRXEC1 DFHRXEC2
    DFHRXEHC DFHRXLGC DFHRXRMC DFHRXSMC DFHRXSM1 DFHRXSM2 DFHRXSVC
    DFHRXSV1 DFHRXTRI DFHRXUCC DFHRXURC DFHRXUR1 DFHRXUR2 DFHRXUW
    DFHRXUWA DFHRXUWC DFHRXUWM DFHRXUWT DFHRXXMA DFHRXXMM DFHRXXMT
    DFHRXXRG DFHRXXRM
    

Publications Referenced
GC34689900GC34686200   

Fix information

  • Fixed component name

    CICSTS V3 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R400 PSY UK41496

       UP08/11/18 P F811

  • R500 PSY UK41497

       UP08/11/18 P F811

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":"3.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
25 September 2009