Session busy when using LINK

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

On Dec 12th 2013, more details on the usecase was requested. This was followed up on May 14th 2014. No information has been received as of July 18th 2014, so this RFE is being closed.

Please see earlier comments with request for more information on this. This RFE will shortly be closed with a reason of 'no information provided' if we do not hear back soon.

Mark,

You can already do this at a global level for the link using QUEUELIMIT and MAXTIMEOUT.
There is also the XZIQUE global user exit which would you to be be more selective on which sessions to queue.
Do these satisfy your requirement?


QUEUELIMIT({NO|number})
specifies the maximum number of allocate requests that CICS is to queue while waiting for free sessions:

NO
There is no limit set to the number of allocate requests that CICS can queue while waiting for a free session. In this case, a value of X'FFFF' is passed on the XZIQUE parameter list (in field UEPQUELM).
number
The maximum number of allocate requests, in the range 0 through 9999, that CICS can queue on the connection while waiting for a free session. When the number of queued allocate requests reaches this limit, subsequent allocate requests return SYSIDERR until the queue drops below the limit.

This queue limit is passed to an XZIQUE global user exit program on the XZIQUE parameter list if the exit is enabled.

You can also control the queuing of allocate requests through the MAXQTIME attribute, and through an XZIQUE global user exit program. See the MAXQTIME attribute for more information about controlling queues.

MAXQTIME({NO|seconds})
specifies a time control on the wait time for queued allocate requests waiting for free sessions on a connection that appears to be unresponsive. The maximum queue time is used only if a queue limit is specified for QUEUELIMIT, and then the time limit is applied only when the queue length has reached the queue limit value.

NO
CICS maintains the queue of allocate requests that are waiting for a free session. No time limit is set for the length of time that requests can remain queued (though the DTIMOUT mechanisms can apply to individual requests). In this case, a value of X'FFFF' is passed on the XZIQUE parameter list (in field UEPEMXQT).
seconds
The approximate upper limit on the time that allocate requests can be queued for a connection that appears to be unresponsive. The number represents seconds in the range 0 through 9999.

CICS uses the maximum queue time attribute to control a queue of allocate requests waiting. When the number of queued allocate requests reaches the queue limit (QUEUELIMIT), and a new allocate request is received for the connection, if the rate of processing for the queue indicates that, on average, the new allocate takes more than the maximum queue time, the queue is purged, and message DFHZC2300 is issued. When the queue is purged, queued allocate requests return SYSIDERR.

No further queuing takes place until the connection has successfully freed a session. At this point, CICS issues DFHZC2301 and resumes normal queuing.

Exit XZIQUE is invoked when an allocate request for a session is about to be queued, and when an allocate request succeeds following previous suppression of queuing.

When invoked
Whenever:

An allocate request for a session is about to be queued
An allocate request succeeds following previous suppression of queuing.