#
Upgrading and Repairing Networks

# - 11 -

# Network Client Software

The goal of network client configuration is to enable the client to use the network with the optimal balance of high performance and low memory use. When you factor in your time constraints, finding that balance can be something of an art form.

This chapter looks at network software configuration for clients. It examines the software components and how to install them, and it covers network and memory configuration issues. It gives you the information you need to get a reasonably well-configured client up and running in a reasonably short time and to fine-tune that client to meet your particular requirements.

## Workstation Software Configuration

This part of the chapter deals with the nuts and bolts of client configuration. It describes how to install and configure the various software components, and it takes a detailed look at the numerous configuration parameters.

The broad idea behind client configuration is to allow your client workstation to transmit and receive packets of a particular type (or types) on your network. Before you begin, you need to know which Ethernet frame type the server uses and which protocol or protocols your client is going to use.

### Client Network Software Components

There are two major elements to network client software. First, there is the network driver, the software that controls the network adapter. Then there is either a shell or redirector to translate all the network traffic into something meaningful to the OS.

The form taken by both of these components has changed considerably over the last few years. Broadly speaking, DOS workstations have seen three types of configurations:

- Monolithic IPX driver and NetWare shell (IPX.COM and NETX)
- ODI driver and NetWare shell (MLID and NETX)
- ODI driver and NetWare requester (MLID and VLM)

The next few sections look at the various components.

Monolithic IPX Driver: IPX.COM. The original NetWare network drivers were monolithic, dedicated IPX drivers. A single executable file contained all the software needed to control the network adapter, along with the hardware configuration information for the adapter. Adapter manufacturers distributed their NetWare drivers as an object file, which then was linked to NetWare code to produce an executable file with the adapter configuration embedded in it. If one of the adapter parameters was changed, the driver had to be rebuilt. These drivers supported IPX only--no other protocol could be used while they were loaded and in control of the network adapter.

Such drivers are obsolete and therefore are discussed no further in this chapter.

> CAUTION: Dedicated IPX drivers are obsolete! If your workstation currently uses such a driver, refer to "Upgrading Client Software" later in this chapter, for more information.

How do you tell if the network driver on a workstation is a dedicated IPX driver or not? Dedicated IPX drivers generally are named IPX.COM; however, the name may have been changed to indicate the type of adapter the driver supports. You may not be able to tell from the time stamp on the file, either. Although Novell has not certified monolithic drivers for network adapters since 1990, the COM file might have been linked since then. The best way to tell if a network driver is a dedicated IPX driver or not is by trying to load it without the Link Support Layer (see the following section)--if it complains about the LSL not being loaded, then it is an ODI driver rather than an IPX driver.

ODI Driver: MLID. Novell developed the Open Datalink Interface (ODI) specification with Apple in 1989. A network driver that complies with this specification is known as a Multiple Link Interface Driver (MLID). The strength of the ODI concept lies in its modularization of network functions. There are at least three components in the adapter driver software end of an ODI client:

- ODI Driver (MLID)
- Link Support Layer (LSL)
- One or more protocol-specific drivers (for example, IPXODI)

These work together according to the instructions in the configuration file NET.CFG to provide network connectivity to the OS. The following sections look at each component in turn.

Multiple Link Interface Driver (MLID). The MLID handles all communications between the physical network adapter and the other network components. Each adapter model needs its own MLID; these are written and distributed by the adapter manufacturers. The MLID is the only software component that deals directly with the adapter. If you replace an adapter with a different model, just swap in the MLID for the new adapter and update the NET.CFG file.

Link Support Layer (LSL). The Link Support Layer (LSL) communicates between the MLID and the various protocol drivers (such as IPXODI) as described later. The LSL may seem like an extraneous layer. Why not have the protocol drivers talk directly to the MLID? The answer lies in the benefits of modularizing the network functions. Consider the complexity of an ODI workstation. It may have several network adapters, each using multiple protocols. Network traffic must be routed between each adapter and the protocol-specific software that uses it. It would be quite difficult for a number of MLIDs in memory to coordinate their traffic-passing with each other. Even a single MLID for a single adapter would have difficulty keeping the various protocols separate, passing each type of traffic on to the correct driver.

The LSL lies between the MLID and the protocol drivers in logical--or even purely chronological--terms. It passes data from the MLID to the protocol drivers, and vice versa. It must, however, be loaded before the MLID. This is because the MLID needs to have the LSL to communicate with as soon as the MLID loads and also because there might be many MLIDs but only one LSL. It is easier to get each MLID to register with the LSL as it loads than to try to get the LSL to figure out which MLIDs are present when the LSL loads.

IPXODI and Others. MLID and LSL can look after the delivery of data from the adapter to the protocol drivers and vice versa. The purpose of the drivers is to interpret incoming data and to package outgoing data, according to the protocol that they support. IPXODI, for example, looks after incoming IPX packets, unpacks them and passes them on to the shell or redirector. Likewise, it accepts data from the shell or redirector for packaging as IPX packets and then passes them on through the LSL to the MLID for processing by the adapter.

This is where the versatility of the ODI scheme is most apparent. If your workstation needs only IPX support, just load IPXODI. If you want to add TCP/IP support, load TCPIP.EXE or some similar driver. Provided you keep the NET.CFG file in order, the workstation then handles both protocols.

NetWare Shell: NETX. The NetWare shell, NETX.EXE, adds network functionality to the workstation environment by intercepting calls made to DOS and handling some of them itself.

> NOTE: Early versions of the NetWare shell were DOS version-specific. NET3.COM worked with DOS 3, NET4.COM worked with DOS 4, and so on. More recent versions work with any DOS version and are named NETX.EXE. Notice that it has become an EXE file rather than a COM file--if you have NETX.COM, it's obsolete.

NETX is loaded into the workstation's memory when the workstation makes its initial connection to a file server. From then on, it watches a number of DOS interrupts. If an interrupt request can be handled by the OS, NETX simply passes it on to DOS.

If an interrupt call was made that requires action by NetWare rather than by the OS--for example, a reference to a network drive--NETX handles the interrupt itself. It puts together an IPX request and passes it on to the network via the network adapter and its associated software. Figure 11.1 illustrates the relationship between DOS, NETX, and the other network components.

Figure 11.1
NETX intercepts DOS calls and redirects them to network resources.

NetWare Requester: VLM. The NetWare requester, VLM.EXE, also adds network functionality to the workstation environment; however, it does so quite differently than the NetWare shell does. The requester incorporates a redirector that relies on DOS's redirection capabilities. If DOS receives an interrupt request relating to a network service, such as access to a network drive, it passes the request on to the requester. The redirector then handles the request in much the same way as the shell would--it makes an IPX request and transmits it to the network. Figure 11.2 illustrates the relationship between DOS, VLM, and the other network components.

Figure 11.2
The VLM requester takes advantage of DOS's ability to redirect interrupt requests.

The requester has a modular architecture. Virtual Loadable Modules (VLMs) are loaded by the VLM.EXE as required. Modules that are not needed do not need to be loaded. Individual modules may be replaced or reconfigured without affecting other modules. The requester uses advanced memory management techniques to make optimal use of client memory.

Table 11.1 lists the available VLMs. Notice that some VLMs are required and others are optional. If you are unsure whether a VLM is required, you can load it anyway--it won't clash with another VLM. Be aware, though, that there is a memory cost for each VLM loaded. A better approach is to omit the VLM and see if you can get by without it. If you get error messages, you can always include the required VLM later.

#### Table 11.1 Virtual Loadable Modules

File | Manages | Required
AUTO.VLM | Auto reconnection and auto retry | No
BIND.VLM | NetWare protocol (Bindery) | Bindery mode only
CONN.VLM | Connection table | Yes
FIO.NLM | File input/output | Yes
GENERAL.VLM | Support functions for NETX and REDIR | Yes
IPXNCP.VLM | IPX communications | Yes
MIB2IF.VLM | MIB-II interface | No
MIB2PROT.VLM | MIB-II TCP/IP support | No
NDS.VLM | NetWare protocol (NDS) | NDS mode only
NETX.VLM | NetWare shell emulation | No
NMR.VLM | NetWare management responder | No
NWP.VLM | Multiplexor for NetWare protocols | Yes
PNW.VLM | NetWare protocol (Personal NetWare) | PNW mode only
PRINT.VLM | Printer redirection | No
REDIR.VLM | DOS redirector | Yes
RSA.VLM | Encryption for Directory Services | No
SECURITY.VLM | NetWare security | No
TRAN.VLM | Multiplexor for transport protocols | Yes
WSASN1.VLM | SNMP ASN translation | No
WSREG.VLM | MIB network management | No
WSSNMP.VLM | SNMP network management | No
WSTRAP.VLM | SNMP traps | No

Shell versus Requester. There are a number of differences between the shell and the requester, in terms of both architecture and the user's point-of-view:

- Modularity
- Memory management
- Relationship with DOS
- Last DOS drive
- First network drive
- Global mappings
- File handles

The next few sections explore these differences.

Modularity. The requester consists of a number of VLMs and the VLM manager, VLM.EXE. VLM.EXE takes care of loading the VLMs into the workstation's memory, as well as managing memory allocation from various sources to the VLMs. This modular approach differs from the monolithic NETX.EXE, which consists of a single file with a single memory allocation. NETX takes up one large chunk of memory rather than several small chunks. NETX also encapsulates all network functionality in a single file. The VLMs, in contrast, modularize network functionality so that unneeded components need not be loaded.

Memory Management. VLM.EXE looks after memory allocation for the VLMs. It is capable of using conventional, extended (XMS), and expanded (EMS) memory. Unless instructed otherwise, it loads individual VLMs into memory in the following order of preference:

  1. XMS memory if available
  2. EMS memory if available
  3. Conventional memory

Therefore, the first few VLMs can be loaded into XMS while others are loaded into EMS or conventional memory. Using XMS rather than conventional memory has a performance cost, however--XMS is slower to access than conventional memory.

Relationship with DOS. When the shell is in use, it gets first call on requests. It decides which requests are network-related and which are not; any non-network requests are passed to DOS. When the requester is in use, though, DOS gets first call. DOS decides which requests are network-related and which are not; network requests are passed to the VLMs. This architectural difference has several implications, as explained in the following sections.

Last DOS Drive. The NetWare shell creates drive mappings using only drive letters that are not in use by DOS. If DOS uses drives A through E (the default), then the first network drive is drive F, and drives F through Z are available for mapping by the shell. If a DOS request comes through for drive M, it is handled by the shell. If a request comes along for drive C, the shell passes it along for DOS to deal with. The requester doesn't work that way--remember that it only has to handle requests that DOS decides are network requests. If DOS is using drives A through E, and a request comes along that refers to drive M, DOS returns an `Invalid drive` error, and the requester never sees the request.

It is necessary when using the requester to tell DOS to use more drive letters than the default five (A-E). It usually is best to make all drive letters available by setting the last DOS drive to Z. This is done by using the command

    LASTDRIVE=Z

in the workstation's CONFIG.SYS file.

Once this has been done, requests involving network drives are handled differently. If a DOS request comes through for drive M, DOS recognizes the drive letter as valid but also recognizes that VLM.EXE has taken over the operation of drive M. It therefore passes the request on to the requester for handling. Requests for local drives such as drive C are handled in the normal way, without the involvement of the requester: DOS recognizes the drive, knows that the drive is DOS's responsibility, and therefore handles the request itself.

First Network Drive: Specifying. The shell and requester both map the first network drive to the server's logon area when the initial connection is established. Using NETX, the first network drive is the next drive after the local drives or DOS drives. Assuming that the workstation uses the DOS default of five available drives (A-E), the first network drive is drive F. This is true even if some of the DOS drive letters are unused. If there is no hard disk, for example, and only drives A and B are in use, the first network drive still is drive F.

As explained in the preceding section, DOS and the requester share a range of drive letters. DOS examines each request and either deals with the request itself (if for a local drive) or passes the request on to the requester (if for a network drive). The mechanism used by NETX to decide on the first network drive--the first one after the DOS range--therefore does not work. Instead, VLM uses the first available DOS drive letter for the first network drive. If a workstation has no hard disk, for example, and uses only drives A and B, the first network drive is drive C; if the workstation has a hard disk drive (C) and a CD-ROM drive (D), the first network drive is drive E.

You can force VLM to use a particular letter as its first network drive by using the `First Network Drive` parameter in NET.CFG. See the "NET.CFG Parameters" section, later in this chapter, for details.

First Network Drive: Root Mapping or Not. The DOS prompt looks different when you switch to the first network drive, depending on whether you use NETX or VLM. Suppose that the first network drive in each case is drive F. Under NETX, the mapping is not a fake root--the DOS prompt reads `F:\LOGIN>`. You cannot switch to the root directory, `F:\`, until you log on. That does not matter to NETX--it happily intercepts all requests that refer to drive F and makes sure that you do not get to `F:\`.

This is not true of DOS because DOS cannot maintain a subdirectory when the parent directory is inaccessible. As soon as VLM attaches to the file server, it creates a root mapping to the logon area; therefore, the DOS prompt reads `F:\>`.

Global Mappings. Drive mappings in Windows DOS sessions using NETX are private by default. Under VLM, such mappings are global. This means that if you have multiple DOS sessions running, and you change a drive mapping in one session, the drive is also remapped in the other sessions.

File Handles. NETX regards network files as its own. It allocates handles for these files when it loads, either using the default value of 40 or a different number if there is a `File Handles=` entry in NET.CFG. Local files are DOS's business and have nothing to do with NETX, so DOS maintains file handles for local files. The number of file handles used by DOS can be set in CONFIG.SYS using the `FILES=` statement. Using VLMs, all file handles are managed by DOS. The total number of network and local file handles is set in the CONFIG.SYS file using the `FILES=` statement. You might need a larger `FILES=` setting in CONFIG.SYS when using VLMs.

Installing NetWare Clients. The installation procedure for the NetWare clients for DOS and Windows has been greatly simplified over the years. The original monolithic adapter driver had to be generated from its component parts into an executable file (IPX.COM) with the adapter's hardware settings hard-coded into the driver. To change a setting, the entire driver had to be recompiled. Once this was done, however, the simple loading of two TSRs from the workstation's AUTOEXEC.BAT was the only remaining procedure. The advent of the ODI architecture eliminated the need for driver generation and eased the process of configuring the adapter's hardware settings. It also simplified the procedure for using multiple network protocols on a workstation. However, as a result, the number of executables required increased from two to four.

The VLM client plus the adoption of Microsoft Windows as the standard business workstation environment increased the complexity of the NetWare client beyond the point at which it could be conveniently installed manually. Finally, an installation program was created for the VLM client that automates the procedure. If you are installing network support to a workstation for the first time, the use of the automated installation program is highly recommended.

Installing the VLM Client. The NetWare VLM client installation files ship with the NetWare 4.x operating system. It is installed by default to the \PUBLIC\CLIENT\ DOSWIN directory during the normal NetWare server installation process. The kit is also available for download from Novell's NetWire service on CompuServe.

> NOTE: The NetWare VLM Client Installation Kit is available from CompuServe (GO NWCLIENT) as six files called VLMKT1.EXE through VLMKT6.EXE. VLMKT6, however, contains only support for TCP/IP. If you will not be running Novell's TCP/IP, you do not need to download this file. Note that the full VLM kit contains all of the modules needed to support NetWare in all its available languages. The client upgrade archives mentioned elsewhere in this chapter, such as WINDR3.EXE, support U.S. English only.

You don't need a complete client installation to establish basic network connectivity. In the case of most corporate networks, an administrator uses a boot disk containing the basic files needed: LSL.COM, and MLID, IPXODI.COM, and NETX.EXE to connect to the network, from which she runs the full client installation.

If you have downloaded the Client Installation Kit from an online service, copy all the self-extracting files to a single empty directory and execute each one in turn. After you agree to the Novell terms and conditions, the files are decompressed and a directory structure is created. Certain files, such as NWUNPACK.EXE and LICENSE.TXT, exist in all of the archives. You can safely overwrite these files, as they are not required for the client installation.

Once you have extracted the archives, run the INSTALL.EXE program from the directory you have created. The VLM client installation program then performs the following tasks:

- Copies all necessary files to the workstation.
- Optionally installs Windows support.
- Optionally installs NetWare SBACKUP agent.
- Installs an MLID of the user's selection.
- Inserts user-specified adapter hardware settings into a NET.CFG file.
- Creates a STARTNET.BAT file that loads the client software.
- Modifies CONFIG.SYS, AUTOEXEC.BAT, WIN.INI, and SYSTEM.INI files.

After you have completed the installation process, you may want to make additional adjustments to the NET.CFG file using the settings explained in "NET.CFG Parameters," later in this chapter. You should, however, be able to reboot your system and connect to the network.

Installing the NETX Client. There is no dedicated installation program for the NETX client. If you have reason to perform an installation of the NETX client on a new computer with no networking support, you should still utilize the VLM Installation Kit to install the client, and then substitute NETX.EXE (or XMSNETX.EXE or EMSNETX.EXE) for VLM.EXE in the STARTNET.BAT file. This way, you have a complete set of client files that have been tested and are known to work together. If you are familiar with the structure of the NET.CFG file and you will not be running Windows on the computer, then you may find it simpler just to copy LSL.COM, and MLID, IPXODI.COM and NETX.EXE to a workstation drive and load them from the AUTOEXEC.BAT file--once you have created a NET.CFG containing the appropriate hardware settings. Most NetWare client workstations today are used to run Windows, however, and while you can install the client's Windows support manually (see "Manually Upgrading Windows Network Components," later in this chapter), it is far simpler to use the installation program.

## Upgrading Client Software

Every network client machine requires a software upgrade sooner or later. The upgrade may be prompted by a hardware or operating system change, the need to replace buggy or inefficient software, or the desire to take advantage of the enhanced functionality of newer software.

This section describes why, when, and how to upgrade the client network software components. It tells you which files you should have and what you are missing in each case by not upgrading. It also explains how to replace existing software as smoothly as possible. It points out the changes you can expect and shows how to avoid losing functionality--including the ability to use the network--by taking appropriate precautionary steps.

> NOTE: This chapter is focused on the upgrade procedures per se rather than on the particular software components. It may tell you, for example, that you should upgrade from IPX.COM to an ODI driver without giving a full explanation of what an ODI driver is.

Upgrading Guidelines. You want client upgrades to be successful and worth the effort. An upgrade that adds nothing to the client is a waste of time; if the client loses functionality as a result of your efforts, you will have to restore it to its previous state. The following precautionary steps can help you to ensure a successful upgrade and to backtrack gracefully in the event of a disaster.

Backups. Few experiences in network configuration can match the feeling you get when an upgrade kills the client so that it can no longer connect to the network. This is especially true if you skipped the step of backing up all network related files before carrying out the upgrade.

> CAUTION: It is generally advisable to have a full backup of all hard disks in the system before carrying out any software upgrades--network or otherwise. Before you dismiss this as excessively cautious, consider the implications for yourself and for the users of the workstation if data is lost on the hard disk. If you are about to upgrade a workstation that is maintained by someone else, ask him first if the backups for the machine are in a satisfactory state. If not, you should warn him that there is a risk of data loss during the upgrade.

Make a backup copy of all network files on floppy disk or copy them to another directory or extension (such as *.OLD) before carrying out an upgrade that might replace any of them. Use the following checklist as a guideline:

- AUTOEXEC.BAT
- CONFIG.SYS
- IPX.COM or MLID
- LSL.COM and IPXODI.COM (if ODI is in use)
- SHELL.CFG or NET.CFG (if present)
- NETX.EXE or NETX.COM (if shell is in use)
- VLM.EXE (if requester is in use)
- WIN.INI (\WINDOWS directory)
- SYSTEM.INI (\WINDOWS directory)
- NETWARE.DRV (\WINDOWS directory)
- NWUSER.EXE (\WINDOWS directory)
- NETAPI.DLL (\WINDOWS directory)
- NWCALLS.DLL (\WINDOWS directory)
- NWIPXSPX.DLL (\WINDOWS\SYSTEM directory)
- NWLOCALE.DLL (\WINDOWS\SYSTEM directory)
- NWNET.DLL (\WINDOWS\SYSTEM directory)
- NWNETAPI.DLL (\WINDOWS\SYSTEM directory)
- NWPOPUP.EXE (\WINDOWS\SYSTEM directory)
- NWPSERV.DLL (\WINDOWS\SYSTEM directory)
- NWPSRV.DLL (\WINDOWS\SYSTEM directory)
- VIPX.386 (\WINDOWS\SYSTEM directory)
- VNETWARE.386 (\WINDOWS\SYSTEM directory)
- VPICDA.DLL (\WINDOWS\SYSTEM directory)
- NWGDI.DLL (\WINDOWS\SYSTEM directory, if requester is in use)

Remember to check in subdirectories for these files. There may be older versions of the files in one directory and more recent versions in another. This is bad practice but it does happen, and it can mean that you accidentally back up the wrong files. Check AUTOEXEC.BAT to see where the files are loaded from.

Look for different versions of the Windows network files in both the \WINDOWS and \WINDOWS\SYSTEM subdirectories. If you find any, make backups of both for simplicity. Copy them to separate subdirectories on the backup floppy. You can experiment with deleting older versions and moving newer versions to the correct location after the successful completion of the upgrade.

Bootable Disk. Make sure you have a bootable floppy disk before starting the upgrade process. Check that it works on the specific client machine that you are configuring and that the hard disk is accessible after booting from it. Ideally, use a floppy boot disk formatted using the same DOS version as the one installed on the PC. Using a floppy boot disk with the same DOS version means you can use the external DOS commands stored in the PC's DOS directory after booting from the floppy.

Copy your favorite utilities to the floppy boot disk so they will be ready when you need them. Include a text editor for working on the PC's configuration files.

Remove Stray Copies of Files. There may be old versions of the network files lying around in directories other than the one from which the current files are loaded. Search for any such files and remove them from the hard disk before starting the upgrade. This helps to avoid confusion at a later stage, when it might not be clear which copy of a particular program should be loaded. It is best to keep copies of these files on a special backup floppy disk for reference purposes and as a safety precaution.

Checking Current File Versions. You may need to establish the current version number and revision level of a particular file before you can decide whether to replace it with another. There are a number of ways to do this. A simple comparison of file dates is often sufficient. If one copy of LSL.COM is from 1992 and another from 1994, install the 1994 version. Sometimes the date stamp is misleading though; for example, it may be the date on which the file was downloaded from an online service.

In many cases, running the program with the `/?` command line option gives quite detailed version information. Compare the first line in the `/?` output from two copies of LSL.COM:

    NetWare Link Support Layer v2.05 (930910)
    NetWare Link Support Layer v2.14 (941011)

The version numbers tell you that the second file is the more recent. The date stamp in parentheses at the end of the line tells you how much more recent: the first was released on September 10, 1993, and the second on October 11, 1994.

In some cases, you can't trust even this information. MLIDs are particularly prone to mislabeling, as hardware manufacturers can be sloppy about software version numbering. For example, two early versions of ODIDEPCA.COM reported the same version number: `Digital Equipment Corp DEPCA DOSODI driver V1.0 (920515)` `Digital Equipment Corp DEPCA MLID V1.00 (930122)` Yet the second is eight months more recent than the first and is considerably more reliable.

In summary, compare file date stamps and the version numbers reported by the programs themselves, but don't rely completely on this information. The only way you can be certain you have the most recent version of a file is to contact the supplier, as explained in the next section.

Sourcing the New Files. The most recent versions of the NetWare files--LSL.COM, IPXODI.COM, NETX.EXE, VLM.EXE, and the Windows files--can be found in Novell's NETWIRE forum on CompuServe and in various Internet mirrors. If you don't have access to the Internet or to CompuServe, your NetWare dealer should be able to provide these files to you.

> NOTE: All the NetWare client update archives can be downloaded from the NWOSFILES forum on CompuServe.

Novell packages the files into a number of self-extracting archives, each of which contains a set of related files. The latest VLM files at the time of writing, for example, are distributed in a file called VLMUP4.EXE. Unpack the archive into a new, empty directory to avoid mixing up its contents with any older files. Use the following commands to do so:

    C:\> cd tmp
    C:\TMP> md vlmup4
    C:\TMP> cd vlmup4
    C:\TMP\VLMUP4> c:\imports\vlmup4

The contents are unpacked from the archive file into the current directory. Any subdirectories contained in the archive file are automatically re-created in this directory.

The easiest place to find an MLID for your network adapter is on the adapter configuration disk supplied with the adapter. The place to find the most recent one is usually on the adapter manufacturer's World Wide Web or FTP server or in their CompuServe forum.

### Upgrading Specific Files

The following pages look at the various client network software components in turn. Topics covered include reasons for upgrading, upgrade instructions, and the benefits of particular upgrades.

Obsolete Files. IPX.COM and NETX.COM should simply not be used anymore.

IPX.COM. Novell stopped certifying dedicated IPX drivers years ago. If any of your workstations still use one, it's time to get rid of it. Replace IPX.COM (or whatever the dedicated IPX driver is called on your workstation) with a recent version of the Multiple Link Interface Driver (MLID) for your network adapter. Refer to the following "ODI Files" section for details.

Upgrading from a dedicated IPX driver to an MLID provides the client with a more robust and flexible interface. Above all, it gives the client the ability to run multiple network protocols simultaneously.

NETX.COM. The NetWare shell was originally DOS version specific, with NET3.COM written for DOS 3 and NET4.COM written for DOS 4. These were replaced with a single shell that worked on all DOS versions: NETX.COM. This was replaced in turn by NETX.EXE. If NET3.COM, NET4.COM, or NETX.COM is in use on the workstation, replace it with the most recent version of NETX.EXE (see the "NETX.EXE" section later in this chapter). Alternatively, migrate to the NetWare DOS requester, as discussed in the "Migrating from NETX to VLM" section later in this chapter.

ODI Files. The modular architecture of ODI means there are at least three network programs to upgrade on a NetWare client. These are the Link Support Layer driver (LSL), the IPX driver (IPXODI), and the MLID for the workstation's network adapter.

LSL.COM. The functionality of LSL is clearly defined in the ODI specification. Newer versions offer bug fixes or efficiency improvement over older versions without any change in core functionality. In other words, upgrading LSL.COM won't break anything but it may fix a problem or avoid a potential problem, so always use the most recent version! At time of writing, the most recent LSL.COM available on NetWire is v2.14, released on April 17, 1995. Check the current revision of your copy of LSL.COM by using LSL's `/?` switch:

    C:\> LSL /?
    NetWare Link Support Layer v2.16 (950417)
    (C) Copyright 1990-1995 Novell, Inc. All Rights Reserved.

Upgrading from an old version is a snap--just replace the old version with the new one. Installing ODI drivers from scratch--for example, when upgrading from IPX.COM to ODI--is more complex.

IPXODI.COM. Like LSL, IPXODI has a clearly defined role in the ODI scheme and is a stable entity as a result. It cannot change dramatically between releases; to do so would disrupt a huge number of client machines around the world. New releases generally offer bug fixes. Check the version of your current copy of IPXODI.COM using IPXODI's `/?` switch:

    C:\> IPXODI /?
    NetWare IPX/SPX Protocol with Mobile Support v3.02 (950808)
    (C) Copyright 1990-1995 Novell, Inc.  All Rights Reserved.

The current version of IPXODI.COM at time of writing is v3.02, released on August 8, 1995.

Just as for LSL.COM, you can replace an old version of IPXODI.COM with a newer version by simply replacing it. Always use the most recent version you can find--as a minimum, you will avoid potential problems that may be inherent in the older version.

MLID. LSL.COM and IPXODI.COM are universal in application, in the sense that they are designed to run on any PC with any network adapter. They are tested exhaustively before being released, and the introduction of new problems in an upgrade of either file is very unlikely. This is not the case with the ODI driver or MLID for a given network adapter. These programs are written by the adapter manufacturer, working to the ODI specification. MLIDs are occasionally released with serious bugs that have escaped the manufacturer's testing procedures. This is particularly true of initial releases of drivers; if you are having strange network problems while using version 1.00 of the ODI driver for a particular adapter, an upgrade is a good idea.

You can generally establish the current revision number and release date of an MLID using the `/?` command-line option. Here's an example from the 3Com Etherlink II MLID:

    3Com 3C503 EtherLink II MLID  v1.30 (930203)
    (C) Copyright 1992 3Com Corporation.  All Rights Reserved.
    (C) Copyright 1991 Novell, Inc.  All Rights Reserved.

Upgrading an MLID is the first step to take if you are experiencing unusual, client- specific network problems that you cannot reliably attribute to any other source. Keep a copy of the old version in case the new one is faulty.

A little more care is necessary when upgrading the MLID than when upgrading LSL. This is because the MLID works in close cooperation with the workstation's hardware, particularly the network adapter and system RAM. It is not a simple "plug-in" component like LSL. In particular, default settings may change from one version of an MLID to the next; values that you did not need to specify in NET.CFG may need to be explicitly stated when using the new version.

The following procedure explains how to upgrade a given MLID. It is assumed that you have located a new version of the MLID and verified that it is designed for use with your particular adapter model. It is also assumed that you have taken all the precautions listed in the "Backups" section earlier in this chapter.

  1. Read any documentation that came with the new MLID. This may consist of a README.TXT file on the disk or in the archive file in which you obtained the new MLID or a sample NET.CFG file. Pay particular attention to any references to changes in default settings. The old MLID may have used a 32K RAM area while the new one uses 64K, for example.
  2. Determine the hardware interrupt (IRQ), I/O port address, and shared RAM address used by the adapter. These are best established using the adapter's diagnostic/setup utility. If you don't have a copy, run a system diagnostic utility (such as Microsoft's MSD) with the old MLID running. Note the hardware settings that are actually in use by the card. As a last resort, check the INT, PORT, and MEM values previously entered under the adapter's Link Driver section in the workstation's NET.CFG file. Remember not to take these values too seriously, though.
  3. Examine the NET.CFG file. It should explicitly state the hardware settings used by the adapter. Don't rely on default values--they may have worked in the past but the new MLID may use different defaults. If any of the hardware settings (INT, PORT, MEM, or DMA, if applicable) are not explicitly stated, add an entry with the correct value.
  4. If you made any changes to the NET.CFG file, reboot the workstation to check that the old MLID still works. This is a quick check that the settings you entered are in fact correct.
  5. If you haven't already done so, make a copy of the old MLID. If the new one doesn't work for some reason, you will need to revert to the old.
  6. For the same reason, make a copy of the old NET.CFG file.
  7. If the network files were in the root directory or in an inappropriate location, this is a good time to move them. Copy LSL.COM, IPXODI.COM, and so on, into a suitable directory (C:\NWCLIENT, for example) and edit the batch file that loaded the drivers in the past to reflect the change of path.
  8. Copy the new MLID into place.
  9. Search for and remove any old versions of the MLID on the hard disk. These can cause confusion--you may upgrade the workstation only to have someone else change your configuration at a later stage so that the older driver is loaded.
  10. Restart the machine and test the new MLID.

On those rare occasions when an MLID upgrade results in a deterioration in client performance, be ready to switch back to the previous MLID while you source a newer driver from the adapter manufacturer.

Shell and Requester. The user interface to the network, shell or requester, can be upgraded independently of the other components. The next two sections describe how to do this.

> NOTE: These sections cover only the upgrading of existing drivers--migrating from shell to requester is covered in the "Migrating from NETX to VLM" section later in this chapter.

NETX.EXE. The latest version of the NetWare shell--NETX.EXE--at the time of writing is v3.32, released on November 22, 1994. Novell has ceased development of NETX, and future releases are likely to be limited to bug fixes. You can check your current NETX version using NETx's `/?` command-line option:

    NetWare Workstation Shell  v3.32 (941122) PTF
    (C) Copyright 1994 Novell, Inc.  All Rights Reserved.
    Note: For use with DOS v3.X through v7.X.

As you can see from the last line here, NETX.EXE retained some of the version-specific nature of its NET3.COM and NET4.COM predecessors. It was manifested in a slightly different way; Novell couldn't guarantee that NETX.EXE would work on all possible future versions of DOS, so they made NETX check the DOS version at load time. If the DOS version was not within the range they had tested, NETX would refuse to load. So, for example, version 3.32 of NETX.EXE only loads if the DOS major version is between 3 and 7 inclusive--i.e., from DOS version 3.00 to 7.99.

It is possible to force NETX to load on later versions of DOS using the SETVER utility, as explained in the "NETX and DOS" section later in this chapter. However, it is better to upgrade to a version of NETX that has been tested on the version of DOS that is installed on the workstation.

Upgrade an existing version of NETX.EXE by simply replacing the old version with the new one. To protect against mistakes or the possibility of a corrupt executable file, make sure you back up the old one first. Search for and remove old versions of NETX from the hard disk to avoid confusion.

VLM.EXE. The DOS requester is a relatively recent appearance in the network client software world, and updates to VLM.EXE and the various VLM files are still likely to appear at regular intervals. Check the version of VLM.EXE currently installed on a workstation using the `/?` command line option:

    VLM.EXE NetWare virtual loadable module manager  v1.20 REV B (951002)
    (C) Copyright 1993, 1994, 1995 Novell, Inc.  All Rights Reserved.

Whenever you replace the VLM.EXE executable, be sure to include any new *.VLM modules in the upgrade archive, as well. These are located in a directory called \VLMS that is created when you extract the files from the archive.

Aside from replacing the old VLM files with the new versions, upgrading should involve a review of the entries in the NetWare DOS requester section of the workstation's NET.CFG. The parameters in table 11.2 are new in version 1.20.

#### Table 11.2 New NET.CFG Parameters, VLM v1.20

Parameter | Default
CONFIRM CRITICAL ERROR ACTION | ON
EOJ | ON
FORCE FIRST NETWORK DRIVE | OFF
LIP START SIZE | 0
LOAD LOW FIO | OFF
LOAD LOW NETX | OFF
LOAD LOW REDIR | OFF
LOCK DELAY | 1
LOCK RETRIES | 3

In addition, the default value for the READ ONLY COMPATIBILITY parameter changed from ON to OFF with the release of version 1.20.

The new parameters listed in table 11.2 represent a major improvement in the DOS requester. In particular, the ability to control whether the FIO, NETX, and REDIR VLMs load into upper or conventional memory gives you significantly more control over that all-important balance between performance and memory use.

Remember, these changes arose in a particular minor upgrade of VLM.EXE. The scope and extent of changes illustrates the importance of reading all relevant documentation that accompanies such releases.

### Windows Components

It is not absolutely necessary to install the Windows network components. Windows can use network drive and printer services that were set up under DOS before Windows was loaded. If you map drive X under DOS and then load Windows, for example, drive X is accessible to Windows applications.

Leaving all the network management to DOS is fine as far as DOS activity goes, but it makes for a very restricted network environment under Windows. To change a drive mapping, for example, you have to exit Windows, issue a MAP command, and then restart Windows.

When the Windows network components are installed, errors have been relatively common in the past. The infamous Black Screen of Death (BSOD) syndrome in particular has caused much frustration for users and network administrators alike, with PCs dropping out of Windows to DOS or hanging intermittently, leaving a blank screen with just a cursor in the top left-hand corner. Fortunately, most of the bugs that caused these errors have now been tracked down. Applying the latest Windows NetWare patches should leave you with a fairly stable system.

There are a number of interrelated files that allow Windows to use NetWare services. These files are listed in table 11.3. Because of the way these files interact, it is advisable that you upgrade all files in a set together, rather than mixing and matching from different Novell distribution sets. Everything may seem to work well enough initially, but some functions may not work. For example, mismatched copies of NETWARE.DRV and NWPOPUP.EXE can prevent network broadcast messages from appearing on-screen. No error or warning messages appear about the mismatch but neither does the broadcast pop-up window.

Table 11.3 lists the files that must be installed to allow Windows to manage the NetWare environment. The second column lists the most recent file versions at the time of this book's publication. The third column indicates whether the files are for use with NETX or VLM.

#### Table 11.3 Windows NetWare Files

File | Version | VLM/NETX | Purpose
*NETAPI.DLL | 1.30 | Both | SQL Server support
NETWARE.DRV | 3.03 | VLM | Client Windows driver for NetWare
NETWARE.DRV | 2.02 | NETX | Client Windows driver for NetWare
NETWARE.HLP |  | Both | Windows Help file for NETWARE.DRV
NWCALLS.DLL | 4.10 | Both | NCP communications
NWGDI.DLL | 1.01 | VLM | Graphical display interface for NETWARE.DRV, version 3 or later
NWIPXSPX.DLL | 4.10 | Both | IPX/SPX communications
NWLOCALE.DLL | 4.10 | Both | Localization/Internationalization
NWNET.DLL | 4.10 | Both | Support for NDS
*NWNETAPI.DLL | 1.30 | Both | NCP communications
NWPOPUP.EXE | 3.01 | Both | Displays a broadcast message in a dialog box under Windows
*NWPSERV.DLL | 1.30 | Both | Print server support
NWPSRV.DLL | 4.10 | Both | Print server support
NWUSER.EXE | 1.02 | VLM | Utility for managing a workstation's network environment under Windows
VIPX.386 | 1.19 | Both | Virtual IPX/SPX driver
VNETWARE.386 | 2.04 | Both | Virtual NetWare driver
**VPICDA.386 |  | Both | Virtual interrupt driver

* Outdated files that are no longer maintained by Novell--some older applications may still require them.

** VPICDA.386 is for Windows 3.0 only. It fixes a problem with network adapters using IRQ 2 or an IRQ of 9 or higher.

### Manually Upgrading Windows Network Components

For a workstation that has no Windows network support (or for a workstation that has become hopelessly muddled), the NetWare Client Installation program is the best way to ensure that all the correct files are copied to the appropriate directories on the workstation. There are times, however, when it may benefit you to know exactly what the benefits of the Windows components are, as well as what files should go where.

This section describes how to manually install or upgrade the Windows network software components. When installed, they enable you to do the following:

- Manage network connections
- Manage drive mappings
- Manage printer mappings
- Receive broadcast messages

Network connections and mappings can be managed using File Manager or from within applications that use the standard Windows file selection dialog boxes. If the Windows network software components are installed, Windows presents a Network button in these dialog boxes. Clicking the Network button displays a dialog box like the one shown in figure 11.3.

Figure 11.3
The Windows Network-Drive Connections dialog box is used to associate network drives with workstation drive letters.

> CAUTION: The following instructions apply to the latest available Novell file distributions at the time of writing, contained in WINDR3.EXE, NWDLL2.EXE, NET33X.EXE (NETX workstations only), and VLMUP4.EXE (VLM workstations only). If you are using a more recent release of any of these files, check the accompanying documentation carefully before installing any files. Also, check before installing any files that the versions you are installing are in fact more recent than the versions you are replacing! Although many of the same files are included in the NetWare Client Installation Kit, they are packaged for use with the installation program included. The release files listed previously are more easily manageable when you are performing a manual installation.

Windows Network Files.

  1. Get a copy of the latest update distribution sets.
  2. For VLM workstations, apply the patches in VLMUP4.EXE. The version of VIPX.386 (v1.19) in WINDR3.EXE requires version 2.12 or higher of LSL.COM and version 3.01 or higher of IPXODI.COM.
  3. For NETX workstations, apply the patches in NET33X.EXE. The version of NETWARE.DRV in NET33X.EXE is 2.02 and is for use with NETX. WINDR3.EXE contains version 3.03 of NETWARE.DRV, which is for use with VLM.
  4. Create an expanded distribution set from WINDR3.EXE. Create a new directory for the purpose, change to the new directory, and run the self-extracting archive from there. WINDR3 expands its files into the following directories:

> (top level)

> VLMDRVS

> NTSWD

> READMES

> STANDARD

> VXDS

  The following instructions refer to these subdirectories by name. For example, the instruction "Copy WINDR3\VXDS\VIPX.386 to the Windows SYSTEM directory" means "Copy the file VIPX.386 from the VXDS subdirectory of the expanded WINDR3 distribution set to the workstation's Windows SYSTEM directory."
  5. Create an expanded distribution set from NWDLL2.EXE. Create a new directory for the purpose, change to the new directory, and run the self-extracting archive from there. NWDLL2 expands its files into the following directories:

> (top level)

> NWDLL

> OLDDLLS

  The following instructions refer to these subdirectories by name. For example, the instruction "Copy NWDLL2\NWDLL\NWCALLS.DLL to the Windows SYSTEM directory" means "Copy the file NWCALLS.DLL from the NWDLL subdirectory of the expanded NWDLL2 distribution set to the workstation's Windows SYSTEM directory."
  6. Identify the Windows and the Windows System directories. These are usually \WINDOWS and \WINDOWS\SYSTEM, respectively, on the PC's boot disk, but they could also appear under a different directory name.
  7. Check for stray copies of the NetWare files in the wrong directories. You may install the latest version of a file in the \WINDOWS\SYSTEM directory only to have an overlooked older version in the \WINDOWS directory load instead of the new one.
  8. Edit the SYSTEM.INI file (located in the \WINDOWS directory) using a text editor. Add the following entries or, if entries already exist for these parameters, make sure that the values match those given here:

>     [boot]
>     network.drv=netware.drv
>     [386Enh]
>     network=*vnetbios,vnetware.386,vipx.386
>     TimerCriticalSection=10000

  9. Edit the `load=` line under the `[windows]` section of WIN.INI (in the \WINDOWS directory) to include NWPOPUP.EXE. If no other programs are listed for loading, you end up with the following:

>     load=NWPOPUP.EXE

  If other programs are listed for loading by Windows, leave them there; add NWPOPUP.EXE at the end, resulting in something like the following:

>     load=SCHED.EXE,NWPOPUP.EXE

  10. If you are upgrading a shared network installation of Windows, make sure that no users are running Windows before you start the upgrade and that none can start Windows while you perform the upgrade. If they do, their workstation may open VIPX.386, for example, and you can't overwrite it with the new version. This could result in a partial upgrade in which some files are updated and others are not--a situation that could leave you worse off than when you started.

  11. Refer to the "Backups" section earlier in this chapter and make sure you have taken all necessary precautions before proceeding.

What you do next depends on the version of Windows you are running, the mode in which it runs, and whether you are using the NetWare shell or the DOS requester. The following sections explain what to do in each case.

All Windows Installations. In all cases, copy the following files to the Windows SYSTEM directory:

WINDR3\NWPOPUP.EXE

WINDR3\VXDS\VIPX.386

WINDR3\VXDS\VNETWARE.386

NWDLL2\NWDLL\NWCALLS.DLL

NWDLL2\NWDLL\NWIPXSPX.DLL

NWDLL2\NWDLL\NWLOCALE.DLL

NWDLL2\NWDLL\NWNET.DLL

NWDLL2\NWDLL\NWPSRV.DLL

On Personal NetWare systems, also copy NWDLL2\NWDLL\PNW.DLL to the Windows System directory.

If any of the files NETAPI.DLL, NWNETAPI.DLL, or NWPSERV.DLL exist in the workstation's Windows or Windows System directory, copy the corresponding files from the OLDDLLS directory of the NWDLL2 distribution set.

NetWare Shell. If the workstation uses the NetWare shell (NETX.EXE), make sure you have copied NETWARE.DRV and its accompanying Help file NETWARE.HLP, from the NET33X distribution set to the Windows System directory.

NetWare DOS Requester.

> CAUTION: Version 1.19 of VIPX.386, as distributed in WINDR3.EXE, requires version 2.12 or higher of LSL.COM and version 3.01 or higher of IPXODI.COM. These are distributed in VLMUP4.EXE. Refer to the previous VLM upgrade instructions, and make sure that these files are at the appropriate revision level before carrying out the Windows upgrade.

If the workstation uses the NetWare DOS requester (VLM.EXE), copy the following files to the Windows SYSTEM directory:

NWDLL2\NWDLL\NWGDI.DLL

WINDR3\VLMDRVS\NETWARE.DRV

WINDR3\VLMDRVS\NETWARE.HLP

WINDR3\VLMDRVS\NWUSER.EXE

Create a program icon for NWUSER.EXE if one does not already exist. If an icon already exists, check that it points to the new NWUSER.EXE that you have just installed.

Create a subdirectory called NLS of the WINDOWS directory if it doesn't already exist. Copy the following files into it:

WINDR3\VLMDRVS\1252_UNI.001

WINDR3\VLMDRVS\437_UNI.001

WINDR3\VLMDRVS\850_UNI.001

WINDR3\VLMDRVS\UNI_1252.001

WINDR3\VLMDRVS\UNI_437.001

WINDR3\VLMDRVS\UNI_850.001

WINDR3\VLMDRVS\UNI_COL.001

WINDR3\VLMDRVS\UNI_MON.001

The DOS requester allows drive mappings in DOS sessions under Windows to be either global or private. If mappings are global, a change in drive mappings in one DOS session affects all other DOS Windows, too. Private mappings allow each DOS session to maintain separate mappings. Mappings are private by default; to change them to global, add the following line to the `[NetWare]` section of SYSTEM.INI:

    NWShareHandles=TRUE

### Migrating from NETX to VLM

The NetWare DOS requester offers many advantages over the NetWare shell. The modular architecture allows you to load only those components that you need; the intelligent, automatic memory optimization features can be overridden using NET.CFG entries; and the switch from a shell to a redirector gives you a networking environment that interacts more smoothly with the operating system. The features of the NetWare DOS requester are covered in more detail in chapter 8, "Novell NetWare."

The fundamental architectural and conceptual differences between the shell and requester mean that migrating from NETX to VLM is not seamless. This part of the chapter deals with the issues you have to confront when migrating.

Installing the VLM Upgrade. The installation itself is quite straightforward:

> NOTE: The following upgrade procedure assumes that the workstation is working correctly using the NetWare shell, NETX.EXE. If not, refer to "Installing the VLM Client" earlier in this chapter and perform a full installation from scratch.

  1. Get a copy of the latest client distribution kit. At the time of writing, this is VLMUP4.EXE.
  2. Create an expanded distribution set from VLMUP4.EXE. Create a new directory for the purpose, change to the new directory, and run the self-extracting archive from there. VLMUP4 expands its files into the following directories:

> (top level)

> ODIDRV

> VLMS

  3. Create a new network client software directory (for example, \NWCLIENT) on the workstation. It is best to leave the NETX setup in place until you are satisfied that the VLM setup is working properly.
  4. Copy the MLID for your adapter and your NET.CFG file from the old (NETX) client directory to your new (VLM) directory.
  5. Make sure you have the most recent LSL and IPXODI programs by copying the following files to the new directory. Copy the version in the VLMS directory of the expanded distribution set, unless the version in the old NETX directory happens to be more recent:

> LSL.COM

> LSL.MSG

> IPXODI.COM

> IPXODI.MSG

  6. Copy VLM.EXE and *.VLM from the VLMS directory of the expanded distribution set to the new client directory.
  7. Edit AUTOEXEC.BAT (or whatever batch file loads the network drivers) to load LSL, IPXODI, and so on, from the new client directory, and to load VLM instead of NETX.
  8. Reboot the workstation and test the connection!

Note that this is a minimal DOS upgrade. Refer to the other sections in this chapter on Windows, user environment, and tuning to complete the upgrade.

Windows Changes. Refer to the "Windows Network Files" section earlier in this chapter. Upgrade the workstation according to those instructions, making sure in particular that:

- NETWARE.DRV is version 3.03 or later--the old version that worked with NETX does not suffice with VLM.
- NWGDI.EXE has been copied to the Windows SYSTEM directory.
- Any stray older network files in the WINDOWS directory have been removed.

User Environment Changes. The architectural differences between NETX and VLM result in a number of changes from the user's point of view, as discussed in detail in chapter 8, "Novell NetWare." Follow these steps to make the transition from shell to requester as smooth as possible:

  1. Add the line

>     LASTDRIVE = Z

  to the workstation's CONFIG.SYS. The NetWare shell uses drive letters beginning after the last DOS drive; the requester uses driver letters up to and including the last DOS drive. Adding this line allows the requester to use the same range of drive letters as the shell used.
  2. The `FILES` parameter in the workstation's CONFIG.SYS limits the number of files that DOS can have open at one time. NETX handles network file requests without involving DOS' file handling mechanism, so the `FILES` parameter applies only to local files. The requester is different--it allows DOS to handle all files, local and network. This means that the `FILES` parameter must be increased to account for network files as well as local files.
  Increase the number of DOS file handles by editing the `FILES` line in CONFIG.SYS. If there is no such line there, add one:

>     FILES = 100

  How big a value should you use? You can easily duplicate the NETX limit under VLM by adding together the DOS and network file handle limits. Suppose for example that CONFIG.SYS specified `FILES=30` and the NET.CFG or SHELL.CFG had no `File Handles` line. This means that NETX was maintaining the default of 40 file handles, giving a total of 70 file handles in all. Changing the `FILES` value in CONFIG.SYS from 30 to 70 gives the same maximum file limit as before.
  This may be a good time to review the file limit. In most cases, a value of 100 or so is appropriate, particularly if the workstation runs Windows. The amount of memory required per file handle is about 60 bytes, so increasing the `FILES` value from 30 to 100 uses an additional 4K of RAM. Bear in mind that this memory cost will be more than compensated for by the substantial improvements in memory you get by switching from NETX to VLM.
  3. Create a `NetWare DOS Requester` section in the workstation's NET.CFG file.
  4. Force the first network drive to be the same as it was under NETX by adding the following line to NET.CFG's `NetWare DOS Requester` section:

>     First Network Drive = F

  If the first network drive letter under NETX was not F, substitute the appropriate letter here.
  This change is required because NETX uses the first drive letter after the last DOS drive as the first network drive; VLM uses the first available DOS drive letter. Users accustomed to using `F:` as the logon drive may be confused if it suddenly appears as drive `D:`.
  5. The first network drive is mapped to a server's logon area when the workstation establishes a connection. VLM performs a root mapping, while NETX does not. This difference is due to the fact that DOS cannot cope with a subdirectory (\LOGIN) of a drive when the root is not accessible. The result is that the prompt at the first network drive changes from something like

>     F:\LOGIN>

  to

>     F:\>

  Alert users to this change. Also, check any batch files that may have referred explicitly to `F:\LOGIN` and use `F:\` instead. If that is not possible--if both NETX and VLM workstations will use these batch files--try using `F:` without a path. This should work whether the drive is root mapped or not.

Note that these steps are designed to make the transition from NETX to VLM as smooth as possible for the user. It may be more appropriate to use the default VLM configuration, particularly in the case of experienced users. The "NET.CFG" section later in this chapter describes how to take full advantage of the flexibility of the DOS requester by using appropriate entries in the `NetWare DOS Requester` section of NET.CFG.

Migrating from SHELL.CFG to NET.CFG. The NET.CFG file stores configuration information for a number of network components, including LSL, IPX, and other protocol-specific drivers and either the NetWare shell or DOS requester. Entries in the various sections (called "options") of NET.CFG override the default behavior of the relevant program. Before the introduction of ODI, the configuration information for the NetWare shell was stored in a file called SHELL.CFG in the root directory of the workstation's boot disk. This section explains how to migrate the entries in an existing SHELL.CFG file to NET.CFG, retaining the configuration settings in the SHELL.CFG.

> NOTE: If there is no SHELL.CFG file on the workstation that you are upgrading, this section does not apply.

If the workstation has a SHELL.CFG file, review the entries in it and decide which, if any, are still necessary. For each entry that you decide to keep, copy the relevant line in SHELL.CFG to the appropriate section of NET.CFG. Table 11.4 lists the possible SHELL.CFG entries and the corresponding NET.CFG options.

#### Table 11.4 SHELL.CFG Parameters and NET.CFG

SHELL.CFG Parameter | NET.CFG Option
ALL SERVERS | (Obsolete)
CACHE BUFFERS | NetWare DOS requester
CONFIG OPTION | (Obsolete)
ENTRY STACK SIZE | (Obsolete)
EOJ | NetWare DOS requester
FILE HANDLES | (Obsolete)
HOLD | (Obsolete)
INT64 | Protocol IPX
INT7A | Protocol IPX
IPATCH | Protocol IPX
IPX PACKET SIZE LIMIT | Protocol IPX
IPX RETRY COUNT | Protocol IPX
IPX SOCKETS | Protocol IPX
LOCAL PRINTERS | NetWare DOS requester
LOCK DELAY | NetWare DOS requester
LOCK RETRIES | NetWare DOS requester
LONG MACHINE TYPE | NetWare DOS requester
MAX CUR DIR LENGTH | (Obsolete)
MAX PATH LENGTH | (Obsolete)
MAX TASKS | NetWare DOS requester
NETBIOS ABORT TIMEOUT | NetBIOS
NETBIOS BROADCAST COUNT | NetBIOS
NETBIOS BROADCAST DELAY | NetBIOS
NETBIOS COMMANDS | NetBIOS
NETBIOS INTERNET | NetBIOS
NETBIOS LISTEN TIMEOUT | NetBIOS
NETBIOS RECEIVE BUFFERS | NetBIOS
NETBIOS RETRY COUNT | NetBIOS
NETBIOS RETRY DELAY | NetBIOS
NETBIOS SEND BUFFERS | NetBIOS
NETBIOS SESSIONS | NetBIOS
NETBIOS VERIFY TIMEOUT | NetBIOS
NPATCH | NetBIOS
PATCH | (Obsolete)
PREFERRED SERVER | NetWare DOS requester
PRINT HEADER | NetWare DOS requester
PRINT TAIL | NetWare DOS requester
READ ONLY COMPATIBILITY | NetWare DOS requester
SEARCH MODE | NetWare DOS requester
SET STATION TIME | NetWare DOS requester
SHARE | (Obsolete)
SHORT MACHINE TYPE | NetWare DOS requester
SHOW DOTS | NetWare DOS requester
SPECIAL UPPERCASE | (Obsolete)
SPX ABORT TIMEOUT | Protocol SPX
SPX CONNECTIONS | Protocol SPX
SPX LISTEN TIMEOUT | Protocol SPX
SPX VERIFY TIMEOUT | Protocol SPX
TASK MODE | (Obsolete)

So for example, to migrate a SHELL.CFG consisting of just two lines:

    LOCAL PRINTERS = 0
    FILE HANDLES = 30

Add the `LOCAL PRINTERS = 0` line to the `NetWare DOS Requester` section of NET.CFG, and then delete the SHELL.CFG file.

### Additional Protocols

One of the greatest strengths of the ODI system is the ease with which a workstation can be configured to handle new protocols. A NetWare client that uses only IPX may have a `Link Driver` section something like this:

    Link driver NE2000
         Int  3
         Mem  C8000
         Port 300
         Frame Ethernet_II
         Protocol IPX    8137 Ethernet_II

The MLID can be instructed to handle IP packets too, by adding a line here that tells the MLID which protocol ID is used by IP when using Ethernet II frames. This example is for Beame & Whiteside's TCP/IP package--note that their ETHDEV.SYS driver program requires a protocol of its own:

    Link driver NE2000
         Int  3
         Mem  C8000
         Port 300
         Frame Ethernet_II
         Protocol IPX    8137 Ethernet_II
         Protocol ETHDEV 0    Ethernet_II
         Protocol IP     0800 Ethernet_II
         Protocol ARP    0806 Ethernet_II

Refer to table 11.6 for a list of some of the more common protocol ID values.

Of course, this by itself just tells the MLID how to handle IP packets, not how to send them or what to do with them if any should arrive! To make use of IP, the workstation also needs to load an IP protocol driver such as Novell's TCPIP.EXE.

### DOS Upgrades

Workstations may require a few changes in the network software configuration after a DOS upgrade. Other adjustments, while not absolutely necessary, may allow you to take advantage of the new DOS version. This section describes what to look out for after a DOS upgrade.

NETX and DOS Versions. Upgrading DOS used to mean upgrading to a new NET*.COM. NET3.COM was designed to work with DOS 3.x, so if a workstation was upgraded to version 4 of DOS, it needed a copy of NET4.COM. This is no longer the case, but a certain degree of sensitivity to DOS versions remains on workstations that are using the NetWare shell. When NETX starts to load, it asks DOS for its version number. If the number returned by DOS is outside the range that NETX considers acceptable, NETX refuses to load, reporting an error:

    SHELL-332-29: Shell requires DOS v3.X through v6.X.
    The NetWare shell is not loaded

So, a version of NETX that has been running without difficulty on a workstation may suddenly refuse to load after a DOS upgrade.

You can persuade NETX to load in such circumstances by using the DOS SETVER utility. First, make sure SETVER is loaded in the workstation's CONFIG.SYS. Look for a line like this on the form:

    DEVICEHIGH=C:\DOS\SETVER.EXE

If no such line is present, add one (substituting the appropriate DOS path). Then tell SETVER to lie to NETX.EXE about the DOS version:

    C:\> SETVER NETX.EXE 6.0

and reboot the machine for this change to take effect. From now on, when DOS receives a query from NETX.EXE to return its version number, it returns 6.0, regardless of the DOS version that is really running. NETX should then load without complaint.

## NET.CFG Parameters

The NET.CFG file can hold entries to control almost every aspect of networking on a workstation. This section looks at the possible entries, their parameters, and the reasons why you might use each of them.

### NET.CFG Location and Layout

By default, LSL.COM looks for NET.CFG in the directory from which LSL.COM was loaded. If NET.CFG is not found there, then LSL.COM looks in the current working directory. You can override this search mechanism by specifying a path for NET.CFG using LSL's `/C` parameter, as in the following example:

    LSL /C=C:\NWCLIENT\NET.CFG

The NET.CFG file has a simple structure. Edit it using a text editor, in accordance with the following guidelines:

- NET.CFG is laid out in sections known as options.
- Each option has a heading that is flush with the left margin.
- The individual parameters that apply to the option are listed, one per line, under the option heading.
- Parameter lines must be indented at least one space from the left margin--indent one tab space for clarity.
- Comment lines begin with a semicolon. A semicolon at the start of a parameter line disables that parameter line; a semicolon at the start of an option heading line disables the entire section.
- Include as many blank lines and comment lines as you want--these make the file easier to read. It's a good idea to insert comments to remind yourself later why you chose a particular parameter value.

NET.CFG entries fall into a number of categories:

- Link Driver
- Link Support
- Protocol IPX
- NetWare DOS requester

The following sections look at these categories in detail.

### Link Driver

Entries in the `Link Driver` section of NET.CFG specify parameters related to the MLID. If your workstation has more than one network adapter, you can enter more than one `Link Driver` section. The section heading is of the form

    Link Driver <MLID>

where <`MLID`> is the name of the adapter's ODI driver.

> NOTE: The driver name required on the heading line is the internal name of the MLID. This usually, but not always, is the name of the executable file. If you're using an MLID named EWRK3.COM, the name to use in the section heading is probably `EWRK3`.

> Run the MLID with the `/?` command-line option to see the internal MLID name.

The `Link Driver` section can contain both hardware and software settings. Strictly speaking, you only need to enter a hardware setting if the setting on the workstation's adapter is different from the default value assumed by the MLID. The defaults, however, might change between versions of the MLID. In practice, it makes sense to enter all the settings here rather than rely on the MLID to provide the default values you want.

You can specify more than one value for some of the hardware options (MEM, PORT, INT, and DMA). For example, a board might use two I/O port address ranges. If so, specify the second value using the `#2` qualifier, as in the following example:

    PORT #2 300

You can specify the first value with or without using the `#1` qualifier. Any value given is assumed to be the first value unless you stipulate otherwise.

Table 11.5 lists the available `Link Driver` entries.

#### Table 11.5 NET.CFG: Link Driver Entries

Entry | Parameters | Purpose
DMA | Channel | Specify DMA channel used by adapter
FRAME | Type | Enable a frame type on the adapter
INT | IRQ | Specify interrupt used by adapter
MEM | Start [Length] | Specify adapter's shared RAM area
PORT | Start [Number] | Specify adapter's I/O port
PROTOCOL | Name ID Frame | Define a protocol to the adapter
SLOT | Number | Specify adapter slot

The `Link Driver` entries are explained in turn below. `DMA`. If the adapter uses a DMA channel, specify the channel number here, as in the following example:

    Link Driver WLAN40
         DMA 2

`FRAME`. An ODI driver can handle several frame types at once. To do this, the MLID sets up a logical board for each frame type on each adapter. Frames of one type on a particular adapter are treated as if they come from a specific logical board; frames of another type on the same adapter are treated as if they come from a different logical board. In the `Link Driver` section, insert one `FRAME` entry for each frame type that will be handled by the adapter. The following are valid Ethernet frame types:

- `Ethernet_802.2` (Default)
- `Ethernet_802.3`
- `Ethernet_II`
- `Ethernet_SNAP`

Here's an example of how to specify the frame type:

    Link Driver WLAN40
         FRAME Ethernet_802.3
         FRAME Ethernet_II

`INT`. With `INT` you specify the interrupt channel used by the adapter. You must get this right or your client is unable to use the network! Here's an example of a valid `INT` entry:

    Link Driver WLAN40
         INT 5

`MEM`.`` If the adapter uses a shared RAM area, enter the start address in hexadecimal following `MEM`. You also can specify the length (again, in hexadecimal), but this usually is unnecessary--the adapter just uses what it needs. Use the `X=` parameter on the `EMM386` line in CONFIG.SYS to reserve the necessary memory for the adapter. Here's an example of a valid `MEM` entry:

    Link Driver WLAN40
         MEM D0000

`PORT`.`` With `PORT`, you specify (in hexadecimal) the I/O port used by the adapter. You also can specify the number of ports to reserve, but that usually is unnecessary. Here's an example of a valid `PORT` entry:

    Link Driver WLAN40
         PORT 280

`PROTOCOL`. You must specify each protocol that is to be handled by the adapter. This means adding a `PROTOCOL` entry for each protocol to the adapter's `Link Driver` section of NET.CFG. Each `PROTOCOL` entry must specify the following:

- Protocol name
- Protocol ID
- Frame type

The protocol ID is a hexadecimal number that has been assigned to identify a protocol and frame type combination. For example, IPX using Ethernet_802.3 frames has ID 0, and IPX using Ethernet_II frames has ID 8137.

Table 11.6 lists some common frame types and the corresponding protocol IDs.

#### Table 11.6 Protocol IDs

Protocol | Frame Type | Protocol ID
IPX | Ethernet_802.2 | E0
IPX | Ethernet_802.3 | 00
IPX | Ethernet_II | 8137
IPX | Ethernet_SNAP | 8137
IPX | Token-Ring | E0
IP | Ethernet_II | 800
IP | Ethernet_SNAP | 800
AppleTalk | Ethernet_II | 809B

Here's an example that contains two valid `PROTOCOL` entries:

    Link Driver WLAN40
         PROTOCOL IP 800 Ethernet_II
         PROTOCOL IPX E0 Ethernet_802.2

`SLOT`.`` EISA and MicroChannel bus machines generally can locate the slot holding the adapter card by scanning all slots. Use this option to force the machine to use a given slot.

The use of `SLOT` is very straightforward, as shown in the following example:

    SLOT 5

### Link Support

The `Link Support` section of NET.CFG contains settings related to buffers and stacks used by the network software. Table 11.7 lists the valid `Link Support` entries.

#### Table 11.7 NET.CFG: Link Support Entries

Entry | Parameters | Purpose
BUFFERS | Number [Size] | Specify LSL receive buffers
MAX BOARDS | Number | Specify maximum logical boards
MAX STACKS | Number | Specify maximum logical protocol stack IDs
MEMPOOL | Number | Specify size of LSL memory pool buffers

The `Link Support` entries are explained in turn.

`BUFFERS`.`` Use the `BUFFERS` setting to override the default of zero buffers maintained by the LSL. Some protocol stacks require the LSL to maintain receive buffers. IPX does not--it maintains its own buffers. The default size is 1,130 bytes; you can override this by specifying the size as a second parameter on the `BUFFERS` line, as in the following example:

    Link Support
         BUFFERS 8 1564

This instructs the LSL to maintain eight buffers of 1,564 bytes each. The memory hit is easily calculated--in this case, it is 8x1,564 bytes, or just over 12K.

Increasing the number of buffers might help to improve performance on workstations that make many connections. The optimal buffer size is close to the largest packet size that will be received by the workstation.

Do not allow the total buffer space to exceed 59K. The buffers are allocated from the same 64K segment as the `MEMPOOL` and some of the LSL program code.

`MAX BOARDS`. The LSL can handle up to 16 logical adapters. The default number of logical adapters is four, which means that the number of adapter/frame type combinations cannot exceed four unless this value is increased. A single adapter using four frame types, therefore, works with the default setting, but adding a second adapter with four frame types means having to increase this value to eight, as in the following example:

    Link Support
         MAX BOARDS 8

The memory hit for allowing the LSL to handle extra logical boards is fairly low, about 200 bytes per logical board. Similarly, the memory saved by reducing the maximum logical boards is roughly 200 bytes per board.

`MAX STACKS`. The LSL can maintain up to 16 logical protocol stack IDs. The default is four. If you need to define more than four protocol IDs (using `PROTOCOL` lines in the `Link Driver` sections), use a value greater than four, as in the following example:

    Link Support
         MAX STACKS 8

You can save a tiny amount of memory by limiting the maximum number of stacks to the number actually in use.

`MEMPOOL`.`` Some protocols require that the LSL maintain memory buffers of a particular size. Use the `MEMPOOL` option to set this value:

    Link Support
         MEMPOOL 2K

IPXODI does not use `MEMPOOL`.

### Protocol IPX

Some of the IPX protocol's default parameter values can be changed, although this rarely is necessary. Table 11.8 lists the valid `Protocol IPX` entries.

#### Table 11.8 NET.CFG: Protocol IPX Entries

Entry | Parameters | Purpose
BIND | Board | Force bind to specific board
INT64 | on/off | Stop IPX using Int 64
INT7A | on/off | Stop IPX using Int 7A
IPX PACKET SIZE LIMIT | Number | Set maximum packet size used
IPX RETRY COUNT | Number | Tell SPX how often to resend
IPX SOCKETS | Number | Set maximum IPX sockets maintained

The `Protocol IPX` entries are explained in turn.

`BIND`. Protocols usually bind to the first MLID they find. The `BIND` option can be used to force a protocol to bind to a specific MLID. For example, to force IP to bind to the `EWRK3` driver, use the following:

    Protocol IPX
         BIND EWRK3

If you have loaded multiple drivers, differentiate between them by specifying the driver number, as well:

    Protocol IPX
         BIND EWRK3 #2

`INT64`. Some applications may need to use interrupt 64h, which ordinarily is used by NetWare. Set the `INT64` parameter to `off` to avoid such clashes:

    Protocol IPX
         INT64 off

`INT7A`. Some applications might need to use interrupt 7Ah, which ordinarily is used by NetWare. Set the `INT7A` parameter to `off` to avoid such clashes:

    Protocol IPX
         INT7A off

`IPX PACKET SIZE LIMIT`. IPX packets can vary in size, up to 6,500 bytes. Some MLIDs insist on a smaller limit; in fact, you may want to set the limit lower if the client work-station is running into memory allocation trouble. The default limit is 4,160 bytes unless the MLID specifies a smaller value. The minimum size limit is 576 bytes. To set a value of 1,500 bytes, for example, use the following:

    Protocol IPX
         IPX PACKET SIZE LIMIT 1500

`IPX RETRY COUNT`. IPX does not resend packets, but SPX does if it gets no response. The `IPX RETRY COUNT` option is used to tell SPX how many times it should try sending a packet. The default value is 20 times. Increasing this to 40 might be necessary on a network that drops a lot of packets. You can cause such an increase with the following entry:

    Protocol IPX
         IPX RETRY COUNT 40

`IPX SOCKETS`. IPX normally maintains 20 sockets on the workstation. Some programs that use IPX directly might require more sockets than this. You can increase the value by using the `IPX SOCKETS` option as follows:

    Protocol IPX
         IPX SOCKETS 50

### NetWare DOS Requester

VLM.EXE uses the same NET.CFG file as LSL.COM. The `NetWare DOS Requester` section of NET.CFG controls many aspects of the operation of VLM.EXE and the individual VLMs (see table 11.9). Careful attention to this section can help to tune workstation performance, memory use, and the user environment.

> NOTE:`NetWare DOS Requester` entries in NET.CFG use an equal sign (`=`) between the name of the option and the value that it takes. This differs from the entries in the NET.CFG sections described earlier.

#### Table 11.9 NET.CFG: NetWare DOS Requester Entries

Entry | Default | Parameters | VLMs Affected
AUTO LARGE TABLE = | ON | ON/OFF | AUTO
AUTO RECONNECT = | OFF | ON/OFF | AUTO, NDS
AUTO RETRY = | 0 | Number | AUTO
AVERAGE NAME LENGTH = | 48 | Number | CONN
BIND RECONNECT = | OFF | ON/OFF | AUTO, BIND
CACHE BUFFER SIZE = | -- | Number | FIO
CACHE BUFFERS = | 5 | Number | FIO
CACHE WRITES = | ON | ON/OFF | FIO
CHECKSUM = | 1 | Number | IPXNCP, NWP
CONFIRM CRITICAL ERROR ACTION = | ON | ON/OFF | --
CONNECTIONS = | 8 | Number | AUTO, CONN, FIO, NDS, SECURITY
DOS NAME = | MSDOS | Name | GENERAL, NETX
EOJ = | ON | ON/OFF | NETX, REDIR
EXCLUDE VLM = | -- | VLMs | --
FIRST NETWORK DRIVE = | -- | Letter | GENERAL, NETX
FORCE FIRST NETWORK DRIVE = | OFF | ON/OFF | GENERAL
LARGE INTERNET PACKETS = | ON | ON/OFF | IPXNCP, NWP
LIP START SIZE = | 0 | Number | IPXNCP, NWP
LOAD CONN TABLE LOW = | OFF | ON/OFF | CONN
LOAD LOW CONN = | ON | ON/OFF | CONN
LOAD LOW FIO = | OFF | ON/OFF | FIO
LOAD LOW IPXNCP = | ON | ON/OFF | IPXNCP
LOAD LOW NETX = | OFF | ON/OFF | NETX
LOAD LOW REDIR = | OFF | ON/OFF | REDIR
LOCAL PRINTERS = | 3 | Number | PRINT
LONG MACHINE TYPE = | IBM_PC | Name | GENERAL, NETX
MAX TASKS = | 31 | Number | CONN
MESSAGE LEVEL = | 1 | Number | --
MESSAGE TIMEOUT = | 0 | Number | NWP
MINIMUM TIME TO NET = | -- | Number | --
NAME CONTEXT = | -- | Name | NDS
NETWARE PROTOCOL = | -- | List | --
NETWORK PRINTERS = | 3 | Number | PRINT
PB BUFFERS = | 1 | Number | FIO, IPXNCP
PREFERRED SERVER = | -- | Name | BIND
PREFERRED TREE = | -- | Name | NDS
PRINT BUFFER SIZE = | 64 | Number | PRINT
PRINT HEADER = | 64 | Number | PRINT
PRINT TAIL = | 16 | Number | PRINT
READ ONLY COMPATIBILITY = | OFF | ON/OFF | REDIR
SET STATION TIME = | ON | ON/OFF | --
SHORT MACHINE TYPE = | IBM | Name | GENERAL, NETX
SHOW DOTS = | OFF | ON/OFF | REDIR
SIGNATURE LEVEL = | 1 | Number | NWP, SECURITY
USE DEFAULTS = | ON | ON/OFF | --
VLM = | -- | Path | --

The `NetWare DOS Requester` entries are explained in the following sections.

`AUTO LARGE TABLE`. AUTO.VLM tries to restore network connections that have been lost. To do this, it must store username and password information for each connection established. It normally uses just 34 bytes to store this information. If the length of the username and password combined is likely to be greater than 32 characters (that's 34 characters, including the terminators), then you need to tell AUTO.VLM to reserve more space for the reconnection information. For example, the entry

    AUTO LARGE TABLE = ON

tells AUTO.VLM to use 178 bytes per connection rather than the default 34 bytes per connection.

For this parameter to have any effect, AUTO.VLM must be loaded and `BIND RECONNECT` must be set to `ON`. For NDS reconnections, RSA.VLM also must be loaded.

`AUTO RECONNECT`. As explained in the preceding section, AUTO.VLM attempts to re-establish network connections in the event of a lost connection. You can turn off this behavior if you want to:

    AUTO RECONNECT = OFF

If this option is used, AUTO.VLM fails to load. Removing AUTO.VLM from the list of VLMs to be loaded has the same effect as setting `AUTO RECONNECT = OFF`.

`AUTO RETRY`. As explained earlier, AUTO.VLM attempts to reestablish network connections in the event of a lost connection. The `AUTO RETRY` option tells AUTO.VLM how many seconds to wait before attempting to reestablish a connection. The default behavior is for AUTO.VLM to try to reconnect as soon as a critical network error message occurs. You can tell it to wait a longer time before retrying; to do so, use a line such as the following:

    AUTO RETRY = 10

This tells AUTO.VLM to wait 10 seconds before retrying the connection.

For this parameter to have any effect, AUTO.VLM must be loaded. For NDS reconnections, RSA.VLM also must be loaded.

> CAUTION: The entry `AUTO RETRY = 0` is regarded by AUTO.VLM as an instruction to not reconnect at all. This obviously is not the same as AUTO.VLM waiting the default of 0 seconds before retrying.

`AVERAGE NAME LENGTH`. CONN.VLM stores server names in a table that has a fixed size when VLM.EXE loads. It allows a default of 48 characters per server name, for the number of servers specified using the `CONNECTIONS` setting. You can tell CONN.VLM to use less memory for its connection table by setting `AVERAGE NAME LENGTH` to a value smaller than the default. For example,

    AVERAGE NAME LENGTH = 8

saves 40 characters per allowed connection. If the maximum number of connections is the default (eight), then a total of 320 bytes of memory are saved by making this change.

> NOTE: The name lengths referred to here include a terminating character. Thus, specifying an `AVERAGE NAME LENGTH` of `8` only allows for an average of seven characters per file server name.

`BIND RECONNECT`. AUTO.VLM normally tries to reestablish lost network connections without restoring any drive mappings and printer connections that were lost when the connection was broken.

    BIND RECONNECT = ON

tells AUTO.VLM to attempt to restore the drive mappings and printer connections that were in effect before the connection was dropped. This makes for a more stable environment.

For this parameter to have any effect, AUTO.VLM must be loaded and `AUTO RECONNECT` must be set to `ON`.

`CACHE BUFFER SIZE`. FIO.VLM uses memory buffers to cache data being read from or written to network files. This can significantly increase I/O performance. Files that are flagged `Shareable` or `Transactional` are not included; the file may be in use on the server while the workstation is still using its cached copy. The default buffer size is 64 bytes less than the maximum packet size for the network media--if your network uses Ethernet, then the buffer size defaults to 1,436 bytes. Increasing this value uses more memory but can enhance workstation performance.

Valid buffer sizes are from 64 bytes to 4,096 bytes. For example, the line

    CACHE BUFFER SIZE = 4096

should increase performance, but at a cost of 2,660 bytes.

> CAUTION: Don't set `CACHE BUFFER SIZE to be` greater than the maximum packet size that can be handled by the workstation's adapter. Check your adapter documentation before deciding on a setting.

`CACHE BUFFERS`. As explained above concerning `CACHE BUFFER SIZE`, FIO.VLM uses memory buffers to cache network file reads and writes. It uses one buffer per cached file. The number of buffers created at VLM load time defaults to five, and can be set to any number between zero and 64. Remember that the maximum number of files that the workstation can have open is set using the `FILES=` statement in CONFIG.SYS. Large numbers of cache buffers might not make sense if they approach the `FILES` setting: There is no point in setting aside 40 cache buffers if the workstation can only have 30 files open at a time. Keep the number of cache buffers at least five below the `FILES=` setting in CONFIG.SYS.

Consider the following example:

    CACHE BUFFERS = 20

This allows 15 files more than the default to be cached. Assuming the default cache buffer size for Ethernet of 1,436 bytes, this enhanced caching uses an additional 21,540 bytes (roughly 21K) of memory. The increase in performance should be significant, especially if the workstation is doing a lot of sequential reading from or writing to files on the network.

> TIP: If you carry out workstation-based backups of your server, increase the number and size of cache buffers on the backup workstation.

`CACHE WRITES`. Write caching--storing data in a local cache before sending it over the network--is a useful trick for increasing efficiency and boosting performance. So is read caching, where data is read from the server and transmitted over the network in one big chunk before being stored in the workstation's cache. There is, however, a major difference between the two in terms of robustness. If read caching is in operation and the server goes down, there is no data loss. Whatever was in the workstation's cache is still there; assuming the server is unharmed, the data is still stored on its disk. The same cannot be said of write caching. If an application on a workstation writes data to a cache, there is an assumption that the cache will be written to disk at some stage in the near future. If the server goes down before the contents of the cache are written to disk, then the data probably is irretrievably lost.

This is similar to having SmartDrive perform write caching on a local hard disk. If you save data from an application to a cached file, and then power off the machine before SmartDrive has a chance to commit the data to disk, the data is lost.

FIO.VLM implements write caching as well as read caching by default. You can turn write caching off by using the following line:

    CACHE WRITES = OFF

This way, you lack the performance benefits of buffered writes to the server but also reduce the risk of losing data between the cache and the server. Unless you absolutely need the higher write speed, protect your data by turning cache writes off.

`CHECKSUM`. IPX packets can carry a checksum that allows the recipient to verify that they were received as they were transmitted. This feature improves data integrity but adds some performance overhead because the checksums must be calculated by both sender and recipient. By default, IPXNCP.VLM only uses checksums when the recipient insists on them. You can alter this behavior by changing the `CHECKSUM` setting, using the following possible values:

0 | Don't do checksums
1 | Do checksums if the recipient insists
2 | Do checksums if the recipient can do them
3 | Insist on checksums

For example, the line

    CHECKSUM = 2

gets the workstation to use IPX checksums as much as possible without actually refusing to talk to stations that do not support it.

`CONFIRM CRITICAL ERROR ACTION`. Windows responds to many critical network errors either quietly or by displaying a dialog box with the message `Cannot read from device network`. The user then selects Cancel or Retry. If the user selects Cancel, VLM attempts to rebuild the lost connection. By default, VLM displays a dialog box before it tries to recover lost connections. This dialog box shows the name of the server affected and asks the user to confirm that she wants to reconnect. The line

    CONFIRM CRITICAL ERROR ACTION = OFF

turns off these dialog boxes. Windows then responds to critical errors itself, without awaiting confirmation from the user.

`CONNECTIONS`. CONN.VLM maintains just eight connections by default. You can change that to as few as two or as many as 50. Increasing the value costs memory, as explained in the earlier discussion of `AVERAGE NAME LENGTH`. Here's an example of a valid `CONNECTIONS` entry:

    CONNECTIONS = 10

This allows two connections more than the default.

`DOS NAME`. Workstations that run DOS from the server need a search mapping to the DOS drive. This can be set up in the logon script using the `%OS` variable. VLM automatically detects MS DOS and DR DOS; if you want to override its automatic detection, or if you're using another OS, use `DOS NAME`. For example, the line

    DOS NAME = MSDOS

forces the replacement of `%OS` with `MSDOS` in the logon script.

`EOJ`. Some applications close all files and locks that they have used, by issuing a special DOS interrupt that issues End of Job (EOJ) commands. An EOJ command sent to the server closes any files that the application has had open. The simple line

    EOJ = OFF

tells the workstation not to send EOJ commands to the file server.

`EXCLUDE VLM`. VLM.EXE loads the VLMs listed later (see the "`USE DEFAULTS`" section) unless they are not in the VLM directory or are explicitly excluded using `EXCLUDE VLM`. For example, the line

    EXCLUDE VLM PRINT.VLM

tells VLM.EXE not to load support for printer redirection.

`FIRST NETWORK DRIVE`. When the workstation establishes its initial connection to a file server, it maps the first available drive letter to the logon area on the server, unless told otherwise. A workstation with a hard disk (drive C) and no drive letters in use after that gets drive D as its first network drive. You can override this by using `FIRST NETWORK DRIVE`.

    FIRST NETWORK DRIVE = F

forces VLM to map `F` to the logon area rather than `D`. Drive D is still available for mapping.

`FORCE FIRST NETWORK DRIVE`. If your default drive when you log off from a server is a network drive, then the drive letter it uses is remapped to `SYS:LOGIN`. Thus, if your current directory is `R:DATA` when you issue the LOGOUT command, it changes to `R:\`, which then is mapped to `SYS:LOGIN`. More consistent behavior is produced by using the following setting:

    FORCE FIRST NETWORK DRIVE = ON

This way, when you log off from a network drive, that drive mapping is lost, the first network drive used when the initial connection was made is remapped to `SYS:LOGIN`, and that drive becomes your default drive. For example, if your current directory is `R:DATA` when you issue the LOGOUT command, and F was your first network drive, then your current directory changes to `F:\`, which is mapped to `SYS:LOGIN`.

`LARGE INTERNET PACKETS`. NetWare packets crossing bridges or routers used to be limited to 576 bytes. Ethernet and Token Ring both can handle much larger packets than this, so in most cases you can allow a workstation and server to communicate across bridges and routers using the maximum packet size negotiated by them for local area communications. If you experience difficulty passing larger packets across a bridge or router, you can restrict the internetwork packet size to 576 bytes by using the following line:

    LARGE INTERNET PACKETS = OFF

`LIP START SIZE`. The client and server negotiate a maximum packet size when they first make contact. The size they finally agree on depends upon a number of factors, including network topology. The negotiation process can take a noticeable amount of time if the link is very slow. If you know in advance what the size is likely to be, then you can speed up the negotiations a bit by using a line like the following:

    LIP START SIZE = 12000

This example tells the workstation to begin internetwork packet size negotiations at 12,000 characters. Novell reports that, in some cases, specifying a suitable LIP START SIZE parameter can reduce the amount of negotiation traffic from 60K to approximately 3K. This can mean a significant speedup in establishing a connection over a slow link.

`LOAD CONN TABLE LOW`. The connection table usually is loaded into an upper memory block, if one is available. You can force VLM.EXE to load the connection table in conventional memory by using the following option:

    LOAD CONN TABLE LOW = ON

`LOAD LOW CONN/FIO/IPXNCP/NETX/REDIR`. VLM.EXE normally loads CONN.VLM and IPXNCP.VLM into conventional memory and FIO.VLM, NETX.VLM, and REDIR.VLM into upper memory, if suitable upper memory blocks are available at VLM load time. You can override this behavior in all cases by using the following option:

    LOAD LOW CONN = OFF

This forces VLM.EXE to attempt to load CONN.VLM into upper memory.

You need to do a certain amount of experimentation with these VLMs to see which combination of low and high loading gives the best combination of performance and memory use for your needs. The optimum depends on your requirements as well as on the workstation hardware and memory configuration.

> TIP: Load REDIR.VLM into conventional memory unless you absolutely cannot spare the conventional memory. The performance gain from loading REDIR low is significant.

`LOCAL PRINTERS`. The BIOS assumes that there is a printer attached to each parallel port, unless told otherwise. You can use `LOCAL PRINTERS` to tell it otherwise:

    LOCAL PRINTERS = 0

This really doesn't have much to do with NetWare. It was introduced to SHELL.CFG--a precursor of NET.CFG that was used by older versions of NETX--as a convenient way to stop workstations from hanging if the Shift+PrintScreen key combination was pressed when no printer was attached.

`LONG MACHINE TYPE`. You might need to refer to the machine type in the system logon script using the `%MACHINE` variable. Use this option to force the VLM to give a particular response when the machine type is queried. For example, the line

    LONG MACHINE TYPE = COMPAQ

forces the replacement of `%MACHINE` with `COMPAQ` in the logon script.

`MAX TASKS`. CONN.VLM needs to keep track of each task running in a multitasking or task-switching environment such as Windows. CONN.VLM allocates space for a fixed number of tasks at VLM load time (the default is 31). Increase or decrease this number to any value from 5 through 254 by using `MAX TASKS`. For example, the line

    MAX TASKS = 100

forces CONN.VLM to allocate enough memory and handles to keep track of as many as 100 tasks.

`MESSAGE LEVEL`. In keeping with the general emphasis on customizability, VLM.EXE can be either very verbose or very quiet about what it is doing when it loads VLMs. The levels of verbosity are selected through `MESSAGE LEVEL` as follows:

0 | Display copyright information and report critical errors
1 | Level 0 and display warning messages (this is the default)
2 | Level 1 and display VLM program load information
3 | Level 2 and display configuration information
4 | Level 3 and display diagnostic information

You might want to turn up the level while debugging the VLMs by using a line such as the following:

    MESSAGE LEVEL = 4

`MESSAGE TIMEOUT`. Messages displayed on-screen usually stay there until the user presses Ctrl+Enter (DOS) or clicks OK (Windows). You can specify a time interval after which messages are automatically cleared from the screen. The time is expressed in CPU ticks, up to a maximum of 10,000 ticks. For example, the line

    MESSAGE TIMEOUT = 1000

establishes that any messages still on-screen a minute or so after they first appeared will be cleared.

`MINIMUM TIME TO NET`. A router may decide on a timeout value for connections on the basis of local area conditions. This value might be inappropriate for wide area connections where the connection would take considerably longer. If, for example, a user is dialing in to a network using a slow modem and then traversing a bridge or router to get to a server, you might need to specify a relatively large time to allow them to establish their connection. For example, the line

    MINIMUM TIME TO NET = 3000

gives the user three seconds (3,000 milliseconds) to establish the connection.

`NAME CONTEXT`. You can specify your starting point in the directory tree when connecting to a NetWare 4 network. Here's an example:

    NAME CONTEXT = "OU=home.O=groceries"

The quotation marks are required to facilitate parsing the name.

`NETWARE PROTOCOL`. VLM.EXE by default loads NDS.VLM, BIND.VLM, and PNW.VLM--in that order. If any of these files are absent from the VLM directory, or if they explicitly have been excluded from loading using the `EXCLUDE VLM` option, then the others are loaded. You can change the combination of NetWare protocols used by VLM or the sequence in which they are loaded, using `NETWARE PROTOCOL`. For example, the line

    NETWARE PROTOCOL Bind, NDS

tells VLM.EXE to load the Bindery mode protocol first and then the NDS protocol. Personal NetWare is not loaded.

> NOTE: If `NETWARE PROTOCOL` is used, it must appear as the first line in the `NetWare DOS Requester` section of NET.CFG.

`NETWORK PRINTERS`. NetWare by default allows you to capture three printer ports. You can capture as many as nine by using a line such as the following:

    NETWORK PRINTERS = 9

There is, however, a slight increase in memory use if you do so.

You can also turn off printer redirection, with the following line:

    NETWORK PRINTERS = 0

This prevents PRINT.VLM from loading.

`PB BUFFERS`. The DOS requester uses packet burst to transmit data on the network in efficient, large chunks. You can turn off this behavior, with the following line:

    PB BUFFERS = 0

This might result, however, in a significant decrease in workstation performance.

All non-zero values on this line have the same effect--packet burst is enabled. The number of buffers and their size are set using `CACHE BUFFERS` and `CACHE BUFFER SIZE` as described earlier.

`PREFERRED SERVER`. VLM using the NetWare Bindery protocol attaches to the first server to respond to a `GET NEAREST SERVER` request, unless it is told to attach to a specific server. For example, the line

    PREFERRED SERVER = INDIE

tells BIND.VLM to try to attach to `INDIE` when it loads. If `INDIE` has a free connection slot, then the workstation attaches to it; if not, the workstation attaches to the first server to respond to a `GET NEAREST SERVER` request.

> NOTE:`PREFERRED SERVER` has no effect if `PREFERRED TREE` is also specified and NDS establishes its connection first.

`PREFERRED TREE`. VLM using the NetWare Directory Services protocol attaches to the nearest tree that contains a user object for the user who is attaching. For example, the line

    PREFERRED TREE = DISTRIB

tells NDS.VLM to try to attach to `DISTRIB` when it loads. If `DISTRIB` has a server with a free connection slot, then the workstation attaches to it; if not, the workstation attaches to the nearest tree that contains a user object for the user who is attaching.

> NOTE:`PREFERRED TREE` has no effect if `PREFERRED SERVER` is also specified and BIND establishes its connection first.

`PRINT BUFFER SIZE`. Some applications print one byte at a time, leading to slow print throughput. VLM maintains a print buffer to improve the efficiency of such printing. The default buffer size is 64 bytes, but you can set this to any size from 0 through 255 bytes. A line such as

    PRINT BUFFER SIZE = 100

provides only a tiny amount of extra memory, but this can give a noticeable improvement in printing speed.

`PRINT HEADER/TAIL`. Print header information is stored in a buffer that has a default size of 64 bytes. If you generate printouts with large headers--due to specifying a lot of print options, font changes, or the like--then 64 bytes might not be enough, and the printer might not initialize as you instruct it to. In such cases, you should increase the print buffer size, using a line like the following:

    PRINT HEADER 512

The maximum size for the print header is 1,024 bytes.

The same theory applies to the print tail, which can contain instructions for the printer to reinitialize or eject a page after the job has been printed. If the behavior is not what you instructed, try increasing the print tail buffer size from its default of 16 bytes:

    PRINT TAIL 256

The maximum print tail size is also 1,024 bytes.

`READ ONLY COMPATIBILITY`. When an application opens a file, it signals to DOS whether it is opening the file for reading, writing, or both. Some applications insist on opening files for writing when they do not actually need to write to them. This is not a problem on a stand-alone machine where the user generally has write access to all files but can cause problems with applications run from a server. On a server, the user probably doesn't have write access to application files and doesn't really need to write anything to the files, but an application might still try to open them for writing. Whether the application succeeds in opening the files in write mode (without write access) depends on the network client software on the workstation. Older versions of the NetWare shell allowed the application to open the files for writing. Attempting to actually write to the files caused an error. More recent versions of NETX are compatible with DOS in that they do not allow a read-only file to be opened for writing.

You can tell the requester to use either approach with such applications. The default behavior is to be strict and disallow opening read-only files with write access. The following line causes the requester to allow such unorthodox accesses:

    READ ONLY COMPATIBILITY = ON

`SET STATION TIME`. The workstation sets its time to the server's time when it makes its initial attachment. That's all very well if your server has a radio clock and is accurate to a fraction of a second; if it isn't, your users might complain about the time on their workstations being incorrect. The following line tells VLM.EXE not to synchronize the workstation time with the server:

    SET STATION TIME = OFF

`SHORT MACHINE TYPE`. Novell uses a series of machine type-specific overlay files for its standard menu-based utilities. It loads IBM$RUN.OVL for certain purposes on IBM machines and CPQ$RUN.OVL for the same purposes on Compaq machines. Even if VLM cannot identify your machine type, you can force the issue. For example, the following line identifies your workstation as being an IBM PC or compatible:

    SHORT MACHINE TYPE = IBM

`SHOW DOTS`. DOS has directory entries for the current and parent directories (. and .. respectively). NetWare does not have these entries by default but can display them in directory listings if you use the following line:

    SHOW DOTS = ON

> TIP: Turning the dots on makes it much easier to use Windows file and directory dialog boxes.

`SIGNATURE LEVEL`. You can trade performance for security by using packet signatures. The packet signature options are

0 | Don't sign packets
1 | Sign packets if the server insists
2 | Sign packets if the server can deal with signed packets
3 | Sign all packets and insist on signed packets

Depending on the level of security selected, workstations and servers can be limited to reading only the packets that are addressed to them. The following line configures your workstation for the highest level of security:

    SIGNATURE LEVEL = 3

> NOTE: To use packet signatures, network servers must also be configured for an appropriate level of security. This is done using `SET` commands from the file server console.

`USE DEFAULTS`. If you want to override the default VLM load order (see the following section), you can do so using the `VLM=` option. If you do so, and if you specify the names of any of the standard VLMs listed in the following section, use the following command to avoid error messages about attempting to load VLMs twice:

    USE DEFAULTS = NO

`VLM`. The default load order for VLMs is as follows:

  1. CONN.VLM
  2. IPXNCP.VLM
  3. TRAN.VLM
  4. SECURITY.VLM
  5. NDS.VLM
  6. BIND.VLM
  7. NWP.VLM
  8. FIO.VLM
  9. GENERAL.VLM
  10. REDIR.VLM
  11. PRINT.VLM
  12. NETX.VLM

If you want to load a VLM that is not in this list, you must force VLM.EXE to load it. Here's an example of the `VLM=` line that does this:

    VLM=C:\NWCLIENT\AUTO.VLM

You can specify as many as 50 VLMs to load here, but each must be specified on a separate line, with its own `VLM=` statement. All VLMs listed in this manner are loaded after the defaults. If you want to modify the load order of the default VLMs, you must disable the default load and specify each VLM individually--in the order that you want them to load.

## Summary

As the years have passed, the NetWare clients have become increasingly complex, but they are also far more flexible now--and more easily configured, as well. Their primary burden on the workstation, which is their use of conventional memory, has been eased by the improved memory handling capabilities of the VLM requester and by the modu-larization of the client into several pieces, which can be more easily shoehorned into small upper memory areas.

Performance has improved, as well. You can configure the client to suit the needs of your network by trading off speed for security, if necessary, or by eliminating unneeded VLM modules from the requester. Novell has a version of its Client32 currently in development for the DOS/Windows workstation, which will probably replace the VLM client before long; however, considering the age of the NetWare operating system, the number of revisions undergone by the client seems, in hindsight, to be remarkably few.

© Copyright, Macmillan Computer Publishing. All rights reserved.