Debugging Tips for SQL Server on Novell Netware 8-17-92 Summary SQL Server can work reliably on Novell Netware. This article contains some tips for correcting common problems encountered in this environment. SQL Server 4.2 is compatible with OS/2 2.0 as a server and as an OS/2 client. The rest of this document pertains primarily to OS/2 1.3 and the Novell Requester 1.3. More Information The software that allows SQL Server to function on a Novell network is the "Novell Netware Requester for OS/2, version 1.3." The Requester is a single software item that serves several functions. These functions are: (1) Allows OS/2 workstations to communicate with Netware file servers. (2) Contains OS/2 protect-mode versions of the Netware utilities, such as MAP and LOGIN. This way a user of an OS/2 workstation can use the same familiar Netware utility commands as he does on an MS-DOS workstation. (3) Contains named-pipe support for OS/2, Windows, and MS- DOS workstations. It is this support that allows client workstations to communicate with SQL Server. In general a bottom-up approach to debugging is suggested. This means reduce the configuration of each workstation involved to the minimal level, until named pipe connectivity is achieved. This is especially important with MS-DOS/Windows workstations. Following is a checklist of debugging tips, in very roughly priority order. (1) Run the latest update to the Netware Requester, which is currently NSD004. It is available on the NOVLIB forum of CompuServe. To install it on an OS/2 workstation (including the one SQL Server runs on), just insert the diskette and type NSDINSTL. You should first shut down SQL Server before upgrading the Requester. If any files fail to copy because the existing old files are open, you may need to re-boot the machine on an OS/2 boot diskette, and manually copy the problem files over. To install on an MS-DOS/Windows workstation, just copy over the two files DOSNP.EXE and NETAPI.DLL. On a Windows machine the NETAPI.DLL you copy over should have a size of 7168 bytes. It may be in a subdirectory called WINDOWS.NP, or in a separate ZIP file. (2) Use the MAKEPIPE/READPIPE debugging programs that ship with SQL Server. Run MAKEPIPE on the OS/2 machine, and run READPIPE on the client. MAKEPIPE requires no parameters. Example of READPIPE syntax: "READPIPE /Smyserver /dhello". Do not use a space after the /S or /d. (3) If MAKEPIPE/READPIPE fails, it is a pure network or configuration problem, unrelated to SQL Server. Concentrate resolution efforts on correcting the network/configuration problem. The error codes MAKEPIPE/READPIPE report are standard OS/2 error codes. They are documented in a number of references. You can also get information from the OS/2 command prompt on many of these error codes. Example: "HELP SYS5", where 5 is the error code in question. (4) Use OS/2 local pipes. After you start SQL Server, switch to an OS/2 session on the same machine. Try to log in to SQL Server using ISQL or SAF, but do not supply a server name. This will bypass the network component and use OS/2 local pipes. Sometimes this works, but when you do supply a server name for ISQL/SAF, the login fails. This means SQL Server is running properly, but there is a configuration problem with the network software. This test can only be performed on the SQL Server machine, not from a SQL Server client workstation. (5) If the OS/2 SQL Server machine completely hangs such that CTL-ESC or ALT-ESC is impossible, or ever prints out the trap code "internal processing error", this is a ring-0 software problem. It has nothing whatsoever to do with SQL Server, but is caused by a device driver or faulty hardware. Successful problem resolution will depend on acknowledging this and focusing further resolution efforts on the true cause of the problem. (6) For an MS-DOS workstation, this is the recommended order in which to load the network TSRs: * IPX (Novell IPX/SPX network support) * DOSNP (Novell named pipe support) * NETX (Novell shell; allows connection to Netware file servers; not necessary for solely SQL Server connectivity) * DBNMPIPE (Microsoft Named Pipe Net Library TSR) (7) For a Windows workstation, the order is the same, with the following exceptions: * Don't load IPX or DOSNP into high DOS memory (loading high is possible with the latest VIPX.386, from Novell's NOVLIB CompuServe forum) * Don't load DBNMPIPE. The Windows file DBNMP3.DLL assumes this function. If you need to run an MS-DOS SQL Server program from a Windows MS-DOS session, load DBNMPIPE in that session. (8) On MS-DOS/Windows clients, for debugging purposes rename your AUTOEXEC.BAT and CONFIG.SYS files, reboot the machine, and load by hand only the minimum number of TSRs needed to establish named pipe communications. These files are: IPX and DOSNP. After loading these 2 files, try the MAKEPIPE/READPIPE test. (9) MAKEPIPE/READPIPE may return error 6 "Invalid Handle", if after rebooting either client or server you don't wait about 60 seconds for the Novell software to establish communications. (10) If you are running Windows 3.0, make sure you have downloaded the latest Novell/Windows update from the NOVLIB forum CompuServe. Currently, this is WINUP6.ZIP. Apply this according to the directions contained therein. (11) You are trying to run the Windows version of SQLAdmin, and you get the error: "The network has not been started, cannot continue." This is caused by not having the correct version of the Novell NETAPI.DLL file. There should be only a single copy of NETAPI.DLL on your MS-DOS/Windows workstation, and it should have a size of 7168 bytes. This file can be found on any Requester or Requester update diskette since version 1.3. Common reasons for having the wrong version of NETAPI.DLL are: * Since it must be copied manually from the Requester diskette, this was accidentally omitted. * The OS/2 version of NETAPI.DLL was accidently copied to the Windows machine. * Other application software such as Q+E may have installed its own copy of NETAPI.DLL. (12) On an OS/2 machine, it is best to have a only single copy of NETAPI.DLL. This file should be of size 2291 bytes. It is available only on the original version 1.3 Requester diskette. It is not on NSD004. However, you do not need NETAPI.DLL for SQL Server to run, or for client workstations to access SQL Server. You do need this particular NETAPI.DLL for the OS/2 SAF program, when run on the SQL Server machine, to fill the "Server List" box. (13) If you use IBM OS/2 EE, you should be aware of the following points. You may not be able to run EE components such as COMM Manager that are dependent on the special IBM NETAPI.DLL installed in the MUGLIB directory. Both the Requester and some OS/2 EE components require their own special copies of NETAPI.DLL. OS/2 architecture only allows a single .DLL of a given name to be used. Therefore you must decide whether you want to run COMM Manager or Netware Requester. If you want to run the Requester, you must rename or delete the existing NETAPI.DLL in the MUGLIB directory. Alternately, some customers have reported they are able to use both EE components such as COMM Manager, and the Netware Requester by using the following procedure. Place the Novell NETAPI.DLL file in the \SQL\BINP directory. Leave the IBM EE NETAPI.DLL file in the \MUGLIB directory. Place a dot at the beginning of the OS/2 LIBPATH setting. Run SQL Server programs such as SAF from the \SQL\BINP directory. This is not a supported configuration. (14) One the OS/2 SQL Server machine, following are the recommended settings that concern SQL Server for the Netware NET.CFG file: Protocol Stack SPX retry count 50 sessions 255 (alternately, #server sessions + #client sessions + 1) Named Pipes server sessions 255 (alternately, # server sessions + #client sessions) client sessions 50 (alternately, # client sessions desired) service threads 32 (15) If you need more than 4 simultaneous named pipe connections on an MS-DOS/Windows machine, use the following settings in your NET.CFG or SHELL.CFG file: NP MAX OPEN NAMED PIPES=X (Where X is total number of named pipes that can be opened. Maximum is 128) NP MAX COMM BUFFERS=Y (Where Y is about X*2, but <= 40 In other words, you should specify about 2 buffers per pipe, up to a limit of 40) (16) If you need more than 14 simultaneous name pipe connections on an MS-DOS/Windows machine, in addition to the above settings, you also need to add the following to your NET.CFG or SHELL.CFG file: SPX CONNECTIONS=Z (Where Z is the total number of named pipes that can be opened) (17) On an OS/2 machine, edit your CONFIG.SYS and set the "THREADS=" parameter to 255. (18) Note that the name of your SQL Server which you supply during the Requester installation must not exceed 8 characters in length. (19) If other steps fail, it is often useful to delete all traces of the Netware Requester from the OS/2 SQL Server machine, and re- install. This process only takes a few minutes if done properly. Make sure to back up your CONFIG.SYS file before taking this step. To delete all traces of the Netware Requester, do the following: * Backup your CONFIG.SYS file * Delete all references to the Requester in CONFIG.SYS. This includes the PATH, LIBPATH, and DPATH, as well as the Requester section at the bottom of CONFIG.SYS * Reboot the machine * Delete the entire Netware directory * Install the 1.3 Netware Requester * Install the NSD004 update (20) The SQL Server 4.2 SQLAdmin program will work on a Novell network, with the following exceptions: * You cannot use the Manage/System, Manage/Errorlog option to remotely view the SQL Server errorlog. If you try this function, it may also prevent proper functioning of other SQLAdmin functions such as timed backup/restore of database. * You cannot use the Manage/System, Manage/Start option to remotely start SQL Server. * You cannot use the NETSQL commands to control the SQLMONITOR program. NETSQL will only function on Lan Manager-compatible networks. * You cannot use the Manage/Databases, Manage/Backup, Scheduled Backups from the OS/2 version of SQLAdmin on the SQL Server machine. (21) If server names don't show up in the server list box of SAF or SQLAdmin, or you get a NetServerEnum error, you can usually log in by manually supplying the server name. This indicates a problem with the NETAPI.DLL file, which is required for the NetServerEnum API call to function. Also, for SQLAdmin you need to use the /n parameter. You can add this by selecting the SQLAdmin icon, then the File/Properties option of the Windows Program Manager. (22) Sometimes the list of server names visible in SAF, SQLAdmin, or similar DOS/Windows tools may be incomplete. You cannot connect to servers not on this list, even by manually typing in the server name. This is expected behavior based on the current implementation of Novell's named pipe support. The Novell OS/2 Requester broadcasts a SAP (Service Advertising Protocol) packet about every 30 sec. During bootup, the Novell IPX/DOSNP software will listen for these SAP packets for about 60 sec. All packets received during this time comprise the list of SQL Servers to which connections can be made. Servers not on this list cannot be connected to. Various network factors such as traffic, bridges, routers, etc., can create this situation. This behavior is currently hard-coded in Novell's software and cannot be changed. It may be possible to connect to the desired server by rebooting the workstation. Placing the following parameter in the SHELL.CFG file of the MS-DOS/Windows workstation may also help: NP MAX MACHINE NAMES=50. (23) Sometimes older files from a previous Requester installation may be in a forgotten subdirectory that is on the PATH, or OS/2 LIBPATH. Use the OS/2 or Windows File Manager, or if you are running MS-DOS 5.0, the DIR /s command to search the disk for older copies of these files. If found, delete them, and insure that there is only a single copy of the current version of these files. (24) If you are unsure what version of the Requester you are running, you can often use the Novell NVER command to examine this. However the most reliable way is to use the OS/2 or Windows File Manager, or the MS-DOS 5.0 DIR /s command to search the entire hard disk for certain versions of the Requester files. This has the added benefit of detecting multiple/old instances of these files. It is more reliable to use the file byte count as an identifier rather than the file date. Following are the suggested versions of the Requester files for which to check: OS/2 ---- File Size Version NPDAEMON.EXE 22432 NSD004 NWCALLS.DLL 67856 NSD003/4 NETAPI.DLL 2291 All versions MS-DOS/Windows -------------- File Size Version DOSNP.EXE 9971 NSD004 NETAPI.DLL 7168 All versions