Connecting in SuperServer mode to an NT server

Date:Archived
Product/Release:LANSA for Windows and LANSA Open
Abstract:Some things to look at before trying to establish a SuperServer connection from either a LANSA for Windows application or a LANSA Open one to an Windows Server box
Submitted By:LANSA Technical Support

Since LANSA for Windows Version 7.5 it is possible to run in Super Server mode with the server database residing on a Windows Server PC (prior to 7.5 only AS/400 servers were supported). This method offers substantial performance advantages against the standard LANSA for Windows network access. It also offers integration with LANSA Open, as LANSA Open can be used to access the same LANSA for Windows database.

Below is a check list that will some problems to be avoided that are very common when setting up this type of environment.

On the server:

  1. Verifying that the listener has been installed correctly.
    As in the AS/400 environment, on the NT Server there also needs to be a job listening for connection requests from the clients. The listener is installed on the NT Server provided TCP/IP connection method is selected during the LANSA for Windows installation. It is installed as a NT service with the name LConnectServices.
    By default LConnectServices will not start automatically when the Windows NT server system is booted. Once the LANSA for Windows server installation has finished, please go the Control Panel/Services and verify that a service with the above name exists. To make it start automatically, use the Startup button and then change the Startup Type to Automatic.
     
  2. Starting the listener.
    * Invoke the LANSA Communications Extension Administrator, choose the Advanced then Listener options.
    * Select communication method socket and change the Number of Threads to Listen On value to a value greater than 2.
    * Choose the Start Listener button.
     
  3. Verifying that the listener has started.
    * Invoke the Windows NT Task Manager.
    * Check that a Process named LCOLIST.EXE (or lcolist.exe) is active. LCOLIST is the "listener" that listens for TCP/IP requests from the client systems. If it is not active on your Windows NT server then there is no way that any of the following things will work.
    NT Task Manager

    If it is not active, then there are 2 possible causes :

    1. It has not been installed correctly. Search for LCOLIST.EXE on the server system.
    2. It has not been enrolled as a system service correctly. Get it to (re)enroll itself as a system service at any time by executing the command : LCOLIST -I from a command line.
       
  4. Optional but recommended: define a LX_LANSA ODBC data source as a System data source. This will make the database visible to any Client PC user in the NT network. Otherwise, the database will only be visible to the user that created the data source.

On the client

  1. Ping the NT Server to verify that TCP/IP has been correctly configured in both Server and Client.
  2. In exactly the same way an AS/400 server was enrolled in the LANSA Administration utility, create an entry for the NT Server.

    In theory, the Client should be ready to connect to NT using either a LANSA for Windows or LANSA Open application. In reality, there are a couple of other things to check:

    1. NT is password case sensitive. To connect to the NT server the application will need to supply a user and password, again, same as when connecting to an AS/400. Make absolutely sure that the password supplied is in the same case as it was entered on the NT Server's User Manager. If in doubt, verify by logging off Windows NT Server and logging back on.
    2. ONLY FOR LANSA Open: go to the LANSA Open configuration utility. Change the Host Name to the Server's name and make sure that the Host type is checked for ASCII.

    LANSA Server Configuration

Trouble shooting

Tracing the communications is done in the same way as currently by selecting the different tracing options in the LANSA Communications Administrator.

Look for the simplest solution first

Search for an X_ERR.LOG file on the client and on the server using the Windows find facility. Multiples of these may be found (it is recommended that all are deleted and that the errors are reproduced to ensure that the latest errors are being displayed). Invoke and editor on the file and scroll to the bottom. An entry like this may be found :

======Wed Jun 25 13:35:43 1997
Process : QADBP01 QAH - Data Base TestingFunction
: Not known/applicableStatement
: Not known/applicableRoutine
: pfnLoadObjectMessage : (0042)
- Unable to load/locate FUNCTION QADBF01.OS Error Message Number : 126

This is a simple application failure that indicates that a function named QADBP01 could not be found (presumably because it was not compiled). If this application was being run on the client then this information would appear in a Fatal Error dialog box, the cause would be instantly recognizable and the problem rectified.

Similarly, start an X_RUN command running on a client and specify an invalid DBMS user profile and a dialog box like this should appear:

Error Message

Again the cause is instantly recognizable and can be corrected. If however, the X_RUN  is run on a server (via a CONNECT_SERVER) operation, then the server cannot cause the dialog box to pop-up on the client in the same way. It can't even pop-up on the server either (because its a service job and has no desktop) but that's another story.

A communications error will occur back on the client and to decide what it means look in X_ERR.LOG on the server where entries like this will be found:

====== Fri Jun 27 08:41:33 1997
Process : Not known/applicableFunction
: Not known/applicableStatement
: Not known/applicableRoutine
: X_DBM_Connect(SQLConnect)Message
: [Sybase][ODBC Driver]Invalid user authorization specification:
invalid userid or passwordSQL Error Code : -103

In other words, what would appear in a Fatal Error dialog box is always logged into the X_ERR.LOG file.

Looking for more complex problems

A more serious application problem may be encountered where an application effectively crashes and no useful error information is produced. In such cases LANSA/X tracing may be turned on.

To turn on tracing do either of the following :

To trace on the client and the Server: Start tracing the client application. This will automatically turn tracing on for the server job (because the values are inherited by the server job).

To trace on the server only: Put tracing keywords into the override area of the DEFINE_OTHER_SERVER request or if using automatic connection using the PSxx parameters, include the following:

ITRO=Set to Y to turn internal tracing on.
ITRL=Set as a number in the range 1 to 9 to increase the detail of the trace.

To trace on the server only (LANSA Open): Define the X_RUN environment variable with the tracing option keywords mentioned above. Remember that it must be set as a system variable available all processes (The Windows NT process that handles the server side of the session runs as a service, independent of the desktop). Stop and re-start the listener after specifying this variables.

Look for files called x_tracennn.