ODBC Server Reference Manual

Architecture Overview
HP NonStop ODBC Server Reference Manual—429151-002
2-17
Message Flows
To improve performance, SCS caches the look-up done by NOSUTIL, so messages
3, 4, and 5 can often be omitted. When SCS is dynamically configured while in
operation, the cache is reset to an empty state.
Having connected successfully, the client can start sending SQL statements to
execute.
Using the SQL API, the client submits one (or more) SQL statements; DBLIB or the
NonStop ODBC/MP driver sends a logical message to the NonStop ODBC server. The
NonStop ODBC server executes the statement or statements and replies with the
results. The client is then free to submit more SQL statements.
Figure 2-17. Message Flow for a Client Connection
[
1, 2 Client connection causes a message to be sent to the designated SCS. The
message contains a username, a password, and perhaps a database name.
3 SCS recognizes the connect message and starts a thread for it. SCS sends a
message (containing the connect message) to NOSUTIL to determine what
server class should be used.
4 Using the username from the connect message, NOSUTIL accesses the
NonStop ODBC Server mapping tables (using NonStop SQL/MP) to determine
the Guardian name and the server class for the client.
5 NOSUTIL returns the information to SCS.
6 SCS picks a server from the designated server class (or starts one, if
necessary) and passes the connect message to it.
7 The chosen NonStop ODBC server processes the connect message. Using
the password from the connect message and the Guardian ID from NOSUTIL,
the client is authenticated. The NonStop ODBC server initializes itself and
replies to the connect message.
8, 9 The reply is sent to the client to complete the connection. The client can now
proceed to execute SQL statements.
NonStop ODBC
Mapping and
Configuration
Tables
Communication
Processes
NOSUTIL
SCS
Client
Connecting
NonStop ODBC
Server
1 2
3
4
5
6
789
NSSQL
VST021.vsd