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.
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.
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:
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:
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.
| 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:
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:
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:
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.
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:
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.
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.
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.
| 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.
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.
| 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.
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:
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.
(top level)
VLMDRVS
NTSWD
READMES
STANDARD
VXDS
(top level)
NWDLL
OLDDLLS
[boot] network.drv=netware.drv [386Enh] network=*vnetbios,vnetware.386,vipx.386 TimerCriticalSection=10000
load=NWPOPUP.EXE
load=SCHED.EXE,NWPOPUP.EXE
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
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.
(top level)
ODIDRV
VLMS
LSL.COM
LSL.MSG
IPXODI.COM
IPXODI.MSG
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:
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:
LASTDRIVE = Z
FILES = 100
First Network Drive = F
F:\LOGIN>
F:\>
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.
| 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) |
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.
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.
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.
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.
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 entries fall into a number of categories:
The following sections look at these categories in detail.
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.
| 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:
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:
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.
| 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
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.
| 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.
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.
| 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
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.
| 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 | |
| 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 | |
| PB BUFFERS = | 1 | Number | FIO, IPXNCP |
| PREFERRED SERVER = | -- | Name | BIND |
| PREFERRED TREE = | -- | Name | NDS |
| PRINT BUFFER SIZE = | 64 | Number | |
| PRINT HEADER = | 64 | Number | |
| PRINT TAIL = | 16 | Number | |
| 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 |
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:
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.
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.