CNOS processing in Db2
The distributed data facility of Db2 can request to alter the number of sessions with another system for a specific VTAM® logon mode. This automatic process is called change number of sessions (CNOS).
This topic contains a brief overview of the process as it relates to Db2; it should help you understand the messages that CNOS processing generates.
When sessions are started: The AUTOSES option of
the VTAM APPL determines whether,
and how many, sessions are started at the time CNOS is negotiated.
If AUTOSES is 0, then the sessions are not started at CNOS negotiation
time; they are started as they are needed. AUTOSES should generally
not be 0, because then Db2 is
not informed if CNOS fails, and you receive a resource unavailable
SQL
code with the first SQL request to the remote system.
If AUTOSES is not 0, then sessions are started as follows:
- If AUTOSES is equal to or less than the number of contention winner sessions for a specific Db2 subsystem, then the number of sessions that are automatically started at CNOS negotiation is equal to AUTOSES.
- If AUTOSES is greater than the number of contention winner sessions for a specific Db2 subsystem, only the contention winner sessions are automatically started at CNOS negotiation.
Each LU has its own value for the number of contention winner sessions to start. The total number of sessions started on behalf of a CNOS negotiation request is the sum of the sessions started at each site.
Assume that USIBMSTODB21's DDF is started first. CNOS processing fails because USIBMSTODB22's DDF has not yet started, and you get a message at the console. When USIBMSTODB22's DDF is started, CNOS processing can begin. The CNOS negotiation process is as follows:
USIBMSTODB21 has a DSESLIM value of 50, and a CONVLIMIT value of 80. For this first step in the CNOS negotiation, the CONVLIMIT value overrides the DSESLIM value, so USIBMSTODB21 sends an initial CNOS value of 80 to USIBMSTODB22. During this initial negotiation step, the LUMODES information for USIBMSTODB22 is not yet used. USIBMSTODB22 replies to USIBMSTODB21 with its DSESLIM value of 40, which is less than the initial CNOS value of 80. An initial negotiated value of 0 to 40 sessions is therefore established. A second and final negotiation, as described in step 2, is then initiated by USIBMSTODB22. The following image shows the result of the CNOS negotiation that was started by USIBMSTODB21. Overridden values are noted with asterisks (*). After the number of sessions is negotiated, both systems begin starting the number of sessions that are specified in their respective AUTOSES options. VTAM does not start all 40 sessions unless the two AUTOSES values total up to 40 or greater. Instead, VTAM delays starting the other sessions until they are needed.

- Everything up to this point occurred because USIBMSTODB21 initiated CNOS, resulting in an initial negotiation of 0 to 40 sessions. Now, as shown in the following figure, USIBMSTODB22 initiates a second CNOS negotiation back to USIBMSTODB21 because USIBMSTODB22's LUMODES table has a CNOS limit specified by the CONVLIMIT value of 50. USIBMSTODB21's VTAM sees that Db2 allows up to 80 sessions, so VTAM sends the CNOS reply message back to USIBMSTODB22 with an unchanged value of 50. USIBMSTODB22's CONVLIMIT value of 50 is compared with USIBMSTODB21's overridden value of 80 from the previous CNOS, and a final value of 40 to 50 sessions is negotiated. The following image shows the CNOS negotiation from USIBMSTODB22 to USIBMSTODB21. Overridden values are noted with asterisks (*).
If the new negotiated value is smaller than the number already started by USIBMSTODB21, VTAM terminates the number of sessions that makes up the difference. If the CONVLIMIT value at USIBMSTODB22 is 20, for example, VTAM terminates 20 sessions on behalf of the request from USIBMSTODB22 because the lowest negotiated value always wins. If a session is currently being used by a conversation, the session is terminated as soon as the conversation is deallocated.