Return to SNA Crossroad 2 Feb 1995
Summary: SNA defines MODENAME as a method of selecting among different paths to the same server. This is not usually important, since most PS/2 or AIX machines have only one available SNA path to the host. SNA also allows one to limit the number of concurrent requests between the same client and server LUs, although this is also generally not helpful.
Two departments are connected by an SNA network. Two phone links are available to carry traffic. One runs at low speed (say 19200 bits per second) over regular phone wire. Another runs at high speed (say 1.5 million bits per second) but through a satellite link. The signal takes a few seconds to bounce off the satellite, so if two short messages started through the two lines at the same time, the ordinary phone line would send the message faster. For larger amounts of data, the faster speed of the satellite line makes more sense even if the first bit is delayed by a few seconds before it gets to its destination.
This kind or problem is commonly referred to as Class of Service. It is the network version of the supermarket checkout lines. Some lines are "12 items or less" and allow quick processing of trivial requests. The other lines are designated for bulk processing (what is generally called "throughput" - the total amount of bulk data processed over time).
In SNA, Class of Service is designated by selecting a MODENAME. Whatever its original intent in the architecture, MODENAME has evolved to mean many different things:
By now it should be clear that MODENAME tries to put 4 quarts of water in a one quart jar. Some matching MODENAME must be configured on every SNA client and server node. In OS/2 the Communications Manager supplies a few sample names, including a default name "BLANK" (not a missing name, but the 5 letters of the word spelled out). However, if there is a mainframe around, then you might need to accommodate the names that the VTAM programmers originally created.
A key feature of APPC is that sessions are established between subsystems on the two computers instead of between application programs. For some reason, SNA regards it as important to limit the number of concurrent sessions. Presumably this is a holdover from older systems with more limited virtual memory. If an application program starts up and all the permitted sessions are in use by other applications, then the new program waits until an existing session is deallocated when one of the previous transactions end.
If one machine is always acting as the client, and the other machine is always the server, then there is no contention for the sessions. However, when both computers contain a mixture of clients and servers, then a problem can occur. Suppose the maximum number of sessions has been created and one of the sessions is currently not in use. Suppose then that a client program starts up in each of the two computers. Who gets to use the idle session, and who has to wait?
Each session has a polarity. When the session is created, one of the two computers is declared to be the "contention winner." When client programs start up simultaneously on the two computers, use of the session will be given first to the client on the computer that is contention winner for that session.
The first time that the APPC subsystems on the two computers establish a connection, they have to negotiate the number of permitted sessions and the distribution of contention winner status among the sessions. If the system programmers on both computers have supplied the same parameters, there should be no problem. However, if one computer has been configured for more sessions that the other computer will permit, then adjustments must be made. This process is called CNOS.
CNOS occurs by the exchange of information on a special control session between the two subsystems. This control session remains active. Later on, the operator can dynamically change the number of sessions permitted. It is even possible to "drain" the connection between the computers by setting the session limit to 0. After this, as each active transaction ends the session it was using is closed and no new sessions or transactions will start.
Copyright 1995 PCLT -- Modename, Session Limits, Class of Service -- H. Gilbert