Installing Warp Connect Using a Netware Server

From Wiki
Jump to: navigation, search

Return to The Warp Pharmacy:Software

Last update: 6th November, 1995


You've tried setting up Warp Connect to install over the Network with Netbios as a transport, but because of routing issues or the use of Netware servers as bridges, Netbios just doesn't work for your site as a transport mechanism for installing Warp.


Any PC and Networking hardware that supports Netware servers and OS/2 workstations with both ODI and NDIS drivers for their LAN cards.


Warp Connect remote install was built upon SRVIFS, a Netbios based client server architecture. For shops that require a routable protocol, or use Netware servers for bridges, this can be a major impediment.


This technique can be used to install Warp Connect, the base operating system and any or all of the networking add-ons from a Netware server using IPX as a protocol. This technique minimally modifies the the standard Netbios and SRVIFS based LAN install procedures so that there is as small an impact on the install as possible on the install logic.

There are six main issues to deal with under this scenario:

Creating the LAN transport (LT) diskette with a minimal Netware requester

To create the Netware LT Diskette, I first installed Warp Connect on a PC with a CD-ROM drive, and made it a code server, creating a set of install diskettes that included an SRVIFS LT Diskette. I took this SRVIFS LT Diskette and removed the SRVIFS code, then substituted Netware requester code. The Netware requester code is 90% at the 2.01 level - except that the ODI driver was a more current one for the card, the Netware message files were from the 2.0 requester and I used the NWSTART.EXE from the newest R211FT.EXE to ensure that the requester had a connection ID prior to running login.exe in the config.sys.

I tore out the SRVIFS lines from the LT diskette's config.sys and replaced them. Here are the lines in my config.sys with the relevant CID and NW requester stuff.

 DEVICE = token.SYS
 device = route.sys board=1
 call=l:\os2\login.exe /script nul fs1/os2inst
 call=\map.exe z:=fs1/vol:connect
 call=\map.exe w:=fs1/vol:GRPWARE\CLIENTS\LADCLT
 call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
 SET exitwhendone=1

Here is a directory listing of the files used in the minimal Netware requester for the LAN Transport diskette.

 NETH     MSG     3029   5-02-89   8:15a
 NET      MSG     2997   5-25-90   8:47a
 MAP      EXE    25527   7-18-91  11:08a
 IPXCALLS DLL     1348   5-21-92   4:27p
 NETAPI   DLL     1328   5-28-92   4:33p -- change name to NWAPI.DLL
 DDAEMON  EXE     9085   9-04-92  12:13p
 ROUTE    SYS    45440  11-10-92  10:40a
 LSL      SYS    20772  11-25-92   2:31p -- change name to nwlink.sys
 NWDAEMON EXE    40089   1-21-93   5:20p
 NWCALLS  DLL   108704   1-27-93   6:27p
 NWIFS    IFS    35684   1-30-93   9:44a
 IPX      SYS     9780   1-30-93  11:49a
 NWREQOS2 MSG    17902   2-02-93   5:58p
 NWREQ    SYS    30324   2-03-93   9:42a
 NWCONFIG DLL     3584   2-03-93  10:53a
 TOKEN    SYS    28176  11-17-93   1:22p
 NWSTART  EXE     8227  12-06-94   2:02p

Changing the name of LSL.SYS to NWLINK.SYS was done to avoid an install sniffer from determining that the Netware requester was already installed and no allowing me to re-install it. Changing the name of NETAPI.DLL to NWAPI.DLL was done because the install of the Peer product required functionally in the NETAPI.DLL that Novell's NETAPI.DLL did not provide, and the Peer product's install could not get to its own NETAPI.DLL when the Netware requester had its own NETAPI.DLL opened. Changing the name of this .DLL causes a rather nasty looking error message to appear when the Netware drivers are loaded on bootup, but the appropriate functions are apparently found in the renamed .DLL and everything has worked correctly in my testing.

I have put these files (minus token.sys and route.sys) in in /pub/os2/incoming/

proposed directory for placement: /pub/os2/network/netware

As of 25 July 1995, the file was still in the incoming directory.

Setting up the Netware server

To set up the Netware server, I xcopied the CD-ROM onto the server into the VOL:CONNECT directory then xcopied the grpware directory from the OS/2 code server. I also set up the requester drive letters so that they would point to the spots on the Netware server corresponding to the OS/2 code server and with equivalent rights. Check the grpware.ini file on the OS/2 code server to confirm. The virtual CD-ROM on the Netware server takes up about 260 meg. You could also install from an actual CD-ROM but there is a severe performance impact if you are doing multiple simultaneous installs off a CD-ROM.

Allowing the IBM Network Transport install logic to work when it cannot actually be allowed to have access to the LAN adapter

You might notice that adapter information set up in the config.sys segment above is for the IBM Parallel Port ANDIS driver, PRNANDI.OS2.


I did this so that SRVIFS and MPTS would set themselves up for the parallel port rather than the Token Ring card. This avoids device driver conflict during the install. After the install completes I remove the minimal Netware LT rivers from the root directory of the boot drive, run MPTS and 'change' the Parallel port driver out and replace it with the IBM Token Ring NDIS driver. I then tell ODI2NDI the MAC address of the Token Ring Card. This completes the install.

Avoiding conflicts between the minimal Netware setup used in the install procedure and the standard IBM SRVIFS setup.

The use of a Netware server as a code server presents a couple of more challenges. The Netware requester has its own NETAPI.DLL which is much smaller that IBM's NETAPI.DLL and provides less functionality. The CID install of the Peer Product requires functions of the IBM NETAPI.DLL which are not in the Netware Requester's NETAPI.DLL. The Netware requester can use the IBM NETAPI.DLL, but the IBM NETAPI.DLL will not fit onto the LT disk.

My fix for this is to rename the Netware NETAPI.DLL to NWAPI.DLL. NWIFS.IFS will put out a message that makes it look like it failed to load when the name of this .DLL has been changed, but it seems to work anyway.

The Connect Install has a sniffer that looks for LSL.SYS in your config.sys and may prevent you from installing the Netware 2.11 client if it finds it. Again my fix is to rename the file. I changed LSL.SYS to NWLINK.SYS and there wasn't even a peep when I loaded it.

Cleanup of files and config.sys lines--artifacts of the install using the minimal Netware requester

I use the USER.CMD function of the Connect install to clean up my config.sys and remove files. If there is a USER.CMD in the local \grpware\clients\ladclt directory (this directory structure is created, then removed by the Connect install process) it will be executed at the end of the install. I put the user.cmd I wrote in the root of the W: drive and use the following command in the LT config.sys to copy it to the correct directory:

call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*

note this will cause an error message when booting from diskette, but after the line has been migrated to the config.sys partition being installed it does its job.

below is a REXX code segment from my user.cmd file to clean up the mess I made of the config.sys. Note the file read/write logic is absent.

 ---------  begin REXX code segment ------
push stop
push '=\REFPART.SYS'
push '=NWLINK.SYS'
push '=TOKEN.SYS'
push 'SET CAS'
push 'SRVREXX'
push '=ROUTE.SYS'
push '=IPX.SYS'
push '=NWREQ.SYS'
push '=NWIFS.IFS'
push '=\NWSTART.EXE'
push '\OS2\LOGIN.EXE'
push '=\MAP.EXE Z:='
push '=\MAP.EXE W:='
push 'SRVNAME1='
push 'USER.CMD'

/* if find match for any of the above, read in the next line without
writing  the matched line to the new config.sys */

     do until test=stop
       parse pull test
       if rtn > 0 then
           end /* do */
     end /* do */

/* clean autorestart, libpath, dpath of lines migrated from LT Disk */
push stop
push ';Z:\CID\DLL\OS2'
push ';\;\OS2;\OS2\SYSTEM;\OS2\INSTALL'

  do until test=stop
     parse pull test
     if cnt > 0     then
      end /* do */
   end /* do until */

 --------- end of REXX Code segment ---

The install process migrates the minimal Netware requester files from the LT diskette to the root of the drive being installed. Removing the files is tricky because some of them are opened and locked by the Netware requester during all phases of the install process. And they must be removed otherwise your 2.11 requester will grab these ancient files, attempt to use them and fail on your next reboot.

In my user.cmd I deleted all the Netware files copied from the LT diskette that were not locked. Then I set up the IBM locked file device driver to remove those files a simple del statement could not remove. This device driver is run from the config.sys and executes before the Netware drivers are loaded. I used my user.cmd to insert the following two lines as the second and third lines of the config.sys:


then build the ibmlanlk.lst file with the following entries:


You need to make sure there is an End-Of-File character (x'1A') at the end of the IBMLANLK.LST file for the IBMLANLK.SYS to work.

This completed the cleanup.

Fix up protocol.ini and config.sys to use the NDIS drivers for LAN transport

This can be done either manually or with REXX. The manual process is:

a. Run the Netware command USERLIST /a to get the MAC address you network card. This will need to be done from your USER.CMD and piped into a file before the install completes.

b. run MPTS. Select Configure->LAN Adapters and Protocol. This will bring you to the "LAPS Configuration" screen which contains three windows, "Network Adapters", "Protocols", and "Current Configuration"

c. In the "Network Adapters" window hi-light the adapter on your PC.

d. In the "Current Configuration" make sure the "IBM Parallel Port..." selection is high-lited.

e. Under the "Network Adapters" window, select "Change" and then confirm the change.

f. In the "Current Configuration" window hi-light "0 - IBM Netware Requester Support" and select "Edit"

g. Enter the Network adapter address in the appropriate field.

If you are on Ethernet, turn off TOKEN-RING frame header support and turn on the appropriate Ethernet frame header support for your site.

h. Hit "OK" -> "OK" -> "Close"->"Exit"-> then "Update Config.sys" "Exit"

You can also do this with REXX.

For the config.sys, you only need to do one thing. You need to replace the parallel port ANDIS driver with the NDIS driver which corresponds to your card. I do this during the config.sys processing of my USER.CMD. You do need to know the names of the corresponding ODI and NDIS drivers for your NIC card.

 -------------- begin REXX code segment -------------

/* find ODI driver, set up variables for corresponding NDIS */
/* environmental variables used in protocol.ini update */
        if cnt > 0  then
           'set NIC=IBMTOK.OS2'
           'set NIF=IBMTOK_NIF'
           'set NIF_FILE=IBMTOK.NIF'
           'set driver=IBMTOK$'
           'set topology=TOKEN_RING'
          end /* do */
/* replace parallel port driver with NIC Driver */
 cnt=pos('PRNANDIS.OS2', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   end /* do */
 -------------- end REXX segment ----------------

Protocol.ini processing is similar. You replace all the references to
the parallel port driver and NIF files with those of your NIC driver.
You also need to get your MAC address, make sure it is 12 characters
in length and zero fill the leading characters, if it is not.

-------------- begin REXX code segment -------------
/* get MAC address from userlist.txt, Switch NDIS Drivers */
ProtocolProc: Procedure
/* output from userlist /a has been put in userlist.txt file */

Do until LINES(source) = 0 /* spin through file */

/* find line with this PC's MAC address */
if cnt > 0 then
end /* do */
end /* do */

/* zero fill leading spaces */
do until cnt=0
cnt=pos(' ',mac_addr)
if cnt > 0 then
end /* do */

-------------- end REXX segment ----------------

You are then ready to tackle the protocol.ini. Note that the PROTOCOL.INI file from a CID install is not quite the same as what you are use to seeing MPTS (or NTS/2) create. It is sort of a minimalist protocol.ini, without many of the standard entries in the protocol sections (for example).

 -------------- begin REXX code segment -------------

  /* NDIS values put in environment during config.sys proc */

( some file handling  code deleted )

Do until LINES(source) = 0   /* spin through file */

/* insert MAC address of NIC */
   if cnt > 0 then
        say sline
     end /* do */

/* replace LPT ANDIS driver with NDIS Driver */

 cnt=pos('PRNANDIS_NIF', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   end /* do */

 cnt=pos('PRNANDIS.NIF', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   end /* do */

 cnt=pos('PRNANDS$', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   end /* do */

    call lineout object, sline

/* If this is an Ethernet LAN, make sure frame header support is
appropriate */
   cnt=pos('= ODI2NDI$', sline)
  if cnt > 0 then
     call lineout object, '   ETHERNET_II = "yes"'

end /* do spin through file */

 -------------- end REXX segment ----------------


The simplest way to install Warp Connect from a Netware Server is to put the Warp Connect CD-ROM on the Netware Server (or copy it to on of the Netware server's volumes), then from an OS/2 Warp Workstation, map a (permanent) drive to the root of the CD image and run Install.cmd.

My own testing has been done mostly on a Token Ring network with IBM Token Ring cards, but I have also installed using this technique over Ethernet with a 3C509 card. And I have adapted this (only changing the name of the directory for the Z: mapping) for Warp Connect Without Windows--using diskettes created from the Without Windows CD.

Some of the re-install and additional install function that IBM delivers with the standard Warp Connect CID may not work given the Netware requester CID technique described here.

The minimal Netware requester files have been uploaded to in /pub/os2/incoming/ Proposed directory for placement: /pub/os2/network/netware

As of 25 July 1995, the file was still in the incoming directory.

By Matt Hickman

Return to The Warp Pharmacy:Software