IBM Support

CLS1 tasks are in both ALLOCATE wait and TCLASS maximum deadlock for APPC LU62 communications

Technote (troubleshooting)


You have advanced program-to-program communications (APPC) connections in a CICS region that do not acquire. The Change Number Of Sessions (CNOS) process never finishes. The start of communication between CICS and its partners suspends.
A dump of the CICS region shows some CLS1 tasks waiting for Transaction Class (TClass) MAXIMUM in the XM domain and other CLS1 tasks wait for ALLOCATE in the DS domain.


Hung LU62 communications between CICS and nonCICS partner programs


The APPC partner BIDs for SNASVCMG sessions instead of binding its own to send CNOS to CICS.

Diagnosing the problem

The following sequence of events creates this problem:

  1. CICS has more CLS1 tasks than can be handled quickly.
  2. You put the CLS1 tasks into a TClass to keep them from flooding the system and stopping all other work from happening.
  3. The partners detect the BIND request from CICS and wait for the CNOS request to arrive.
  4. If the CNOS has not arrived within a certain amount of time, the partner takes matters into its own hands and sends the CNOS to CICS.
  5. The partner does not BIND its own Contention Winner. Instead, it sends a BID to use the SNASVCMG session that CICS has already bound.
  6. The CICS request holds a TClass slot. The partner request holds the SNASVCMG session. Each waits for the other resource.
  7. The deadlock ensues.

Take these steps to identify the deadlock condition in a CICS dump using the CICS VERBEXIT:
  • Make a list of the CLS1 tasks in the DS section that are in ALLOCATE waits.
  • In the XM domain these tasks have a start code SD.
  • These tasks hold a TClass slot in the XM domain.
  • The DS domain will indicate the name of the CONNECTION in the RESOURCE NAME.
  • Find these CONNECTION names in the TCP section.
  • The bound ConWin SNASVCMG session has a transaction number in field TCTE_TRANNUM (TCTTE +x'14'). The TCTTE does not have TCTTECA (TCTTE +X'10') filled in.
  • Make a list of the task numbers in the SNASVCMG TCTTE control blocks.
  • In the XM domain these have a start code T.
  • These tasks are waiting on a TCLASS slot in the XM domain.

The deadlock happens because:
  • The SD started tasks take up a TCLass slot.
  • The SD started tasks are waiting to ALLOCATE a session.
  • The T started tasks control a session.
  • The T started tasks are waiting for a TClass slot.
Neither type of task will give up its resource.
Both types of tasks will continue to wait for the resource it needs.

You can see more information in the LU62 state machines at offset +x'1DA' in the bound SNASVCMG sessions:
Conversation 01 NOT_ALLOCATED
Bracket 02 IN_BRACKET

The Bracket, Contention, and Chain state machines say that the session is active.
The CONVERSATION state machine does not show active. The local task (SD) has not yet been started on the TCTTE. If the SD started task were able to allocate the session, it would set the CONVERSATION state to ALLOCATED. But, it can not because the session is already allocated to the T started task.

CICS sends certain messages if the connection is unbound before the CNOS can complete. You might find some of these messages:
DFHZC3470 CLS1 LU session failure caused by: route extension to cluster failed.
DFHZC3424 CSNE Session failure. Session terminated immediately.
DFHZC0161 CLS1 CNOS command for modename N/A to node xxxxxxxx connection yyyy has failed
DFHZC2443 CLS1 Request outstanding when node released.
DFHZC0162 CLS1 CNOS transaction for connection yyyy has failed with code X'FB96' subcode X'00'.

Because the CNOS processing never completes, CICS does not send the DFHZC4900 message.

Resolving the problem

There are several ways to correct this problem:

  1. The best way is to contact the support group for the partner program.
    Request that they fix their product so that it BINDs and uses its own SNASVCMG Contention Winning (ConWin) session to send its own CNOS request.
  2. As a quick way to try to free up some work, increase the TClass maximum for the class that the CLS1 task is assigned to.
    If you decide to remove CLS1 completely from the TClass, be aware that the CLS1 tasks may flood the system if you have a large number of CONNECTION definitions.
  3. Change how the APPC connections are acquired.
  4. Change the CICS region's CONNECTION definitions for all of the partners to have AUTOCONNECT=NO.
  5. Leave the SESSIONS' definitions AUTOCONNECT option as is.
  6. Write a script that issues the command SET CONNECTION ACQUIRED against a few of the connections at a time.
  7. This would stop CICS from issuing BINDs to all of the connections at once.
  8. The mass of partners would not know that CICS was up yet and would not BID for CICS' ConWin session because it would not be bound yet.
  9. CICS would then be able to process the ALLOCATE quickly enough to send the CNOS before the partner could interfere.
  10. If the partner initiates contact before CICS, then the partner will have had to BIND and use its own ConWin session.
This should keep the deadlock from happening.

Product Alias/Synonym


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 #: 1173844

Modified date: 25 September 2013

Translate this page: