ODBC Server Reference Manual

Architecture Overview
HP NonStop ODBC Server Reference Manual429151-002
2-36
SQL Communication Subsystem
SCS maintains a cache of username and server class name relationships that it
checks before contacting NOSUTIL. If the username is found in the cache, Steps 3, 4,
and 5 in Figure 2-30 are omitted.
When the server class name is determined, SCS selects a free NonStop ODBC server
from the class, starting one if necessary. SCS passes the original connect message
from the client to the NonStop ODBC server.
The NonStop ODBC server reprocesses the connect message from the beginning. The
server process checks the NonStop ODBC Server mapping table ZNSALT to
determine if the username is an alias; if it is, the NonStop ODBC server uses the
corresponding logical username. The server process accesses ZNSUMAP, ZNSALT,
and ZNSUS to determine the attributes of the username—the Guardian name, server
class name, and profile name to use. Finally, the NonStop ODBC server accesses the
ZNSPROF table to determine the profile settings and, optionally, the ZNSCON,
ZNSGOV, and ZNSTRA tables to determine the control, governing, and trace settings.
If the username is not found in ZNSALT, the NonStop ODBC server attempts to decode
it to a Guardian name. If successful, the DEFAULT profile is used. In any case, if a
Guardian name is obtained, the NonStop ODBC server authenticates the client by
USERAUTHENTICATE command with the Guardian name and the password from the
connect message.
If the logon fails, the NonStop ODBC server returns an error to the client; the process
then returns to the set of free servers in the class. If the connection is successful, the
NonStop ODBC server initializes itself according to the settings of the profile and
returns a “successful connection” message to SCS.
Figure 2-30. SCS Determination of Server Class
NOSUTIL
SCS
3
4
5
ZNSALT
ZNSUMAP
SELECT
USERNAME
Server Class Name
NonStop ODBC
Server Catalog
Guardian username
VST034.vsd