RPL Support Setup Instructions

(Last modified: 27Apr1998)

This document (14933) is provided subject to the disclaimer at the end of this document.

Issue

In this document, "NetWare" refers to the NetWare operating systems 2.x, 3.x and 4.x. "PNW" refers to PERSONAL NetWare and the networking piece of Novell DOS 7. "ND7" refers to Novell DOS 7.

Because Remote Program Load (RPL) functionality is provided by NetWare, PNW will not supply this functionality if a NetWare server is detected on the network. You should reference your NetWare documentation for instructions on setting up RPL.

Further documentation for RPL with PNW can be found in chapter 12 of your PERSONAL NetWare manual or in the RPLDOC.TXT file on the last Novell DOS 7 install diskette, depending on which product you purchased.

THE LOGIN DIRECTORY

Though the NetWare servers provide a LOGIN directory by default, PNW server's do not. This directory needs to be created and shared by the network administrator on one of the PNW servers in the workgroup.

This special directory is the basis for connecting diskless workstations. It is used to load the boot disk image, network utilities, and software that could not be stored on the client itself.

CREATING THE LOGIN DIRECTORY

To create the LOGIN directory, you can use the MDLOGIN batch file listed at the end of this document, or you can do it manually.

To create the LOGIN directory manually:

1. Select what server will contain the LOGIN directory.

2. On that server, create a C:\LOGIN directory.

3. Share the DOS directory as a network directory "LOGIN".
    (for example, NET SHARE C:\LOGIN LOGIN)

After the directory is created and shared on the network, any client who loads the VLMs and has that workgroup as its preferred workgroup in the NET.CFG will have its first network drive automatically mapped to LOGIN. SERVER does NOT have to be unloaded and reloaded for the LOGIN directory to take effect.

Because the purpose of the LOGIN directory is to provide startup files to clients who don't have them locally, the programs and files necessary to running the NET utility should be included in the directory.

The files that should be copied to the LOGIN directory that are required to run NET are listed in the table below. If you ran the MDLOGIN.BAT file to create the LOGIN directory, these files would have been automatically copied over. If you manually created the LOGIN directory, copy the following files to that directory before continuing:

    File Where it can be found
    NET.EXE C:\NWCLIENT
    IBM_RUN.OVL C:\NWCLIENT
    NETU.OVL C:\NWCLIENT
    NETU2.OVL C:\NWCLIENT
    NETU.HLP C:\NWCLIENT
    NETC.MSG C:\NWCLIENT\NLS\ENGLISH

The following files are additional files needed for RPL support. They would NOT have been copied over automatically when you ran the MDLOGIN.BAT file. You should copy them from the C:\NWCLIENT\RPL directory to the LOGIN directory now. Only copy the files that you will need (see the "What it is for" column).

    File What it is for
    NEARSERV.EXE Responds to NEARSERV requests
    DOSGEN.EXE Generates a boot image file
    RPL.COM Provides RPL response
    RPLFIX.COM Fix for image file with DOS 5.X +
    RPLODI.COM Support for older boot PROMS

(The following files should be copied only if required:)
    RBOOT.RPL RPL code for Novell PROMS
    ETHER.RPL RPL code for IBM Ethernet PROMS
    TOKEN.RPL RPL code for IBM Token Ring PROMS
    PCN2L.RPL RPL code for IBM PCN2L PROMS

This completes the general preparation of the LOGIN directory. Next, you need to generate the boot files for each RPL client and make them accessible by copying them to the LOGIN directory.

CREATING A CLIENT BOOT DISKETTE

You can generate the client boot diskette by executing the MAKEDISK.BAT file listed at the end of this document. The batch file relies on the existence of the four .EG files also listed at the end of this document. MAKEDISK.BAT creates a basic boot diskette containing the necessary files to get started.

To manually create a client boot diskette to be used to generate a boot image file, do the following:

1. Format a diskette with the /s switch.

2. Create a CONFIG.SYS file on the diskette.
    (see CONFIG.EG)

3. Create an AUTOEXEC.BAT file on the diskette.
    (see AUTOEXEC.EG)

4. Create a STARTNET.BAT file on the diskette.
    (see STARTNET.EG)

5. Create a NET.CFG file on the diskette.
    (see NET.EG)

6. Copy the LSL.COM, MLID (for example, NE2000.COM), and IPXODI.COM drivers to the diskette.

7. Copy the necessary VLMs to the diskette.
        VLM.EXE
        AUTO.VLM
        CONN.VLM
        FIO.VLM
        GENERAL.VLM
        IPXNCP.VLM
        NMR.VLM
        NWP.VLM
        PNW.VLM
        PRINT.VLM
        REDIR.VLM
        TRAN.VLM

8. Copy any other drivers you will need.
    (for example, HIMEM.SYS)

You should test this diskette by placing it in drive A: of a machine on the network (other than the server with the LOGIN directory) and restarting the computer. This diskette should provide all the functionality for booting, attaching to a server, and logging in. The diskette must be functioning properly before you continue.

ENABLING THE SERVER TO RESPOND TO RPL CLIENTS

To enable the server to respond to RPL Client requests, you must do the following:

1. Verify that no NetWare servers (that is 2.x, 3.x, or 4.x) are on the network. They already provide RPL functionality. If the PNW server finds a NetWare server on the network, NEARSERV.EXE will not load and the PNW server will not respond to client RPL requests.

2. Verify that all nodes (servers and clients) are using the same frame type and that it is the frame type supported by your remote boot PROM. Older style Ethernet boot PROMs use Ethernet_802.3 or Ethernet_II frame types. Newer, "find frame" Ethernet boot PROMs use Ethernet_802.2, Ethernet_SNAP and Ethernet_II (not Ethernet_802.3). If you try to use the wrong frame type, you will not get a connection to the server. The frame type that a machine will use is set in the Link Driver section of the machine's NET.CFG file.

    NOTE: If you are unsure what boot PROM you have, contact the manufacturer.

3. Create a LOGIN directory with the RPL support files.
    (See "THE LOGIN DIRECTORY" instructions previously specified.)

4. Copy the necessary RPL files into the LOGIN directory.
    (See "THE LOGIN DIRECTORY" instructions previously specified.)

5. If you are using the new style boot PROMs, have the server load RPL.COM from the LOGIN directory after IPXODI.COM.

    (For example, LH RPL.COM BIND NE2000 GNS)

    NOTE: The RPL.COM must be configured to respond to Get Near Server (GNS) calls. If you created a BOOTCONF.SYS file (see the "ENABLING RPL FOR MULTIPLE CLIENTS" instructions that follow.), RPL will automatically respond to GNS. However, because everyone may not create a BOOTCONF.SYS file, Novell recommends putting the GNS parameter on the RPL load line as in the example.

6. Have the server load NEARSERV.EXE after SERVER.EXE.
    (For example, LH NEARSERV.EXE)

    NOTE: If NEARSERV.EXE detects a NetWare server on the network, it will not load. In that case, RPL support must be supplied by the NetWare server.

7. Reboot the server so the RPL.COM and NEARSERV.EXE file load.

You must make sure the NEARSERV.EXE file (and RPL.COM if using the new style boot PROMs) loads successfully before continuing.

ENABLING RPL FOR A SINGLE CLIENT

Before enabling RPL for multiple clients, you should verify that it functions correctly for a single client. Therefore, complete this section before continuing, even if you will be adding support for multiple RPL clients.

To enable RPL for a single client, do the following:

1. RPL support must be available at the server.
    (See the "ENABLING THE SERVER TO SUPPORT RPL CLIENTS" section previously specified.)

2. Make sure the boot prom is installed properly.
    (See the documentation that shipped with the PROM.)

3. Make sure the Network Interface Card (NIC) is configured properly so it doesn't conflict with any other hardware or drivers in the machine and so it will request RPL.
    (See the documentation that shipped with the NIC.)

4. Create a boot diskette, and verify that it works.
    (See "CREATING A CLIENT BOOT DISKETTE" section previously specified.)

5. Copy RPLODI.COM to the diskette, and add it to the AUTOEXEC.BAT (only if using old style Ethernet boot PROMS).

    NOTE: If you are unsure what boot PROM you have, contact the manufacturer.

6. DOSGEN the diskette to create NET$DOS.SYS in LOGIN.
    (For example, DOSGEN A:)

    NOTE: For the syntax for running DOSGEN, run DOSGEN /?.

7. Copy necessary boot files from the diskette to the LOGIN directory.
    (For example, AUTOEXEC.BAT, STARTNET.BAT)

    NOTE: After VLM.EXE loads during RPL, the boot image file is no longer available. Instead, the LOGIN directory is where the client is accessing files. For this reason, all files accessed after the VLM loads that are part of the boot process need to be in the LOGIN directory. Also, for this reason, the FIRST NETWORK DRIVE in the NET.CFG on the boot diskette should be set to "A."

8. RPLFIX the NET$DOS.SYS file if using MS DOS 5.X, 6.X or DR DOS 6.X.
    (For example, RPLFIX C:\LOGIN\NET$DOS.SYS)

    Note: With the introduction of DOS 5.0, the size of the transient portion of DOS changed. Part of that portion of DOS extended into the area where the RPL puts a generic version of IPX to provide connectivity to the server. That overlap caused the RPL machine to hang during the boot sequence. RPLFIX moves the generic IPX out of the way of DOS. Even though running RPLFIX is not always necessary, it never hurts. Novell recommends running it to prevent possible hanging problems.

Verify that the RPL client has no bootable media in the A: or C: drive and reboot it. It should connect to the server, find the NET$DOS.SYS file, and boot just as the other client booted when using the boot disk you created. To see the connection being made and the NET$DOS.SYS file be accessed, you can run NET CONSOLE on the server.

ENABLING RPL FOR MULTIPLE CLIENTS

This process involves the following steps:

1. Enabling RPL for a single client.

2. Creating a BOOTCONF.SYS file.

3. Creating a dummy AUTOEXEC.BAT.

4. Creating a separate boot disk image files for each client.

For detailed steps on enabling RPL support for multiple clients, see chapter 12 in the PERSONAL NetWare manual or the RPLDOC.TXT file located on the last of the Novell DOS 7 install diskettes, depending on which product you purchased.

COMMONLY SEEN PROBLEMS

Using a drive letter other than "A" as the FIRST NETWORK DRIVE in the NET.CFG:

    When the client accesses the boot image file, that image file looks just like an A: drive. When the VLMs load, the image file is no longer accessed; the LOGIN directory is accessed instead. Because that switch usually takes place in the middle of a batch file (such as, AUTOEXEC.BAT), that batch file must be accessible.

    To make the switch smoothly, make sure a copy of that batch file is in the LOGIN directory, and make sure that the LOGIN directory is pointed to by the A: drive when the switch occurs. This is done by setting the FIRST NETWORK DRIVE = A in the NetWare DOS Requester section of the NET.CFG on the boot disk, and making that disk an image file by using DOSGEN. If you find that you need to set the FIRST NETWORK DRIVE to something other than the "A:" drive, try adding a command to the STARTNET.BAT file, right after VLM loads, to change to the FIRST NETWORK DRIVE (For example, F:).

Incorrectly configuring the Network Interface Card:

    You must configure the network interface card according to the documentation that ships with that card. Usually, you must install the boot PROM, set the appropriate frame type, and set another jumper to inform the board that it will do RPL.

Not excluding the memory range used by the network interface card during RPL:

    Most cards use an upper memory range when doing RPL. Many NICs (especially IBM Token-Ring boards) use two upper memory addresses. A memory manager, such as EMM386.EXE, may try to use that same area(s).

Using the wrong frame type:

    Different PROM types use different frame types. For example, the old style Novell Ethernet boot PROM uses 802.3, where the new style "find frame" Ethernet boot PROM uses 802.2. All nodes must use the same frame type because PERSONAL NetWare does not provide routing capabilities between networks (although PNW does support routing packets across routers provided by other software or hardware).

Not running RPLFIX against the NET$DOS.SYS file created by DOSGEN:

    Versions of DOS later than MS DOS 5.0 may have increased the size of the transient portion of DOS. In that case, where the boot PROM tries to put its generic IPX and NETX code could be right on top of DOS causing the RPL machine to hang.

Not creating the LOGIN directory correctly:

    The LOGIN directory should be on one server in the workgroup that is up whenever a RPL client tries to boot. The LOGIN directory must be at C:\LOGIN and must be shared on the network. The network volume called LOGIN should point to the C:\LOGIN directory instead of the C:\ directory.

Not loading RPL with the ability to respond to a GetNearestServer (GNS) packet with the complete server information:

    If you do not provide this functionality, the client will get a response from the server, then try to use connection based information to attach. PERSONAL NetWare does not support that type of attachment. If you do provide GNS functionality to RPL.COM, the server will respond with its complete name and the client will connect properly. To enable GNS functionality in RPL.COM, specify GNS on the load line as documented in the attached draft or supply a BOOTCONF.SYS file.

Not loading RPL.COM and NEARSERV.EXE, and verifying that they loaded:

    It is easy to load these files and not watch the messages. These files may not bind or load for some reason (such as another NetWare server being detected, or the wrong frame type being specified). RPL is only needed when using the new style boot PROMs.

Insufficient memory errors when loading RPL.COM or NEARSERV.EXE:

    Many terminate and stay resident (TSR) programs expand themselves when loaded into memory. For example, a TSR called XX.COM may start out on disk being 10 KB; however, after it is loaded, it has allocated some memory, has terminated resident, and it may be 15 KB. If DOS loads the TSR into a memory area too small for it to be able to expand, it may return such an error. The most probable cause is that you are trying to load RPL.COM or NEARSERV.EXE high (into upper memory). There was probably enough memory to load it up there but not enough memory for it to expand. Try loading the driver low, or free up more upper memory by loading something else low.

Not connecting the network cabling after configuring the NIC:

    After adding the PROM to the RPL client's NIC and modifying the NIC configuration to support remote boot, you may forget to connect the cable.

    If the RPL client gets a message that a file server could not be found after it has loaded the VLMs, this indicates that the client is not finding a server with a LOGIN directory.

    This problem normally occurs if the PREFERRED WORKGROUP in the NET.CFG in the boot image file (generated from the boot diskette) is set to an incorrect or nonexistent workgroup. Correct that line in the NET.CFG file, and regenerate the boot diskette with DOSGEN. Don't forget to RPLFIX the new image file.

MDLOGIN.BAT

@echo off
cls
echo MDLOGIN.BAT
echo -----------
echo This batch file creates a Personal NetWare LOGIN
echo directory. After created, when a client loads the
echo VLMs, its first network drive will be mapped here
echo automatically. This batch file also copies the files
echo necessary for running the NET utility for DOS
echo into this LOGIN directory.
echo
echo This batch file makes the following assumptions:
echo - You are running it on the server where you want
echo LOGIN to reside.
echo - You are logged in as a user with
echo workgroup administrator rights.
echo - You have SERVER configured for enough directories
echo that you can add one.
echo - You have PNW installed on this machine's
echo C:\NWCLIENT directory.
echo - This machine currently does not have a
echo C:\LOGIN directory.
echo - This workgroup currently does not have a
echo LOGIN directory resource.
echo
echo To quit this batch file, press Ctrl+Break or
echo Ctrl+C now. Otherwise,
pause
cls

echo MDLOGIN.BAT
echo -----------
echo Creating C:\LOGIN directory.
md c:\login
echo

echo Copying NET.EXE.
copy c:\nwclient\ne?.exe c:\login
echo

echo Copying overlay files.
copy c:\nwclient\ibm_run?.ovl c:\login
copy c:\nwclient\net*.ovl c:\login
echo

echo Copying help files.
copy c:\nwclient\net*.hlp c:\login
echo

echo Copying English version of NETC.MSG.
copy c:\nwclient\nls\english\netc?.msg c:\login
echo

echo Creating LOGIN network directory.
net share c:\login login
echo

MAKEDISK.BAT

@echo off
echo MAKEDISK.BAT
echo ------------
echo This batch file creates a client diskette for
echo booting floppy-only machines to the network.
echo Before this diskette can be used, the LOGIN
echo directory must have been created (MDLOGIN).
echo
echo This batch file makes the following assumptions.
echo - The following files exist in the current directory:
echo CONFIG.EG, AUTOEXEC.EG, STARTNET.EG, and NET.EG
echo These are example files that correspond to the
echo following boot files:
echo CONFIG.SYS, AUTOEXEC.BAT, STARTNET.BAT, and NET.CFG
echo - The A: drive will be used to generate the floppy.
echo - There is a diskette in A: that can be reformatted.
echo - The C:\NWCLIENT directory contains the installed
echo PERSONAL NetWare drivers.
echo
echo To exit this batch file, press Ctrl+Break or
echo Ctrl+C now. Otherwise,
pause
cls

echo MAKEDISK.BAT
echo ------------
echo Formatting floppy disk.
format a: /s
echo

echo Copying CONFIG.SYS.
copy CONFIG.EG? a:\config.sys
echo

echo Copying AUTOEXEC.BAT.
copy AUTOEXEC.EG? a:\autoexec.bat
echo

echo Copying STARTNET.BAT.
copy STARTNET.EG? a:\startnet.bat
echo

echo Copying NET.CFG.
copy NET.EG? a:\net.cfg
echo

echo Copying ODI drivers.
copy c:\nwclient\ls?.com a:
copy c:\nwclient\ipxod?.com a:
echo

echo Copying VLM drivers.
copy c:\nwclient\vl?.exe a:
copy c:\nwclient\auto.?lm a:
copy c:\nwclient\conn.?lm a:
copy c:\nwclient\fio.?lm a:
copy c:\nwclient\general.?lm a:
copy c:\nwclient\ipxncp.?lm a:
copy c:\nwclient\nmr.?lm a:
copy c:\nwclient\nwp.?lm a:
copy c:\nwclient\pnw.?lm a:
copy c:\nwclient\print.?lm a:
copy c:\nwclient\redir.?lm a:
copy c:\nwclient\tran.?lm a:
echo
echo ****IMPORTANT***
echo The boot floppy is now created. Don't forget,
echo you MUST...
echo 1. Copy the correct MLID driver onto the
echo floppy diskette
echo
echo 2. Edit the NET.CFG file with the correct
echo MLID name, hardware settings, and workgroup.
echo
echo 3. Edit the STARTNET.BAT to load the MLID after LSL.

CONFIG.EG

FILES=50
BUFFERS=20
LASTDRIVE=Z

AUTOEXEC.EG

@echo off
CALL STARTNET.BAT
PATH A:\;F:
NET

STARTNET.EG

@echo off
LSL
rem The MLID driver (eg. NE2000.COM) should go here.
IPXODI
VLM

NET.EG

# Edit the Link Driver heading with the proper MLID title.
# For example, if you are loading the NE2000 driver,
# the heading should read:
# LINK DRIVER NE2000
#
# Also, edit the hardware settings appropriately.
#
# Enter the name of your workgroup on the preferred
# workgroup line.
#
# Remember, headings start in the left most column, and
# parameters under headings are spaced over with
# space(s) or tab(s).

Link Driver
    int
    port

NetWare DOS Requester
    first network drive = a
    message level = 2
    netware protocol = pnw
    preferred workgroup =
    signature level = 0
    vlm = auto.vlm
    vlm = nmr.vlm

document

Document Title: RPL Support Setup Instructions
Document ID: 14933
Creation Date: 09May1994
Modified Date: 27Apr1998
Revision: 3
Novell Product Class:NetWare

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.