WSOD Client Install Notes

It is possible to install NTRACE on a WSOD client. The following is a list of recommended changes to enable this installation:

CONFIG.SYS Changes

The CONFIG.SYS changes necessary for NTRACE on WSOD are similar to a local install, however there is a major difference. In the WSOD environment, the binding of protocols is not done using the NETBIND.EXE program.

NETBIND is the program which invokes the process where protocol drivers and MAC drivers exchange tables of information and function entry points. This allows these modules to programmatically call each other to send/receive frames, pass status information... It is the critical process that makes NDIS based drivers work with each other. In a traditional OS/2 environment the following statement in CONFIG.SYS will handle this binding process:

CALL=C:\IBMCOM\PROTOCOL\NETBIND.EXE

In a WSOD client, network access is loaded much earlier than in a locally installed client. This is necessary because the very earliest phase of the OS/2 boot process is done using a DOS based network redirector. However, this networking is slower and more restrictive than than the OS/2 based LAN Requester. So as early as possible, the OS/2 redirector is loaded and protocols are bound to the MAC driver. However the MAC driver is already in use and a DOS redirector is loaded. This strange environment is not something which the NETBIND.EXE was designed to handle. Instead these activities are taken over by the requester itself, in the module named NETWKSTA.200. This module initiates the binding process in a WSOD environment. Please see the following reference for more information: IBM's "WorkSpace On-Demand Handbook", SG24-2028-00.

In a WSOD client, the LANTRAN.LOG will start with the following entry:

Installing NETWKSTA.200 Version 5.0. IBM LAN Redirector (Oct 25, 1997)

In a traditional OS/2 client, LANTRAN will start with:

IBM OS/2 LAN Netbind

A hint of this behavior can be found on page 12 of the WSOD handbook, in section 2.2.2.1 "Environments That May Not Be Suitable for Migration to WorkSpace On-Demand". It states includes on its list of "Environments that will require additional planning:" the following description:

"Applications that require transport protocols other than NetBIOS/802.2 or TCP/IP."

This is a good description of NTRACE.OS2. While it is not a transport protocol, it occupies the location and mimics the functions of one. Then on page 25, in section 3.1.2 "Understanding RIPL", it states:

"When the NETWKSTA.200 driver is loaded, file redirection is switched to using the OS/2 network drivers and LAN Server file redirection."

This appears to clarify the role of NETWKSTA.200 in the way WSOD binds protocols to MAC drivers. Finally, on page 259, in appendix B, section 2.6 "Phase 5: Failure of the OS/2 Redirector (NETWKSTA.200)":

"Check CONFIG.SYS and insure that all network drivers are loaded PRIOR to loading NETWKSTA.200"

Thus it is important to load NTRACE.OS2 BEFORE NETWKSTA.200 in order to have it participate in the NDIS binding process. As with other NTRACE.OS2 installations, if PROTOCOL mode is in use, NTRACE must be the LAST PROTOCOL driver loaded. To ensure this is the case, place the NTRACE.OS2 on the line just before NETWKSTA.200. See the following example which includes support for both TCP/IP and NetBIOS based networking:

RUN=C:\IBMCOM\LANMSGEX.EXE
DEVICE=C:\IBMCOM\PROTOCOL\LANPDD.OS2
DEVICE=C:\IBMCOM\PROTOCOL\LANVDD.OS2
DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM /S
DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2
DEVICE=C:\IBMCOM\MACS\IBMTRP.OS2
DEVICE=C:\MPTN\PROTOCOL\SOCKETS.SYS
DEVICE=C:\MPTN\PROTOCOL\AFOS2.SYS
DEVICE=C:\MPTN\PROTOCOL\AFINET.SYS
DEVICE=C:\MPTN\PROTOCOL\IFNDIS.SYS
RUN=C:\MPTN\BIN\CNTRL.EXE
DEVICE=C:\TCPIP\BIN\VDOSTCP.VDD
DEVICE=C:\TCPIP\BIN\VDOSTCP.SYS
RUN=C:\TCPIP\BIN\VDOSCTL.EXE
DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200
DEVICE=C:\IBMCOM\PROTOCOL\NTRACE.OS2
IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2

Do not be confused by the fact that NETBIOS.OS2 is loaded AFTER NETWKSTA.200. This driver cannot be loaded before NETWKSTA.200 (the authors of this document do not know why), as it appears to hang the IPL process of the machine. NTRACE.OS2 must be the LAST protocol driver which is actually a TRANSPORT. NETBEUI is the transport level driver and NETBIOS is an API layer for the NETBEUI transport driver. As such it is not necessary to load this driver before NTRACE.OS2. Since NTRACE is loaded after NETBEUI, it will still be first in the chain of drivers to receive frames destined for NETBEUI.

PROTOCOL.INI Changes

The PROTOCOL.INI changes are the same as in a locally installed client. There are no differences for WSOD. See the Configuration section of this document for more details.

Location of NTRACE Files on the Server

None of the components require read/write access to their files, read/execute access is all that is necessary. As such, it is recommended that these files be stored in the \IBMLAN\RPL tree which is the best place for read/execute code. At a minimum, the following files must be visible:

\IBMLAN\RPL\NTRACE\PROTOCOL\NTRACE.NIF
\IBMLAN\RPL\NTRACE\PROTOCOL\NTRACE.OS2
\IBMLAN\RPL\NTRACE\APPLIC\NTRACE.EXE
\IBMLAN\RPL\NTRACE\LICENSE\LICENSE.NTO
\IBMLAN\RPL\NTRACE\MESSAGE\NTR.MSG

File Index Table (FIT) Changes

To make these files visible to the correct locations on the WSOD client, the default FIT(\IBMLAN\RPL\FITS\DFBB10US.FIT for WSOD v1.0) must be modified. At a minimum, the NTRACE.OS2 driver must appear in this FIT because this driver must be found during the machine's IPL.

Entries in this file must be kept to a minimum, as the size is limited. However, there is no problem with including additional entries in this file, the rest of the entries may be placed here as well. Example entries:

; NTRACE support
C:\IBMCOM\PROTOCOL\NTRACE.*       NTRACE\PROTOCOL
C:\IBMCOM\NTRACE.EXE              NTRACE\APPLIC\NTRACE.EXE
C:\IBMCOM\LICENSE.NTO             NTRACE\LICENSE\LICENSE.NTO
C:\IBMCOM\NTR.MSG                 NTRACE\MESSAGE\NTR.MSG

Running NTRDIAG.EXE on a WSOD Client

NTRDIAG.EXE WILL NOT run properly on a WSOD client machine. It was designed to run on a locally installed version of OS/2.

Though WSOD is just OS/2 Warp v4 running from a shared drive resource on a server, programs that scan all drives looking for files using wildcards (which resolve to DosFindFirst and DosFindNext APIs) will get unpredictable results. This means that NTRDIAG will not find any of the modules for which it is looking.

More importantly, since the WSOD client does not use NETBIND.EXE to bind its protocols to the associated MAC drivers, NTRDIAG will report that this module is not run from CONFIG.SYS. THIS IS NOT AN ISSUE.

Please read the section above on installation on WSOD for more details.