CICS task hung in an ALLOCATE wait on an APPC connection due to running with limited resource

Technote (troubleshooting)


Problem(Abstract)

You are running an application that gets hung in an ALLOCATE wait for an advanced program-to-program communications (APPC) session. The wait causes your task to hang under CICS.

Symptom

ALLOCATE wait on APPC connection


Cause

Limited Resources (LR) is set somewhere in the network.

Diagnosing the problem

  1. A bind arrives with binltdrc turned on indicating VTAM LIMRES in use.
  2. Change number of sessions (CNOS) is negotiated to max 12 winner 12.
  3. All of the user sessions are bound and then unbound. The 2 SNASVCMG sessions are also unbound after CNOS and exchange lognames (XLN). This is normal operation when VTAM LR is in use. The connection now is in AVA state.
  4. The connection is lost (either brought down from the partner's side, or abnormally lost). Because there are no bound sessions, no information is given at that time to CICS from either the partner or VTAM.
  5. A user task attempts an ALLOCATE. This causes an attempted SIMLOGON for the first WINNER user session. A SUSPEND is issued to wait for the SIMLOGON to finish.
  6. The SIMLOGON fails due to either the network problem or the partner being down. RPL feedback code of X'1000' is received.
  7. The CICS Node Abnormal Condition program, DFHZNAC, creates message DFHZC2405 and TCTESLGI is turned off (No SIMLOGON allow). This prevents a loop in CICS re-issuing the SIMLOGON to VTAM.
  8. DFHZNAC then calls DFHALP TERMINAL_UNAVALABLE. DFHALP TERMINAL_UNAVALAIBLE does a TC LOCATE find the second WINNER session and call DFHZISP to ATI that session. The second WINNER session suffers the same fate as the first one. This loop is repeated until all of the contention WINNER sessions have been tried. On the last contention WINNER, DFHALP sets TERMINAL_UNAVAILABLE because it can not find any more sessions to try. CICS resumes all of the tasks that were suspended in DFHALP for that connection with an error causing SYSIDERR to be returned to the user application.
  9. Another ALLOCATE request is issued some time later. The connection still shows in AVA state but all the user contention winner sessions have TCTESLGI turned off (No SIMLOGON allowed). The state of the connection is in service and available but no session is immediately available for allocate. DFHALP ALLOCATE is called and an ALLOCATE type AID is created. DFHALP calls ZISP ATI. DFHZISP cannot find any session to SIMLOGON and just returns to ALP with a RC of x'0000' where CICS issues a SUSPEND. All ALLOCATE requests after this will wait for the connection to be re-established.

The suspended user task will only get resumed after one of the following events occurs:
  1. The other side of the connection sends a BIND request.
  2. IMS or the connection is re-established. This can be done by the CICS operator with a CEMT SET CONN(REL)
    command followed by
    CEMT SET CONN(ACQ)
  3. DTIMOUT causes the task to abend AAL1. This will get rid of the hung tasks, but will not reset the connection to allow it to be used.

If Limited Resources are not required, a better option is to remove it and allow the sessions to remain bound and ready to work.

Resolving the problem

Remove the cause of the Limited Resource.

You can circumvent the problem by releasing and reacquiring the connection when the allocate requests hang.

Product Alias/Synonym

CICS/TS CICS TS CICS Transaction Server CICS/VSE VSE z/VSE

Rate this page:

(0 users)Average rating

Document information


More support for:

CICS Transaction Server
Terminal Control

Software version:

1.1.1, 3.1, 3.2, 4.1, 4.2, 5.1

Operating system(s):

z/OS, z/VSE

Reference #:

1105317

Modified date:

2012-12-07

Translate my page

Machine Translation

Content navigation