ODBC Server Installation and Management Manual

Installing the NonStop ODBC Server
HP NonStop ODBC Server Installation and Management Manual—429395-002
2-61
Checking Sessions
•
Check error messages you receive from the client application when a connection is
attempted.
•
Check your NonStop configuration by using the appropriate INFO statements.
•
If you have configured the NonStop ODBC Server to prelaunch NonStop ODBC
servers, check that they are running and are using the correct Guardian user
name.
•
Use the SCF interface to check on the status of the SCS and the NonStop ODBC
servers. For more information, see Section 4, Managing the NonStop ODBC
Server.
•
Start RUNFILTR, then try to establish a client connection. Observe the RUNFILTR
trace output and look for error indications. If other SCS processes are running, you
can identify records for your SCS by matching the process-name you set in the
SCS section.
Following is an example of RUNFILTR output when a client connects to a NonStop
ODBC server named $X716:
95-01-27 09:01:15 \TESS.$ZT1 Tandem.SCS.Dxx
000007 $ZDSS.1: session GZORN object state changed to started
95-01-27 09:01:17 \TESS.$ZT1 Tandem.SCS.Dxx
000007 $ZDSS.1: server \TESS.$X716 object state changed to started
•
Check the EMS messages for any information logged by the NonStop ODBC
server.
Checking Sessions
After a client has connected to a NonStop ODBC server successfully, these problems
could occur with the session:
•
The client encounters errors whenever it tries to execute SQL statements.
If the client application does not display error messages, you can invoke NonStop
ODBC server tracing to display the errors. You should set up a trace definition with
TRA_ERROR set to “Y.” You can then turn on NonStop ODBC server tracing by
setting TRA_MODE_ON to “Y” in your profile.
Check that the SQL language dialect in your ZNSPROF record is set correctly.
•
The session appears to be hung. The client has issued a request, but has not
received a reply.
Verify that the client is indeed waiting for a reply. If the client user is entering SQL
statements directly, as with ISQL, client status is usually easy to determine. If the
client user is running a self-contained application, however, status may be more
difficult to determine.
There can be a variety of causes for a hung session:
•
A state where some set of processes is mutually waiting (this usually happens
in the communications code)