Depending on the session limits in effect and the type of allocation required, application programs may need to issue an APPCCMD CONTROL=OPRCNTL, QUALIFY=CNOS macroinstruction to ensure that a session is available for the conversation. If the session limits between the two LUs are 0, or no CNOS exchange has been processed on the requested mode name, a CNOS exchange must be performed to initialize or raise the session limits before the conversation can be allocated.

If an allocate request specifies QUALIFY=IMMED, a free contention-winner session must be available. If a session is not available, the application program must raise the local contention-winner session limit, if possible, before the allocation request can succeed. For more information on setting and negotiating session limits, see Managing sessions.

If the application program is not tracking session limits on its own, it can use the APPCCMD CONTROL=OPRCNTL, QUALIFY=DISPLAY macroinstruction to check on the session limits. If session limits have not been initialized, the DISPLAY request fails with a return code indicating that the partner LU name or the requested mode name could not be found.

If the application program attempts to allocate a conversation before session limits are initialized or when they are equal to 0, a return code of ALLOCATION_FAILURE_NO_RETRY is returned. The application program must correct the session limits before trying the allocation again.

As session limits are initialized or changed, new sessions might be started. This will result in the application's LOGON and SCIP exits being scheduled, if they are present.