SNAX Connection Manager (SNAX/CM) Manual

Creating a User-Written Server Process
SNAX/CM Server
4–10 097842 Tandem Computers Incorporated
Validation In the sample server example provided, the XID and callstring validation processes are
included with the server.
When a call validation message comes into the server, the server does a
straightforward comparison. The server goes to a call address list and scans through
the list to see if the call address received in the message matches anything in the list. If
there is a match, the server returns a positive (or ACCEPT) response; if the server
doesn’t find a match, it returns a negative (or REJECT) response.
When the server receives an XID validation message, it goes to the XID list and scans
to see if there is a match. As before, if there is a match, the server returns a positive
response; if the server doesn’t find a match, it returns a negative response to the XID
validation message.
Both XID and call address values are determined to be valid whenever the server
accepts user commands that identify such values. The server process merely adds the
values to the appropriate list as it receives user commands.
If you want to include criteria other than the basic validation function, you can add to
or delete from the example callstring and XID validation lists. For example, if your
application does accounting based on connection times, the XID value can be used as a
check for billing purposes. You can compare the XID values with user log-on
information that started the billing process, or use the XID value to restrict additional
connection time when users incur unusually high charges.
Defining LUs The LU list is built when user commands are issued. When SNAX/CM issues a
CONNECTED message, it sees the LU names and creates a list of alias LU names for
that particular connection using the LU count. The server can configure up to 255 LUs;
you must specify the process you want to be performed for each LU, identified by
number. You can select the same LU number as many times as you want, because you
can process multiple functions for one LU.
When the server receives a CONNECTED message, the server searches for the first LU
and checks the option specified in the command to define that LU, as follows:
The server first determines how many LUs named LU #1 are in the list.
The server finds the first one, determines it should use Process 1, calls the user
code to use Process 1, processes it, and returns.
The server then scans for any more LUs named LU #1; if there are any, the server
determines the option for the next LU #1 and processes it.
When the server completes processing for LU #1, it then searches for any LUs
named LU #2, checks if there is anything on the LU list for LU #2, and proceeds as
instructed.