Installing Warp Connect Using a Netware Server: Difference between revisions

From OS2World.Com Wiki
Jump to navigation Jump to search
Ak120 (talk | contribs)
Ak120 (talk | contribs)
mNo edit summary
Line 21: Line 21:
* [[#Allowing the IBM Network Transport install logic to work when it cannot actually be allowed to have access to the LAN adapter]]
* [[#Allowing the IBM Network Transport install logic to work when it cannot actually be allowed to have access to the LAN adapter]]
* [[#Avoiding conflicts between the  minimal Netware setup used in the install procedure and the standard IBM SRVIFS setup]]
* [[#Avoiding conflicts between the  minimal Netware setup used in the install procedure and the standard IBM SRVIFS setup]]
* [[#Cleanup of files and config.sys lines--artifacts of the install using the minimal Netware requester]]
* [[#Cleanup of files and config.sys lines - artefacts of the install using the minimal Netware requester]]
* [[#Fix up protocol.ini and config.sys to use the NDIS drivers for LAN transport]]
* [[#Fix up protocol.ini and config.sys to use the NDIS drivers for LAN transport]]
   
   
Line 30: Line 30:
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.
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.
<pre>
<pre>
        DEVICE = NWLINK.SYS
DEVICE = NWLINK.SYS
        DEVICE = token.SYS
DEVICE = token.SYS
        device = route.sys board=1
device = route.sys board=1
        DEVICE = IPX.SYS
DEVICE = IPX.SYS
        DEVICE = NWREQ.SYS
DEVICE = NWREQ.SYS
        IFS = NWIFS.IFS
IFS = NWIFS.IFS
        run = NWDAEMON.EXE
run = NWDAEMON.EXE
        pauseonerror=no
pauseonerror=no
        call=\nwstart.exe
call=\nwstart.exe
        call=l:\os2\login.exe /script nul fs1/os2inst
call=l:\os2\login.exe /script nul fs1/os2inst
        call=\map.exe z:=fs1/vol:connect
call=\map.exe z:=fs1/vol:connect
        call=\map.exe w:=fs1/vol:GRPWARE\CLIENTS\LADCLT
call=\map.exe w:=fs1/vol:GRPWARE\CLIENTS\LADCLT
        RUN=Z:\CID\LCU\SRVREXX.EXE
RUN=Z:\CID\LCU\SRVREXX.EXE
        call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
        device=\mouse.sys
device=\mouse.sys
        SET SAVECONNECT=1
SET SAVECONNECT=1
        SET OEMPROGRAM=\GRPWARE\LANSTART.EXE
SET OEMPROGRAM=\GRPWARE\LANSTART.EXE
        SET exitwhendone=1
SET exitwhendone=1
        SET ADAPTER_NIF=PRNANDIS.NIF
SET ADAPTER_NIF=PRNANDIS.NIF
        SET SRVNAME1=fs1
SET SRVNAME1=fs1
        SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1
SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1
</pre>
</pre>
Here is a directory listing of the files used in the minimal Netware requester for the LAN Transport diskette.
Here is a directory listing of the files used in the minimal Netware requester for the LAN Transport diskette.
<pre>
<pre>
    NETH    MSG    3029  5-02-89  8:15a
NETH    MSG    3029  5-02-89  8:15a
    NET      MSG    2997  5-25-90  8:47a
NET      MSG    2997  5-25-90  8:47a
    MAP      EXE    25527  7-18-91  11:08a
MAP      EXE    25527  7-18-91  11:08a
    IPXCALLS DLL    1348  5-21-92  4:27p
IPXCALLS DLL    1348  5-21-92  4:27p
    NETAPI  DLL    1328  5-28-92  4:33p -- change name to NWAPI.DLL
NETAPI  DLL    1328  5-28-92  4:33p -- change name to NWAPI.DLL
    DDAEMON  EXE    9085  9-04-92  12:13p
DDAEMON  EXE    9085  9-04-92  12:13p
    ROUTE    SYS    45440  11-10-92  10:40a
ROUTE    SYS    45440  11-10-92  10:40a
    LSL      SYS    20772  11-25-92  2:31p -- change name to nwlink.sys
LSL      SYS    20772  11-25-92  2:31p -- change name to nwlink.sys
    NWDAEMON EXE    40089  1-21-93  5:20p
NWDAEMON EXE    40089  1-21-93  5:20p
    NWCALLS  DLL  108704  1-27-93  6:27p
NWCALLS  DLL  108704  1-27-93  6:27p
    NWIFS    IFS    35684  1-30-93  9:44a
NWIFS    IFS    35684  1-30-93  9:44a
    IPX      SYS    9780  1-30-93  11:49a
IPX      SYS    9780  1-30-93  11:49a
    NWREQOS2 MSG    17902  2-02-93  5:58p
NWREQOS2 MSG    17902  2-02-93  5:58p
    NWREQ    SYS    30324  2-03-93  9:42a
NWREQ    SYS    30324  2-03-93  9:42a
    NWCONFIG DLL    3584  2-03-93  10:53a
NWCONFIG DLL    3584  2-03-93  10:53a
    TOKEN    SYS    28176  11-17-93  1:22p
TOKEN    SYS    28176  11-17-93  1:22p
    NWSTART  EXE    8227  12-06-94  2:02p
NWSTART  EXE    8227  12-06-94  2:02p
</pre>
</pre>
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.
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 ftp.cdrom.com in /pub/os2/incoming/ltnwreq.zip.
I have put these files (minus token.sys and route.sys) in ftp.cdrom.com in /pub/os2/incoming/ltnwreq.zip.
Line 96: Line 85:


==== Allowing the IBM Network Transport install logic to work when it cannot actually be allowed to have access to the LAN adapter ====
==== 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.
You might notice that adapter information set up in the config.sys segment above is for the IBM Parallel Port ANDIS driver, PRNANDI.OS2.
<pre>
<pre>
Line 102: Line 90:
         SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1
         SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1
</pre>
</pre>
I did this so that SRVIFS and MPTS would set themselves up for the
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.
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. ====
==== 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.
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
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
and may prevent you from installing the Netware 2.11 client if it finds it.
it failed to load when the name of this .DLL has been changed, but it seems to work anyway.
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.


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 ====
==== 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:
I use the USER.CMD function of the Connect install to clean up
call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
my config.sys and remove files. If there is a USER.CMD in the local
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.
\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:
 
 
<pre>
        call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
 
</pre>
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.
 


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.
<pre>
<pre>
  ---------  begin REXX code segment ------
  ---------  begin REXX code segment ------
Line 215: Line 164:


  --------- end of REXX Code segment ---
  --------- end of REXX Code segment ---
</pre>
</pre>
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.
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:
 
 
<pre>
      DEVICE=\OS2\INSTALL\IBMLANLK.SYS \OS2\INSTALL\IBMLANLK.LST
      RUN=\OS2\INSTALL\IBMLANLK.EXE \OS2\INSTALL\IBMLANLK.LST


</pre>
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:
DEVICE=\OS2\INSTALL\IBMLANLK.SYS \OS2\INSTALL\IBMLANLK.LST
RUN=\OS2\INSTALL\IBMLANLK.EXE \OS2\INSTALL\IBMLANLK.LST
then build the ibmlanlk.lst file with the following entries:
then build the ibmlanlk.lst file with the following entries:
<pre>
<pre>
        DEL \NWCONFIG.DLL
DEL \NWCONFIG.DLL
        DEL \NETH.MSG
DEL \NETH.MSG
        DEL \NET.MSG
DEL \NET.MSG
        DEL \IPXCALLS.DLL
DEL \IPXCALLS.DLL
        DEL \NWCALLS.DLL
DEL \NWCALLS.DLL
        DEL \NWAPI.DLL
DEL \NWAPI.DLL
        DEL \NWDAEMON.EXE
DEL \NWDAEMON.EXE
        DEL \NWREQOS2.MSG
DEL \NWREQOS2.MSG
 
</pre>
</pre>
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.
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.
Line 273: Line 203:
g. Enter the Network adapter address in the appropriate field.
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.
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"
h. Hit "OK" -> "OK" -> "Close"->"Exit"-> then "Update Config.sys"
Line 280: Line 210:
You can also do this with REXX.
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.
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.
You do need to know the names of the corresponding ODI and NDIS drivers for your NIC card.
<pre>
<pre>
  -------------- begin REXX code segment -------------
  -------------- begin REXX code segment -------------
Line 356: Line 285:
   sline=translate(sline)
   sline=translate(sline)


/* insert MAC adress of NIC */
/* insert MAC address of NIC */
   cnt=pos('NETADDRESS',sline)
   cnt=pos('NETADDRESS',sline)
   if cnt > 0 then
   if cnt > 0 then

Revision as of 16:06, 7 March 2018

Return to The Warp Pharmacy:Software

Last update: 6th November, 1995

Symptoms

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.

Hardware

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

Problem

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.

Procedure

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 = NWLINK.SYS
 DEVICE = token.SYS
 device = route.sys board=1
 DEVICE = IPX.SYS
 DEVICE = NWREQ.SYS
 IFS = NWIFS.IFS
 run = NWDAEMON.EXE
 pauseonerror=no
 call=\nwstart.exe
 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
 RUN=Z:\CID\LCU\SRVREXX.EXE
 call=\os2\cmd.exe /q /c copy w:\user.cmd \grpware\clients\ladclt\*
 device=\mouse.sys
 SET SAVECONNECT=1
 SET OEMPROGRAM=\GRPWARE\LANSTART.EXE
 SET exitwhendone=1
 SET ADAPTER_NIF=PRNANDIS.NIF
 SET SRVNAME1=fs1
 SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,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 ftp.cdrom.com in /pub/os2/incoming/ltnwreq.zip.

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.

        SET ADAPTER_NIF=PRNANDIS.NIF
        SET ADAPTER_INFO=PRNANDIS.NIF,PRNANDIS.OS2,1

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 '=NWDAEMON.EXE'
push '=\NWSTART.EXE'
push '\OS2\LOGIN.EXE'
push '=\MAP.EXE Z:='
push '=\MAP.EXE W:='
push 'ADAPTER_NIF='
push 'ADAPTER_INFO'
push 'SRVNAME1='
push 'USER.CMD'
push 'PAUSEONERROR=NO'

/* 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
       rtn=POS(test,sline)
       if rtn > 0 then
           do
             sline=LINEIN(source)
             oline=sline
             sline=translate(sline)
             linecnt=linecnt+1
             read='NO'
           end /* do */
     end /* do */


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

  do until test=stop
     parse pull test
     cnt=POS(test,sline)
     if cnt > 0     then
      do
        sline=delstr(sline,cnt,length(test))
      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:

DEVICE=\OS2\INSTALL\IBMLANLK.SYS \OS2\INSTALL\IBMLANLK.LST
RUN=\OS2\INSTALL\IBMLANLK.EXE \OS2\INSTALL\IBMLANLK.LST

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

 DEL \NWCONFIG.DLL
 DEL \NETH.MSG
 DEL \NET.MSG
 DEL \IPXCALLS.DLL
 DEL \NWCALLS.DLL
 DEL \NWAPI.DLL
 DEL \NWDAEMON.EXE
 DEL \NWREQOS2.MSG

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 */
       cnt=pos('TOKEN.SYS',sline)
        if cnt > 0  then
          do
           NIC='IBMTOK.OS2'
           '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
   do
      sline=overlay(NIC,sline,cnt,12)
   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 */
source="\userlist.txt"

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

/* find line with this PC's MAC address */
cnt=pos('*',sline)
if cnt > 0 then
do
mac_addr=substr(sline,41,12)
end /* do */
end /* do */

/* zero fill leading spaces */
do until cnt=0
cnt=pos(' ',mac_addr)
if cnt > 0 then
mac_addr=overlay('0',mac_addr,cnt)
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 */
driver = VALUE("DRIVER",,"OS2ENVIRONMENT")
NIF = VALUE("NIF",,"OS2ENVIRONMENT")
NIF_FILE = VALUE("NIF_FILE",,"OS2ENVIRONMENT")
NIC = VALUE("NIC",,"OS2ENVIRONMENT")
TOPOLOGY = VALUE("TOPOLOGY",,"OS2ENVIRONMENT")

( some file handling  code deleted )

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

/* insert MAC address of NIC */
   cnt=pos('NETADDRESS',sline)
   if cnt > 0 then
     do
        cnt=pos('"',sline)
        cnt=cnt+1
        say sline
        sline=overlay(mac_addr,sline,cnt,12)
     end /* do */

/* replace LPT ANDIS driver with NDIS Driver */

 cnt=pos('PRNANDIS_NIF', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   do
      sline=delstr(sline,cnt,12)
      sline=insert(NIF,sline,cnt-1)
   end /* do */

 cnt=pos('PRNANDIS.NIF', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   do
      sline=delstr(sline,cnt,12)
      sline=insert(NIF_FILE,sline,cnt-1)
   end /* do */

 cnt=pos('PRNANDS$', sline)
 if cnt > 0 then
 if NIC <> 'unknown' then
   do
      sline=delstr(sline,cnt,8)
      sline=insert(DRIVER,sline,cnt-1)
   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
  if TOPOLOGY='ETHERNET'  then
     call lineout object, '   ETHERNET_II = "yes"'

end /* do spin through file */

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

Notes

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 ftp.cdrom.com in /pub/os2/incoming/ltnwreq.zip. 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