Using the NetWare DOS Requester with NetWare 4.0
Articles and Tips: article
Senior Technical Editor
Systems Research Department
01 Apr 1993
NetWare 4.0 introduces new DOS client software known as the NetWare DOS Requester. The DOS Requester takes the place of NETX.COM and offers a more flexible interface into NetWare 4.0, as well as NetWare 3.x and below. This AppNote explains how the DOS Requester works and what the different Virtual Loadable Modules (VLMs) do. It also tells how to install and configure the DOS Requester, and how to login to a NetWare 4.0 network.
- Introduction
- Architecture of the NetWare Shell
- How the DOS Requester Works
- Installing the DOS Requester
- The NET.CFG Parameters
- Setting Up to Access Specific Services
- Logging In and Using the Client Utilities
- New NET.CFG Parameters
Introduction
With the release of NetWare 4.0, Novell introduced new NetWare DOS client software known as the DOS Requester. The DOS Requester takes the place of the NETX.COM shell and offers a more flexible interface into NetWare 4.0 as well as NetWare 3.x and below.
This AppNote first explains how the DOS Requester works and what the different Virtual Loadable Modules (VLMs) do. It then tells how to install and configure the DOS Requester, using parameters in the NET.CFG file. It ends with a discussion of how to log in to a NetWare 4.0 network and use some of the new client utilities.
To understand the difference between the DOS Requester and the NetWare shell, we first need to review the architecture and function of each.
Architecture of the NetWare Shell
The NetWare Shell (NETX.COM) acts as an intermediary between application requests and DOS or the network. When the NetWare shell is loaded on a workstation, the shell intercepts activities on certain interrupts that applications use to talk to DOS services. These include Interrupts 21h, 24h, and 17h.
To read a data file, for example, an application makes an Int 21h call to DOS to open a file with the indicated name. The NetWare shell intercepts the call and determines if the requested file is on a local drive or on a network drive.
If the request is for a local file, the shell passes the call to DOS and allows DOS to complete the request.
If the file is on a network drive, the request goes through the shell's connection table, which defines information about the server and its location on the network. The shell then converts the request from a DOS request to an NCP request, and the network location information is used to build an IPX packet. IPX takes this packet and sends the request to the server. When the server sends a reply, the shell hands the data back to the application.
Figure 1 illustrates how the NetWare shell passes information between applications, DOS, and the network.
To keep track of attached file servers and their respective network drives, the shell maintains a number of internal tables: the Drive Connection ID table, the Drive Flag table, the Drive Handle table, the File Server Name table, and so forth. These tables are similar to tables that DOS keeps.
Figure 1: The NetWare shell intercepts application requests and determines whether they are for DOS or for the network.
When you log in to a file server, the shell stores the login information and drive mappings that come from the execution of system and user login scripts. The shell places the drive information into the Drive Connection ID table, Drive Flag table, and Drive Handle tables. These drive mappings are used to help designate where a DOS request needs to go. The NetWare shell supports up to eight server connections, so drive mappings can be to any of eight different servers.
How the DOS Requester Works
The DOS Requester is a collection of individual modules that encompass much of the functionality that exists in NETX.COM and add other capabilities as well. The DOS Requester works with DOS versions 3.1 or greater. Figure 2 illustrates the modular architecture of the DOS Requester.
The first DOS Requester module loaded is called VLM.EXE, the Virtual Loadable Module memory and module manager. It manages the memory usage of other Requester modules and provides a function call interface to control when a module is mapped into accessible memory.
Note: VLM.EXE is actually a terminate-and-stay-resident (TSR) program manager. Any TSR written to the VLM specification can use VLM.EXE to manage it.
Figure 2: The NetWare DOS Requester consists of numerous modules which provide various network services.
VLM.EXE contains a default list of VLMs to load, ranked in the order they are used for a NetWare 4.0 client using Directory Services. This includes initially loading VLM.EXE, which then manages the loading of other modules in the following order:
|
Filename |
Module |
|
CONN.VLM |
Connection Table Manager |
|
IPXNCP.VLM |
IPX/NCP Transport Module |
|
TRAN.VLM |
Transport Protocol Multiplexor |
|
SECURITY.VLM |
Enhanced Security Module |
|
NDS.VLM |
NetWare Directory Services |
|
BIND.VLM |
Bindery Services |
|
NWP.VLM |
NetWare Protocol Multiplexor |
|
FIO.VLM |
File Input/Output Module |
|
GENERAL.VLM |
General Functions Module |
|
REDIR.VLM |
DOS Redirector Module |
|
PRINT.VLM |
Printer Redirection Module |
|
NETX.VLM |
NetWare Shell Compatibility |
Types of VLM Modules
There are two types of VLM modules: multiplexors that coordinate activities with specific child modules, and modules that perform specific tasks for the workstation. As shown in Figure 2, certain modules work in relation with one another, while other modules span all levels of activity.
The multiplexors include NWP.VLM and TRAN.VLM. NWP.VLM works with the child modules that control access to Directory Services (the NDS.VLM module) and Bindery Services (the BIND.VLM). The NWP module ensures that information going to a specific service is properly routed to that service.
Note: Child modules are loaded before the multiplexor modules, and the first loaded child module becomes the default. Thus if you load NDS.VLM before BIND.VLM, your default becomes Directory Services.
The TRAN.VLM module coordinates the routing between the different transport protocols you can have loaded. Initially, the only protocol supported in NetWare 4.0 is IPX through the IPXNCP.VLM module. Since there is currently only one transport module, the protocol multiplexor is not needed. The TRAN.VLM module sets up a masquerade which allows IPXNCP.VLM to provide TRAN.VLM services directly.
Each type of module performs a specific service. Invoking some of them can affect overall workstation performance. (We'll discuss performance issues under the "NET.CFG Performance Parameters" heading later in this AppNote.)
What the DOS Requester Modules Do
Following is a brief summary of each of the DOS Requester modules.
VLM.EXE. This is the VLM manager for the DOS Requester. VLM.EXE directs incoming requests and outgoing replies through every stage of the DOS Requester. It oversees where the VLM modules are loaded into memory and in what order they are initially loaded.
Having loaded the VLM modules, VLM.EXE then directs each step of requests to their proper destination. Other application vendors may also write VLM modules that can plug into the VLM manager for use as extended resources to the client workstation.
CONN.VLM. The Connection Table Manager is a critical piece of the DOS Requester which spans all three layers shown in Figure 2. CONN.VLM keeps track of and allocates the number of connections the DOS Requester can have (between 2 and 50), and presents connection table information to other module tasks. The CONN.VLM module can also supply APIs for statistics and for checking the validity of a connection handle.
The DOS Requester can support a configurable number of connections (up to 50), whereas the NetWare shell is limited to eight. You should normally stay with the default of eight to provide the most compatibility with utilities that come with NetWare 3.x and below, as well as with third-party applications that use NETX.COM services.
REDIR.VLM. This is the DOS Redirector portion of the VLM architecture. The DOS Requester now takes advantage of DOS's Int 2Fh redirection capabilities and DOS internal tables. This allows NetWare to handle requests for DOS that DOS can't perform locally. This capability became available in MS-DOS and PC-DOS version 3.1. Incorporating this feature in the DOS Requester reduces a lot of redundancy between NetWare and DOS.
GENERAL.VLM. This module contains a number of functions used for other modules, such as creating and deleting search drive mappings, getting connection information, last print queue and server information, search modes, and long and short machine names.
NETX.VLM. This module is used in conjunction with Bindery Services to ensure compatibility with the utilities that come with NetWare 3.x and below. You'll also need to load NETX.VLM if you have applications that are written to take advantage of the NetWare shell's specific API functionality.
However, if you are running on NetWare 4.0 servers only, or if you only access certain applications on NetWare 3.x and below servers without using their utilities, you don't need to load the NETX.VLM. By not using this module, you reduce memory requirements and can improve performance because there is one less module in the request/reply chain.
TRAN.VLM. This is the transport protocol multiplexor, as explained earlier. The NetWare DOS Requester initially comes with the IPXNCP module for using IPX. Other protocols are planned for future releases.
IPXNCP.VLM. The IPXNCP transport module is a child process module of TRAN.VLM. It is not a replacement for the IPX communications drivers (IPXODI.COM or IPX.COM). The IPXNCP module takes care of building packets with a proper NCP header and so forth, and hands the packets to the IPX protocol for transmission over the cable.
NWP.VLM. This NetWare protocol multiplexor module coordinates requests to the right network module. The NWP module will connect to the available services, perform logins and logouts, and handle broadcasts through its child modules.
NDS.VLM and BIND.VLM. The NetWare DOS Requester come with two network service modules: the NDS.VLM module for NetWare 4.0 Directory Services, and the BIND.VLM module for Bindery services found in NetWare 3.x and earlier. You can load one or both of these modules.
FIO.VLM. This is the DOS Requester's File Input/Output module, which is used when accessing files on the network. This module incorporates the File Cache, Packet Burst, and Large Internet Packets capabilities.
PRINT.VLM. This module takes care of printer redirection capabilities for both Directory Services and Bindery Services. The print module also uses FIO.VLM to speed up printing services.
NMR.VLM. This is the NetWare Management Responder module. It is designed to load at the same time as the DOS Requester modules, but it isn't really a part of the DOS Requester. The NMR module uses the VLM.EXE's memory management capabilities to load into memory and provide diagnostic capabilities.
When loaded, the NMR.VLM module acts as a workstation agent compatible with Novell's Windows and OS/2 Network Management Responder. The module gathers and communicates workstation configuration information and statistics, as well as ODI information and statistics.
SECURITY.VLM. This module is used for NetWare's enhanced security feature and provides additional security as needed. The SECURITY.VLM module resides at the transport layer of the DOS Requester, and offers additional NCP session protection through a message digest algorithm. The first several bytes in a request packet are proceeded by this digest algorithm. If you use this for security reasons, you may see performance degradation.
AUTO.VLM. The Auto- reconnect module reestablishes its connection with the server after it detects the loss of the NCP connection. As downed servers become available again, the AUTO.VLM module reconnects to the server and then rebuilds the user's environment, including connection status, drive mappings, and printer connections. Open files are restored, which means your recovery from the connection loss depends on how the application you were running recovers from a connection loss and reestablishment.
AUTO.VLM currently works only with NetWare 4.0's Directory Services. In the future, it will work with Bindery Services in NetWare 3.x and below.
To load the module, you must specify VLM = AUTO.VLM in the NET.CFG file and load NDS.VLM. If you are using VLM.EXE's default module loading list, you only need to place VLM = AUTO.VLM somewhere under the "NetWare DOS Requester" heading in NET.CFG.
RSA.VLM. This module provides Novell's RSA encryption scheme for Directory Services. RSA authentication is one of the toughest forms of encryption protection on the market today. Currently, you need this module only for running AUTO.VLM with Directory Services.
Installing the DOS Requester
You install the DOS Requester from the WSDOS_1 diskette that comes with NetWare 4.0. However, the DOS Requester is not only for NetWare 4.0 users. Novell will make it available to everyone wishing to upgrade their client software. Because this is a NetWare 4.0 AppNote, we'll cover the installation process using the NetWare 4.0 Client Install program.
Note: The example installation shown is for an initial installation. If you already have the DOS Requester loaded and want to modify it, you may see different menu screens than those shown here.
The NetWare client software comes on four diskettes:
WSDOS_1, the installation diskette
WSDRV_1 and WSDRV_2, two ODI driver diskettes
WSWIN_1, a diskette containing Windows drivers
When you insert the WSDOS_1 diskette in a local drive and type "INSTALL <Enter<", you'll see the main menu screen shown in Figure 3. This single screen provides access to all five steps for installing the client software. The sections below summarize each step.
Step 1
The first step shows you the directory path where the installation program intends to install the VLM files, as well as the latest ODI drivers. By default, this is C:\NWCLIENT.
You can change the path by highlighting it and typing in the desired directory path name. However, if you are going to migrate numerous users to the DOS Requester, it's best to use the same directory name on all the workstations.
Figure 3: The DOS Requester Install program's initial screen.
Step 2
The second step discusses the changes that the installation process will make to the workstation's CONFIG.SYS and AUTOEXEC.BAT files:
For the CONFIG.SYS file, the LASTDRIVE entry will now be Z. Ifyou use a different drive letter other than Z, you won't have any search drive mappings.
For the AUTOEXEC.BAT file, the Install program adds a CALL STARTNET.BAT entry.
You can choose to make these changes yourself by accepting the default of No, or you can have the Install program do them for you by highlighting the No entry, typing Y and pressing <Enter<.
Step 3
The third step is to choose whether you want Windows support. If you would like Windows support, highlight the entry, type Y, and press <Enter<. You'll need to modify the Windows directory path if your path is not C:\WINDOWS.
Step 4
The fourth step allows you to update your network drivers to support ODI. ODI stands for Open Data-link Interface, and it allows a single network board to support multiple protocols. For example, you can have both IPX and TCP/IP protocols actively using an Ethernet network board, thus giving you access to NetWare through IPX and to UNIX through TCP/IP.
As mentioned above, the client software comes with two driver diskettes. When you choose Step 4 and insert one of the driver diskettes, you'll see a list of the different ODI drivers plus an option for Dedicated (Non-ODI) IPX.
If you don't want to install ODI, select the Dedicated (Non-ODI) IPX option, press <Escape<, then <Enter< to continue with Step<5. When you finish the installation process, copy the dedicated IPX.COM file into the NWCLIENT directory, or type in the correct directory path and file name in the STARTNET.BAT file.
To upgrade to ODI drivers in Step 4, select the driver that matches the workstation's network board. If none of the drivers match your board on this diskette, press <Escape<, then <Enter<, and then insert the second driver diskette and see if the driver is on that diskette.
You can also use the ODI drivers that come from the network board manufacturer. Simply press <Escape<, highlight Step 4, press <Enter<, and insert that diskette when Install asks for the driver diskette. If another driver's diskette is already inserted in the drive, remove that diskette and insert the proper diskette before pressing <Enter<.
Once you select the correct network board driver, the screen shown in Figure 4 appears. In this screen, you must match the interrupt, base I/O port, and memory I/O address to the network board settings.
Figure 4: Menu screen to select your network board settings for the DOS Requester.
If you don't know what these settings are, you can press Alt-F10 to leave the Install program, and type either "IPX -i <Enter<" or "IPXODI -I <Enter<" in the directory you load your NetWare drivers from. The -i parameter will display your present network board's configuration. (For ODI drivers, you can look in the NET.CFG file to see the board's settings.)
The third entry in the board setting window shows the "Media Frame Type(s)" that a protocol can use. This entry is of particular concern to long-time NetWare and Ethernet users, as an improper frame type selection can cause problems. NetWare initially used the Ethernet 802.3 frame type specification, which deviates slightly in its frame specification from the more widely-used 802.2 specification used by UNIX.
By selecting the Media Frame Type(s) entry, you'll see which frame types are available to you. Ethernet comes with the following choices:
Ethernet_802.2 Ethernet_802.3 Ethernet_II Ethernet_SNAP
For Token Ring, you have the following selections:
Token-Ring MSB Token-Ring LSB Token-Ring_SNAP MSB Token-Ring_SNAP LSB
Arcnet doesn't have any frame selections.
Choose the frame type you are presently running on your network; otherwise, workstations won't be able to find the servers. If you are upgrading from NetWare 3.x, you can easily find the frame type by typing CONFIG at the server console. CONFIG shows how each server network board is configured as well as the frame type (if one is specified).
On NetWare 2.2 and earlier, you can't specify a frame type, and Ethernet defaults to 802.3. Be sure to highlight the Media Frame Type(s) entry, press <Enter<, and select the proper frame type for your network. If you can't find out what your Ethernet frame type is, chances are it's 802.3, so change the Frame Type entry accordingly. This also applies to Token-Ring, which defaults to Token-Ring MSB.
Once you select the proper frame type, you can also specify an optional node address (according to the 802.2 specification). Since the driver defaults to the network board's node address, you don't need to choose this option.
When you are finished selecting the driver information, press <Escape< to go on to step 5.
Step 5
For the last step, press <Enter< to install your selections. The Install program copies the appropriate files into the directory specified in Step 1 (C:\NWCLIENT by default). If you chose to install Windows support, the Install program adds files to your Windows directory and makes some changes to the PROGMAN.INI and SYSTEM.INI files.
As you leave the Install program, it tells you to remove any lines used to load IPX or NETX from your AUTOEXEC.BAT file.
What the Install Program Modifies
CONFIG.SYS and AUTOEXEC.BAT. The only change to the CONFIG.SYS file is that the LASTDRIVE = entry now uses Z as its drive letter. If the entry is set to anything else, you won't be able to have any search drive mappings.
The only change to the AUTOEXEC.BAT file is the following line as the first in the file:
@CALL C:\NWCLIENT\STARTNET
This line ensures that the network is loaded before any menu program. However, loading the network first means you won't be able to unload the VLM at will if you load other TSRs after it.
Since these are the only changes Install makes to the CONFIG.SYS and AUTOEXEC.BAT files, you can answer No to Step 2 in the installation program and make your own changes to those files (such as putting the @CALL line to a more appropriate place).
The STARTNET.BAT File. Below is a sample STARTNET.BAT file created by the Install program:
@ECHO OFF C: CD \NWCLIENT SET NWLANGUAGE=ENGLISH LSL NE2000 IPXODI VLM CD \
The following variation takes advantage of MS-DOS's extended memory manager to load some of the modules high:
@ECHO OFF C: CD \NWCLIENT SET NWLANGUAGE=ENGLISH loadhigh LSL loadhigh NE2000 loadhigh IPXODI VLM CD \
In either example, the STARTNET.BAT file first changes to the C:\NWCLIENT directory, then sets the language for help screens to English. NetWare 4.0 supports different languages, allowing you to see NetWare utilities and help screens in your native language.
The next three entries - LSL, NE2000, and IPXODI, load the new IPX communications drivers. (If you choose dedicated IPX instead of ODI when installing, Install places a single IPX entry instead of these three.) The next entry loads VLM.EXE, thus loading the DOS Requester.
The NET.CFG File. As the ODI drivers load, the NET.CFG file is called. This file contains information about your network board settings. It may also contain a lot of other parameters used by VLM.EXE and its modules. Below are the settings created by the Install program for an NE2000 board:
LINK DRIVER NE2000 PORT 300 INT 3 FRAME Ethernet_802.3 MEM D0000 NetWare DOS Requester FIRST NETWORK DRIVE = F
The ODI drivers use indented entries under the "Link Driver" heading in the NET.CFG file. In this example, the NE2000 board is set to its default of I/O port 300h and Interrupt 3. You will also notice that the frame type is set to 802.3, which is what our network used because we migrated it from NetWare 3.11 to 4.0.
The next heading in the NET.CFG file is "NetWare DOS Requester." The installation program places only one entry here (since it uses VLM.EXE's default internal loading list). Entries that are specific to the NetWare DOS Requester are indented under this heading, while the more generic NET.CFG parameters don't need to be indented and can be placed anywhere in the file. It's easier to place all DOS Requester parameters indented under the "NetWare DOS Requester" heading than to worry about the correct protocol. (The DOS Requester picks them up if they are all indented.)
If you have particular default NET.CFG entries that you want in everybody's NET.CFG file, you can modify the INSTALL.CFG file on the Installation diskette (using any text editor). For example, to add SHOW DOTS=ON and CACHE BUFFERS=5 globally, bring up the INSTALL.CFG file in a text editor, go to the [NETCFG] heading, and type in the desired commands under the "NETWARE DOS REQUESTER" heading. From now on, whenever you install the DOS Requester using this Install diskette, these global parameters will appear in all newly created NET.CFG files.
Windows Files. If you allow the Install program to include Windows support, your PROGMAN.INI and SYSTEM.INI files will be modified (the originals are kept with a *.BNW extension). The changes you see here depend on the NetWare support you are currently using.
In PROGMAN.INI, Install adds a NWUTILS.GRP line to the [Groups] heading as first in the Order line. In the SYSTEM.INI file, it adds "NETWORK.DRV=Novell NetWare (4.0)" under the [Boot.Description] heading. The following lines are added under the [386Enh] heading if you are running Windows in Enhanced Mode:
network=*VNETBIOS,VNETWARE.386,VIPX.386,VCLIENT.386 UniqueDOSPSP=TRUE PSPIncrement=5 TimerCriticalSection=10000 ReflectDOSInt2A=TRUE
DOS Requester (VLM) Options
The DOS Requester comes with a number of options that you can use when it's loading or running. To see all of the options that are available, type "VLM ? <Enter<" at the network prompt. Figure 5 shows the list of options as it appears on the screen.
Figure 5: The VLM help screen.
VLM.EXE - NetWare virtual loadable module manager v1.0 (930210) (C) Copyright 1993 Novell, Inc. All Rights Reserved. Patent pending. Available command line options: /? Display this help screen. /U Unload the VLM.EXE file from memory /C=[path\]filename.ext Specify a configuration file to use (Default is NET.CFG). /Mx The memory type the VLM.EXE file uses where x is one of the following: C = Conventional memory. X = Extended memory (XMS). E = Expanded memory (EMS). /D Display the VLM.EXE file diagnostics. /PS=<server name> Preferred server name to attach to during load. /PT=<tree name> Preferred tree name to attach to during load. /Vx The detail level of message display where x is one of the following: 0 = Display copyright and critical errors only. 1 = Also display warning messages. 2 = Also display VLM module names. 3 = Also display configuration file parameters. 4 = Also display diagnostics messages.
Following is a brief description of each VLM option.
VLM /?. Use this option to see the help screen we are describing.
VLM /U. Use this option to unload VLM.EXE from memory. Be sure the DOS Requester is the last TSR loaded when you do this, or only load other TSRs that can be unloaded like the DOS Requester can.
The /U parameter makes it easy to try new configurations without having to reboot the workstation. You can modify the NET.CFG file to use other options, type "VLM /U" to unload the DOS Requester, and then retype VLM to try out the new settings.
VLM /C=. Use this option to specify the path to a NET.CFG file other than the one found in the directory where you normally load VLM.EXE. The syntax is:
VLM /C=<path\filename<
For example, if you want to use a NET.CFG file in the root directory of C rather than the one found in the NWCLIENT subdirectory, type "VLM /C=C:\NET.CFG <Enter<".
VLM /Mx and Memory. The DOS Requester is unique in how it loads into the workstation's memory. The DOS Requester uses extended (XMS) or expanded (EMS) memory that is allocated by the XMS or EMS Memory Managers (according to the LIM XMS 2.0 or LIM EMS 4.0 specification).
You can use memory managers to load TSRs into the upper memory block (UMB) area between 640KB and 1,024KB, and to load DOS or a different TSR into the high memory (HMA) area between 1,024KB and 1,088KB. Without this designation, DOS and TSRs load into conventional memory. (For more information on workstation memory, see "Managing Memory in a DOS Workstation: Part 1" in the August 1992 NetWare Application Notes.)
VLM /MX.
The DOS Requester automatically detects if an XMS Memory Manager is installed and then asks the manager to allocate extended memory for VLM.EXE and its modules. Use the VLM /MX option to ensure that the first place the DOS Requester tries to load is into extended memory. Once this memory is allocated, VLM.EXE and its modules load much of their code into the extended memory area designated by the memory manager.
An example of setting up the XMS memory manager for MS-DOS 5.0 and above includes the following in the CONFIG.SYS:
DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE NOEMS DOS=HIGH,UMB
Briefly, the HIMEM.SYS file loads the extended memory manager and the EMM386.EXE file allows you to use Upper Memory Blocks (UMBs) for loading TSRs between 640KB and 1,024KB. The NOEMS parameter prevents the expanded memory manager from loading.
The DOS=HIGH command places the DOS kernel into the High Memory Area (HMA) above 1,024KB, and the DOS=UMB command activates UMBs for TSR placementCthereby making UMBs available for the DOS Requester. (For more information on MS-DOS memory management, see "Managing Memory in a DOS Workstation: Using MS-DOS 5.0 and Windows 3.1" In the October 1992 NetWare Application Notes.)
For DR DOS 6.0, your settings will look similar to the following:
DEVICE=C:\DRDOS\EMM386.SYS /F=NONE /K=3072 /B=FFFF /R=AUTO HIBUFFERS=20 HIDOS=ON
Loading EMM386.SYS can set up the LIM memory manager for XMS (or EMS), but the /F(rame)=NONE parameter deactivates the expanded (EMS) memory manager. The EMM386.SYS file and the HIDOS=ON command allow you to load DOS into HMA, and the HIBUFFERS command loads buffers into HMA as well. Through the EMM386.SYS command, the UMB area is activated for the DOS Requester.
VLM /ME
If your workstation is using expanded memory (EMS) instead of extended memory, the DOS Requester can detect this and load VLM.EXE and its modules into expanded memory. Use the VLM /ME option to ensure that the first place the DOS Requester tries to load is into expanded memory. If you do not specify which memory manager you wish to use when you load VLM.EXE, XMS takes precedence over EMS.
A simple example of setting up the EMS memory manager for MS-DOS 5.0 and above includes the following in the CONFIG.SYS file:
DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE RAM I=D000-EFFF DOS=HIGH,UMB
In this example, the RAM parameter activates expanded memory and UMBs. The Include (I=) statement tells EMS to include the D000 to EFFF range for the EMS driver or RAM.
An example for DR DOS 6.0 looks similar to the following:
DEVICE=C:\DRDOS\EMM386.SYS /F=D000 /B=FFFF /R=AUTO HIBUFFERS=20 HIDOS=ON
Setting the /F(rame) parameter to AUTO allows the expanded memory manager to find and designate a 64KB window for EMS, and the D000 forces EMS to use allocate 64KB at that memory segment. (For more information about the different settings for EMM386.SYS, consult your DR DOS manual.)
The VLM footprint that stays in conventional memory can be as small as 4KB if you have XMS or EMS memory managers active and if you have enough UMBs available for loading VLM modules high.
Once EMS or XMS is in place, the DOS Requester then uses a small amount of conventional memory and/or the UMB area (according to how much upper memory is available). The DOS Requester allocates two blocks of memory in these areas: the transient swap block, and the global block.
VLM.EXE uses the transient swap block (about 8.5KB) to swap modules and data between conventional memory and extended or expanded memory. The global block is about 22KB in size and will also load into the upper memory area as space permits (see Figure 6).
Figure 6: Example of how VLM.EXE uses memory.
If there are enough upper memory blocks to hold these two memory blocks, you will see about a 3.5KB VLM footprint in conventional memory. If there isn't, you'll see more of the DOS Requester in conventional memory.
VLM /MC
You can use the VLM /MC option to ensure that the DOS Requester is loaded into conventional memory. Novell's DOS Client engineering team has worked hard to keep performance the same as if the DOS Requester is loaded into conventional memory. However, some network boards and slower computers may not see the same performance. The tradeoff in using conventional memory is the memory required by VLM.EXE and its modules.
For example, if you load VLM with just Bindery Services, you stand to lose about 58KB of conventional memory; with printing services added, it's about 63.5KB. If you load NetWare Directory Services as well as Bindery Services, VLM grows to about 68KB, or 74KB with printing services added.
VLM /PS=servername. The /PS= option allows you to specify which server you want to attach to when you initially log in. You can do the same thing by using the "PREFERRED SERVER = servername" parameter in the NET.CFG file.
This option is mainly for clients who log in to servers running NetWare 3.x and below, using the BIND.VLM module instead of the NDS module. While NetWare 4.0 clients can use a /PS setting, the shell will initially attach to the specified server, see that it is a 4.0 server, and default to the preferred tree setting (if any).
VLM /PT=treename. The /PT option allows you to specify which Directory tree you want to use when you initially log in. You can do the same thing by including the "PREFERRED TREE = treename" parameter in the NET.CFG file. This option is for NetWare 4.0 clients using the NDS module.
VLM /Vn. The /Vn parameter determines the level of message string verbosity you want to see when the DOS Requester initially loads. The possible values are listed below:
/V0 only shows you the copyright sign-on message and any critical errors that occur as the modules load.
/V1 (the default) adds any warning type messages as the modules load.
/V2 adds the module names as they load.
/V3 adds configuration information along with the module names. This includes the load order of the modules along with version date and code number, followed by the NET.CFG parameters you have set that are different than the parameter defaults.
/V4 displays diagnostic messages, which are different from the diagnostic information you see by typing VLM /D at the commandline.
If you include no /Vn verbosity parameter after VLM, VLM will look to the NET.CFG's "Message Level=" entry or to its default value of /V1.
Figure 7 shows an example of what you might see on the screen when the VLM message verbosity level is set to /V3.
Figure 7: An example of VLM loading with the /V3 message verbosity level parameter.
VLM.EXE - NetWare virtual loadable module manager v1.0 (930210) (C) Copyright 1993 Novell, Inc. All Rights Reserved. Patent pending. MESSAGE LEVEL 3 The VLM.EXE file is pre- initializing the VLMs........... The VLM.EXE file is using extended memory (XMS). CONN.VLM - NetWare connection table manager v1.0 (930210) CONNECTIONS 16 IPXNCP.VLM - NetWare IPX transport module v1.0 (930210) CHECKSUM 0 LARGE INTERNET PACKETS OFF TRAN.VLM - NetWare transport multiplexor module v1.0 (930210) BIND.VLM - NetWare bindery protocol module v1.0 (930210) PREFERRED SERVER SRD NWP.VLM - NetWare protocol multiplexor module v1.0 (930210) CHECKSUM 0 LARGE INTERNET PACKETS OFF SIGNATURE LEVEL 0 FIO.VLM - NetWare file input- output module v1.0 (930210) CACHE BUFFERS 5 PB BUFFERS 8 CONNECTIONS 16 GENERAL.VLM - NetWare general purpose function module v1.0 (930210) FIRST NETWORK DRIVE F SHOW DOTS ON REDIR.VLM - NetWare DOS redirector module v1.0 (930210) PRINT.VLM - NetWare printer redirection module v1.0 (930210) NETWORK PRINTERS 3 NETX.VLM - NetWare workstation shell module v4.0 (930210) FIRST NETWORK DRIVE F You are attached to server SRD
VLM /D. The /D option presents diagnostic information about the VLM's present running state. When you type "VLM /D" in the directory where you initially loaded VLM.EXE, you will see a screen similar to the one shown in Figure 8.
Figure 8: Example VLM /D display screen.
VLM.EXE - NetWare virtual loadable module manager v1.0 (930210) (C) Copyright 1993 Novell, Inc. All Rights Reserved. Patent pending. The VLM.EXE file v1.0 is currently loaded VLM transient switch count : 2405 VLM call count : 40901 VLM current ID : 0040h VLM memory type : XMS VLM modules loaded count : 11 VLM block ID (0 if CON) : A912h VLM transient block : 079Fh VLM global seg (0 if CON) : EB42h VLM async queue (h, t, s) : 0000:0000, 06BB:0030, 0 VLM busy queue (h, t, s) : 0000:0000, 06BB:003C, 0 VLM re- entrance level : 1 VLM full map count : 2403 VLM Control Block information Address TMemSize GMemSize SMemSize ID Flag Func Maps Call TSeg GSeg Low High Para K Para K Para K - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0001 A000 0005 0000 215B 06BB 073A FFFF FFFF 00F3 0003 0000 0000 0000 0000 0010 B000 0011 0000 5973 079F 0899 FFFF FFFF 00FA 0003 0000 0000 015B 0005 0021 B000 000B 0000 00E7 0899 0977 FFFF FFFF 00DE 0003 00A2 0002 0063 0001 0020 E000 000B 0001 0BF9 0899 0977 FFFF FFFF 00DE 0003 00A2 0002 0063 0001 0031 A000 0010 008D 005C EB42 0A19 0000 0000 00AD 0002 001A 0000 002B 0000 0032 A000 0010 0057 0036 EB42 0A33 0AD0 0000 0163 0005 00B9 0002 003E 0000 0030 A000 0011 0090 007A EB42 0AEC 2100 0000 00A9 0002 0071 0001 0048 0001 0041 A000 000B 00D9 071C EB42 0B5D 2B90 0000 01B8 0006 0162 0005 011D 0004 0043 A000 000A 017B 0083 EB42 0CBF 4710 0000 0077 0001 002E 0000 0050 0001 0040 A000 0009 0407 0A1F EB42 0CED 4E80 0000 0211 0008 005E 0001 0048 0001 0042 A000 000E 0088 0079 EB42 0D4B 6F90 0000 00D3 0003 00AC 0002 0059 0001 0050 A000 0007 010D 04AF EB42 0DF7 7CC0 0000 01CC 0007 00E2 0003 0079 0001 Total 0C63 0562 Maximum 0211 0162 015B
Most of this information is intended for use by programmers in debugging VLM modules, but supervisors can glean information from this diagnostic screen as well. The top of the diagnostic screen contains 12 lines of information, beginning with the VLM Transient Switch Count. These 12 lines are explained below.
VLM Transient Switch Count
This entry shows the number of times VLM.EXE swapped modules into the Transient switch block from expanded or extended memory. The entry correlates with the total from the Maps column under the "VLM Control Block Information" heading.
VLM Call Count
This count represents the total calls that are going on between the DOS Requester client and a resource. The VLM.EXE is the manager that interacts with every step of a request and keeps track of calls it makes to the various modules.
This number corresponds to the Call column under the "VLM Control Block Information" heading. The entries in the Call column show which VLM modules are used the most. For example, in Figure 8 VLM number 32 (which is the NDS module) is not being called very often. The BIND.VLM (number 31), the Transport layer, and Connection layer are being used more often.
The call number should roll over frequently under heavy usage.
All numbers in the VLM Control Block Information are in hex.
VLM Current ID
This entry shows which ID number from the ID column under the "VLM Control Block Information Heading" is currently mapped into the Transient Swap block area. For the above example, Current ID is 0040h (the REDIR.VLM module).
Here's a listing of the IDs given to VLM.EXE and the current VLM modules:
01 = VLM.EXE 34 = RSA.VLM 10 = CONN.VLM 40 = REDIR.VLM 20 = TRAN.VLM 41 = FIO.VLM 21 = IPXNCP.VLM 42 = PRINT.VLM 22 = TCPNCP.VLM 43 = GENERAL.VLM 30 = NWP.VLM 50 = NETX.VLM 31 = BIND.VLM 60 = AUTO.VLM 32 = NDS.VLM 61 = SECURITY.VLM 33 = PNW.VLM 100 = NMR.VLM
VLM Memory Type
This entry tells you the type of memory the VLM.EXE is using - XMS, EMS, or conventional memory. You can use this to ensure you are using the correct memory manager. If you thought you were loading the DOS Requester with a different memory manager than the one displayed, check your CONFIG.SYS file and modify it (if needed). Once you are sure you are loading the memory manager correctly, use the appropriate /Mx parameter when loading VLM.EXE.
If the workstation is using MS-DOS 5.0 or higher, your startup screen shows you if you are installing a memory manager. However, this does not mean you have correctly configured the memory manager to use Upper Memory Blocks (UMBs). To do this, make sure you have the following lines in your CONFIG.SYS file:
DEVICE=C:\DOS\HIMEM.SYS (use your directory path) DEVICE=C:\DOS\EMM386.EXE [options] (use your path) DOS=HIGH,UMB
While HIMEM.SYS loads the XMS memory manager, EMM386.EXE allows you to use UMBs (the area between 640KB and 1,024KB). You must also tell DOS to manage the UMB area by placing DOS=UMB in the CONFIG.SYS. The example DOS=HIGH,UMB simply puts both commands on one line.)
For DR DOS 6.0, you don't need to include the HIMEM.SYS line (DR DOS's EMM386 contains the XMS memory manager), but you do need to place the line HIDOS=ON to place DOS into HMA and activate the UMB area.
VLM Modules Loaded Count
This line lets you which VLMs have been loaded successfully. VLM.EXE's default listing loads 12 VLM modules, which are CONN.VLM, IPXNCP.VLM, TRAN.VLM, SECURITY.VLM, NDS.VLM, BIND.VLM, NWP.VLM, FIO.VLM, GENERAL.VLM, REDIR.VLM, PRINT.VLM, and NETX.VLM.
You may not want to use VLM.EXE's defaults to load modules you won't use. You can load extra modules through the NET.CFG file (such as the AUTO.VLM module). Since you can prevent some of VLM modules from loading, you can run VLM.EXE and look at the diagnostics screen to determine which modules the workstation is running. Once you know this, you can determine if your problem is caused by an unloaded module.
VLM Block ID (0 if CON)
This entry is for debugging purposes. The block ID is the enhanced memory handle allocated for the XMS or EMS memory managers. If you are loading the DOS Requester in conventional memory this number will be 0 (there isn't a handle associated with conventional memory).
VLM Transient Block
This entry points to the beginning of the transient block area, where transient memory is being swapped in and out. You can use the number you see to determine whether the VLM is loading high or not.
VLM Global Seg (0 if CON)
This entry is for debugging purposes and points to the beginning of the global memory block area. You can use this number to determine whether it is loading high. If you are loading the DOS Requester in conventional memory, this number will be 0.
In the above example, the transient block (VLM Transient Block) loaded in conventional memory (at 079Fh), while the global segment (VLM Global Seg) is loaded in upper memory (at EB42h). Numbers between 0000h and 9999h constitute conventional memory. Numbers between A000h and FFFFh constitute UMBs. Out of the 40KB that constitutes the working portion of the DOS Requester (depending on what VLMs you load), 12KB ended up in conventional memory (3.8KB for VLM.EXE and about 8.4KB for transient block) and 26KB loaded into extended memory.
For the transient block segment and the global memory block segment, they load either high or low - there is no splitting up the block segments. The DOS Requester tries to load transient and global high if possible. You can load VLM.EXE high as well (UMB space permitting).
VLM Async Queue (H, T, S) and VLM Busy Queue (H, T, S)
These two entries are for debugging purposes. The H, T, and S stand for the head, tail, and size. Normally, the tail points to the beginning of the list, so you should see 0 for the head, some address for the tail, and 0 for the size. If a request gets orphaned, the Size element increments and points to VLM.EXE's dequeuing mechanism, which should not happen.
VLM Re-entrance Level
This entry should generally be 1 and represents the same thing as the Async and Busy queue. The DOS Requester tries to ensure that when it performs a multi- leveled request, it comes out as deep as when it began to perform the request. If this is not the case, something is misbehaving and you may be having problems.
VLM Full Map Count
This is the number of VLM map out requests. Both the number you see here and the number you see in the VLM Transient Switch Count entry should be fairly close. If you load all your VLMs in conventional memory, this number should be 0. The Full Map Count means the DOS Requester is preserving VLM modules stored by the XMS memory manager.
In future releases of the DOS Requester, you may see other items added to this top list. This lists only the current items. The next portion of the DOS Requester diagnostic screen shows raw information. Briefly, here's the topic headings and their corresponding column headings.
VLM Control Block Information
This heading applies to the entire bottom portion of the diagnostic screen. Directly beneath this heading, you see seven column headings. These include ID, Flag, Func, Maps, Call, Tseg, and Gseg.
The ID column shows the different module's identification numbers as known internally to VLM.EXE. The present list of numbers is given under the VLM Current ID heading earlier in this AppNote.
The Flag column shows how a particular VLM module is flagged by the VLM.EXE. For example, A000 stands for valid and loaded, while B000 stands for valid, loaded, and loaded low. E000 stands for valid, loaded, and masqueraded (such as the multiplexor module TRAN.VLM that goes away because there is only one child module).
The Func column shows a count of the functions that are supported by the VLM, and has a direct correlation to the VLM's call-by-number interface for calling the VLM modules.
The Maps column shows how often each VLM module is being mapped into memory.
The Call column shows how often a particular VLM module is called to perform a task. Use this information to see how often particular VLM modules are used in your present configurations. If you have been tracking it over a long period of time and it's never used. You may want to remove this if it isn't a multiplexor module (or isn't necessary).
Depending on which file services you are not accessing (such as Directory Services or Bindery Services), you can remove SECURITY.VLM, NDS.VLM, BIND.VLM, AUTO.VLM, NETX.VLM, PRINT.VLM, and NMR.VLM (if they are not being used). However, at least one of the NDS.VLM or BIND.VLM modules must be loaded in order for VLM.EXE to work. (We'll discuss how to choose the VLM modules for the services you need later in this AppNote.)
The Tseg column shows the transient segment for the VLM modules, and the GSeg shows the global segment for the VLM modules.
Address Low/High
Near the middle of the screen is the Address heading and the Low/High columns. The Address heading columns show the enhanced memory location of the transient memory for VLM.EXE and loaded modules. Those loaded in FFFF are loaded in conventional memory, while the other modules are loaded in swapped enhanced memory. If you are using EMS, the Low column shows the EMS handle and the High column shows the logical EMS page. If you are using XMS, the Low/High columns show the relative D-Word address.
Next come three headings with two columns beneath each heading. The headings are TMemSize, GMemSize, and SMemSize. The columns include Para(graph) and K(iloBytes).
While the K column shows the memory sizes in K, the column is always rounded down to the nearest K rather than up. Therefore, if you have 1.9KB, you will see 1KB rather than 2KB. To get a more accurate number, use the formula in the next paragraph with the numbers in the Para column.
The number you see under the Para column of TMemSize, GMemSize, and SMemSize is the hexadecimal number in paragraphs and there are 16 bytes per paragraph. To see the actual size of the block in Bytes, change the number to decimal, then multiply the decimal number by 16. To get the actual size (in KiloBytes), multiply the Bytes by 1024.
TMemSize Para/K
TMemSize stands for the transient memory block size for each of the VLM modules loaded. For this memory block, the single largest VLM module loaded determines the actual size of the transient memory block. In this example, the largest VLM module is REDIR.VLM at 0211h, or 8,464 Bytes, or 8.26KB.
This number represents the size of the transient block that begins in memory as shown in the VLM Transient Block line (explained earlier). The 079Fh memory location on the VLM Transient Block line is going to be 0211h, or 8,464 Bytes (8.26KB) in size. Note that this number won't be exactly right if the transient memory block is loaded into conventional memory. For simple diagnostic purposes, total the numbers you see in the K column.
GMemSize Para/K
The GMemSize heading stands for Global Memory Size. To get the absolute size, you need to add the VLM modules together by looking at the number in the Total entry at the bottom. Then change the hexadecimal value to decimal, multiply by 16 for the Byte count, then by 1024 for the KiloByte count. The Total column should be accurate if no VLMs are loaded low (if the Address column Low/High does not equal FFFF FFFF). For simple diagnostic purposes, total the numbers you see in the K column.
SMemSize Para/K
The SMemSize heading stands for Start Memory Size and shows the number of start paragraphs there are for each of the VLM modules loaded. This is mainly for programmers and developers.
The NET.CFG Parameters
Up to now we have only mentioned in passing the NET.CFG file and its available parameters for setting up the DOS Requester. This section contains a list of all NET.CFG parameters for the DOS Requester and explains what they can do for you. (There are other NET.CFG parameters, for ODI and protocol stacks, that are not covered here.) For ease of discussion, we categorize the NET.CFG parameters in four groups:
Parameters that affect the DOS Requester's performance. Because performance parameters also affect memory requirements, we've subdivided this first group into parameters that affect performance only, and parameters that affect performance and memory.
The rest of the parameters that affect the overall memory size of the DOS Requester.
DOS Requester parameters that are specific to Directory Services and Bindery Services.
All other parameters that affect the DOS Requester.
Figure 9 summarizes which group the different NET.CFG parameters belong to.
Figure 9: NET.CFG parameters in their respective groupings.
The following list of NET.CFG parameters shows their default settings. If you use the default settings, you don't need to add the parameter entry to the NET.CFG file. If you do want a different setting, you must add the desired parameter entry to the NET.CFG file along with the setting change.
Group 1: Performance Parameters
A number of NET.CFG parameters affect overall network performance. However, some of these parameters also affect the memory size of the DOS Requester. Those that affect performance only include Checksum, Large Internet Packets, Cache Writes, and True Commit. Those that affect performance and memory include Load Low CONN, Load Low IPXNCP, Signature Level, Cache Buffers, Cache Buffer Size, PB Buffers, and Print Buffer Size.
Some of these parameters need to be indented under the "NetWare DOS Requester" header in the NET.CFG file. These include Load Low CONN, Load Low IPXNCP, Large Internet Packets, Cache Buffer Size, Cache Writes, True Commit, and Print Buffer Size. The rest can be placed anywhere in the NET.CFG file. To keep things simple, you can put them all under the "NetWare DOS Requester" header (and indent them).
Performance Only Parameters
CHECKSUM = 1. This is an IPX checksum, which occurs in addition to any other error checking your network board and driver may already be doing. The settings are:
0 for disabled
1 for enabled but not preferred (default)
2 for enabled and checksum preferred
3 for required
Because the checksum executes extra code, it can degrade your performance if it's used. To disable IPX checksumming, set this parameter to 0. But for compatibility's sake, you may want to leave it at 1.
This checksum works with all network protocols except Ethernet 802.3. If you are using Ethernet 802.3, the Requester will not use checksums, regardless of this setting.
LARGE INTERNET PACKETS = ON. The IPXNCP module uses this setting to allow internetwork packets larger than 512 bytes to pass through a bridge or a router that can handle larger packets. Leaving this to ON (the default) offers the best performance, especially for larger networks.
CACHE WRITES = ON. This parameter can provide a big performance gain when set to ON. Cache writes fills the local cache buffers before writing the data to the network, as opposed to writing it immediately to the network. This allows you to return a write success to be returned to the application more quickly, so you can get on with other work.
A workstation's data can be affected if the server goes down or runs out of disk space. In either instance, you'll lose the data in the cache. There are a number of client caches, such as Norton Cache or Super PC-Kwik, that have the same restriction. Before setting Cache Writes=On, make sure the server has sufficient disk space - that's the most common problem you'll have.
TRUE COMMIT = OFF. True Commit increases data integrity by waiting until the data is written to the server's disk, forcing a flush of the server's cache. With True Commit set to ON, the DOS Requester will cause the server to commit the data to disk. Databases perform this when they are not using NetWare's transaction tracking features, but still require guaranteed data storage.
On a NetWare 3.x or 4.0 server, True Commit=On will actually write data to disk instead of waiting for NetWare cache to write it as a background process. The workstation will wait until data is written to disk and the FAT tables are updated, which can mean an 80 to 90 millisecond delay. (On a NetWare 2.x server, only the FAT Table gets updated).
PB BUFFERS = 3. This entry is related to the Packet Burst feature. Even though the possible values range from 0 to 10, packet burst is either On (any number between 1 and 10, including the default of 3) or Off (0). Since ODI is fast enough, the DOS Requester currently allocates three ECBs (Event Control Blocks) and packet burst headers (without the full packet size buffers). Three should be enough to cover your needs. If you're running Packet Burst at the server, set this parameter to a nonzero value (or leave it at the default); if you're not, set it to 0 to save some memory.
Performance Parameters that Also Affect Memory
LOAD LOW CONN = ON. CONN.VLM (the connection table manager) keeps track of the workstation's connections, the servers it is attached to, and the tasks that are currently being executed. CONN.VLM supports all layers of the VLM architecture and takes about 3KB when it is loaded low.
Loading it low (the default) can be a good performance boost. If there is any upper memory available, the Load Low command will use these UMBs rather than conventional memory. This helps keep the VLM footprint in conventional memory to a minimum.
LOAD LOW IPXNCP = ON. IPXNCP.VLM (the IPX transport module) implements the transport layer for IPX. IPXNCP.VLM takes about 4KB when it is loaded low. This is the default (for performance reasons). If there are any UMBs available, the Load Low command will use these UMBs rather than conventional memory.
SIGNATURE LEVEL = 1. Setting the Signature Level offers NCP packet signature, which is a message digest (similar to a checksum) that prevents unauthorized access to the network via forged packets. The first several bytes in a request packet go through a digest algorithm. The possible settings are:
0 for disabled
1 for enabled but not preferred
2 for preferred
3 for required.
If set to anything other than 0 or 1, this entry can impede performance. However, the slight decrease in performance must be weighed against the security benefits offered by NCP packet signing. (For more information, see the NetWare 4.0 Documentation.)
CACHE BUFFERS = 5. This parameter signifies the number of files that may be cached at one time. Generally, applications don't have more than five files open at a time, so increasing the number of buffers does not increase performance. If you are running Windows or DESQView 386, you will probably have more files open at once and may want more cache buffers to improve performance. You can specify between 0 and 64 cache buffers.
CACHE BUFFER SIZE =. This parameter determines the amount of data that can be cached by the DOS Requester. It is used by the FIO module. The DOS Requester dynamically sets this parameter to the optimal size, which is the maximum size for the media type you are using, minus 64 bytes. The actual size varies according to what type of network hardware you have, but since it is dynamically configured, you won't need to set this parameter.
PRINT BUFFER SIZE = 64. This entry is used by the PRINT module. The print buffer is a character catch for Interrupt 17h requests, which are single character print requests. Once the 64 byte buffer is filled, it will call the FIO module to go through a file write request instead of calling FIO for each character. The setting can be between 0 and 256 bytes.
If the majority of your printing is performed through Interrupt 17h, setting this cache larger will make a difference. This is not so important for most new applications which open LPT1 and perform a file write rather than going through Interrupt 17h.
Group 2: Parameters that Are Memory Related
CONNECTIONS = 8. For compatibility with the utilities in NetWare 3.x and below, as well as applications written to the older NetWare shell API set, the default is set to 8. NetWare 4.0 clients using Directory Services may want to set this to 16 (or more) connections. Both the CONN and FIO VLM modules keep track of the connection information for much of what they do.
While you can have more than 8 connections active on NetWare 3.x and below, you will see only eight server attachments when you type WHOAMI. In the end, this confusion to the utilities can be too much for your connection to function properly. For NetWare 3.x and below, use the default of 8.
NETWORK PRINTERS = 3. The default for network printers is 3, but can be set up to 9 if needed. If you set this parameter to 0, the PRINT module won't load. If you set Network Printers to 1 or 2 and you have more CAPTURE statements than you allow printers, CAPTURE will think it has set up these connections. In actuality, no connections are allocated to those statements.
AUTO RECONNECT = ON. The Auto Reconnect parameter defaults to On, but it is only activated by loading the AUTO.VLM module. To load the module, you must specify VLM = AUTO.VLM in the NET.CFG file and you must load NDS.VLM. If you are using VLM.EXE's default module loading list, you only need to place VLM = AUTO.VLM somewhere under the "NetWare DOS Requester" heading.
The AUTO.VLM module keeps a snapshot of its connection information and drive mappings to the respective servers. Then if the server can be found again, AUTO will reconnect to the server and add the drive mappings and printer redirections that were lost. The reconnection applies to the server connection only. How well an application can recover from a connection loss and reentry depends solely on the application itself. If the application has been down for a while, users usually become impatient and reboot their workstations.
AUTO.VLM currently works only with NetWare 4.0 Directory Services, not with Bindery Services.
AVERAGE NAME LENGTH = 48. The NetWare shell was configured to hold eight 48-byte server names - one for each connection allowed. The CONN module (the VLM's connection table manager) can be configured to hold more through the "Connections" entry. Most server names are relatively short (between 6 and 12 characters), so you can set the name length to the longest name and save a bit of memory.
You can set server name lengths anywhere between 2 and 48 characters. Since this number is an average, if a server name is longer than what you have set up, the name will wrap to take care of the extended name set. However, if you run out of space and try to add another server, you can lose all your connections.
MAX TASKS = 31. This entry indicates the number of tasks the DOS Requester can accurately track at one time. For the most part, you have only a few tasks opened or running at the same time, so the default of 31 is a generous number. However, with windowing, multitasking environments running on top of DOS (such as Windows 386 and DESQview 386), you may need to increase this number. The minimum number you can set this parameter to is 5; the maximum is 254.
While the DOS Requester allows more tasks to load than what the setting shows, the DOS Requester won't be able to track them accurately, and the task numbers will show this. Poor tracking has relatively minor affects on the DOS Requester until you terminate a non-tracked task abnormally. Then you will leave files open until you log out.
PRINT HEADER = 64. Use this option in conjunction with the functionality of the network printers (devices). You can send functions to control the font, size, spacing, pitch, and orientation of the printed output. The Print Header parameter allows you to change the size of the print header buffer if you need more space to accommodate the larger mode functions.
There is no easy way to find out how big your buffer needs to be. Because the size depends on how many functions the largest print mode contains, go into PRINTDEF, determine which mode has the most functions, and count every character in each of the functions of that mode. Then resize your buffer accordingly, allowing for one byte per character.
When counting a function's characters, treat all characters within a pair of delimiter brackets (<>) as one character, and each character outside the delimiters as one character. For example, <ESC<2!<SP< is four characters long - one character for <ESC<, two characters for 2!, and one character for <SP<.
If you don't use PRINTDEF or PRINTCON in version of NetWare before 4.0, use the default print header buffer size, which is 64 bytes (characters). If you use these printing utilities a lot, adjust your print header to handle the largest defined mode. The settings can be between 0 and 1,024.
PRINT TAIL = 16. The print tail always contains the Reinitialize mode functions from PRINTDEF. Most such modes are short. For example, Hewlett- Packard's reinitialization sequence is <ESC<E (a two- character count). However, the IBM ProPrinter reinitializ-ation sequence systematically turns off every function defined in the Proprinter mode, so its Reinitialize mode will be larger. Go into PRINTDEF and look at the Reinitialize modes for all your defined devices and determine which one contains the most characters. Then set your Print Tail size to accommodate the largest Reinitialize mode. If you don't use PRINTDEF, use the default Print Tail size (16 bytes). The settings can be between 0 and 1,024.
Group 3: Parameters Specific to a DOS Requester Service
Directory Service-Specific Parameters. NetWare Directory Services has two parameters to help define its environment. These are Preferred Tree and Name Context.
PREFERRED TREE = <tree name<. When you log in to NetWare 4.0 using Directory Services, you log in to a network of services, as opposed to a specific file server. The Preferred Tree entry determines the preferred Directory tree for initial attachment, and gives the workstation a group of resources it can initially access.
If both Preferred Server and Preferred Tree entries are in the NET.CFG, the Preferred Server entry can cause authentication problems and should be avoided. If the Preferred Server entry is the only entry listed and the server is a NetWare 4.0 server running Directory Services, the initial attach will be bindery-based. However, this connection will be upgraded to a Directory Service connection upon logging in.
NAME CONTEXT = "<context<". This entry has nothing to do with the DOS Requester in functionality, but it does offer a starting point within the Directory tree for NetWare 4.0 utilities. It can also be used to locate your user object in the Directory tree when you log in, or to log you into the area of the tree where you need to perform a specific function.
For examples of how to use this parameter and how to use the LOGIN, CX, and NLIST commands in a 4.0 network, see the "Logging In and Using the Login Utilities" section later in this AppNote.
Bindery Service-Specific Parameters. Bindery Services has only one parameter to help define its environment. This is Preferred Server. However, you can also use the First Network Drive = parameter in conjunction with the Preferred Server parameter.
PREFERRED SERVER = <server name<. While this is not a new NET.CFG parameter, it is useful for designating which server you wish to initially attach to when a workstation loads its network drivers and the DOS Requester.
Important: Use the "PREFERRED SERVER =" parameter only if you are logging in as a bindery-based client. Using this parameter when logging in as an NDS Client may cause authentication problems.
The Preferred Server entry allows you to specify a server you want the workstation to attach to; the DOS Requester then attempts to connect the workstation to the specified server rather than the first server that responds to the "Get Nearest Server" broadcast. The DOS Requester will also attempt a number of server connections in case the workstation can't establish a connection with the specified server.
Group 4: Other Parameters That Affect the DOS Requester
This section covers the rest of the NET.CFG parameters that apply to the DOS Requester. Those parameters that need to be placed under the NETWARE DOS REQUESTER heading (and indented) include Use Defaults, VLM, Set Station Time, Message Level, First Network Drive, and Handle Net Errors. The rest of the parameters listed below don't need to be placed under the NETWARE DOS REQUESTER heading, but it's easier to keep track of them if they are. These entries can also be indented (for consistency).
USE DEFAULTS = ON. You can leave this entry set to ON and add other modules, such as AUTO.VLM, under the NetWare DOS Requester heading in the NET.CFG file. This way, VLM.EXE uses its default load list for the relevant VLM modules and then adds other specified VLM modules.
If you set this parameter to OFF, you are telling VLM.EXE to only load the VLM modules designated in the NET.CFG file. When you do this, you must type in all the VLM modules you wish to load (in the correct loading order). Otherwise, VLM.EXE won't work.
For NetWare 4.0 without security, the minimum list should include:
VLM = CONN.VLM VLM = IPXNCP.VLM VLM = TRAN.VLM VLM = NDS.VLM VLM = NWP.VLM VLM = FIO.VLM VLM = GENERAL.VLM VLM = REDIR.VLM VLM = PRINT.VLM
Don't forget your Preferred Tree and Name Context designations. If you try using this list and you can't log in, you may have security in place, in which case you will need to add the security modules and the correct Signature Level parameter setting. If you don't need printing, don't load the PRINT module.
For NetWare 3.11 or below using Bindery Services, the bare minimum list should include:
VLM = CONN.VLM VLM = IPXNCP.VLM VLM = TRAN.VLM VLM = BIND.VLM VLM = NWP.VLM VLM = FIO.VLM VLM = GENERAL.VLM VLM = REDIR.VLM VLM = NETX.VLM VLM = PRINT.VLM
If you don't want printing, remove the PRINT.VLM from the list. Don't forget the Preferred Server and First Network Drive parameters if you need them. You can sometimes get by without the NETX.VLM module, but you stand to lose application compatibility if you do.
VLM= <path<\<VLM<. You can use all relevant DOS path names to load specific VLM modules from local directories. For example, we tried the following different options, and they all worked.
VLM = C:\NWCLIENT\CONN.VLM VLM = C:\NWCLIENT\TEMP\IPXNCP.VLM VLM = ..\NWCLIENT\TEMP..\TEMP\TRAN.VLM
According to VLM specifications, you can have up to 50 VLMs loaded at one time, which leaves a lot of room for future expansion. However, each loaded VLM is another link the VLM manager must go through when passing information along the DOS Requester. You may see better performance by only loading the VLM modules you actually need and use.
SET STATION TIME = ON. This option tells whether or not to synchronize the workstation's time with the server you log in to. The LOGIN.EXE utility used to have the same feature, but this marks the first time the parameter is configurable. If you are remotely tying in across time zones, you would want to set this to OFF.
MESSAGE LEVEL = 1. This entry simply shows you how verbose you wish the message strings to be when you initially bring up the DOS Requester.
0 shows you the copyright sign-on message and any critical errors that occur as the modules load.
1 adds any warning type messages as the modules load (default).
2 adds the module names as they load.
3 adds configuration information along with the module names. This includes the load order of the modules along with version date and code number, followed by the NET.CFG parameters that are different than the parameter defaults.
4 displays diagnostic messages, which are different from the diagnostic information you see by typing VLM /D at the command line.
These settings correspond to the numbers you can set as you initially bring up the DOS Requester. For example, you can type VLM /V0 through /V4 and see the same message strings as you do here. If you put no /Vn verbosity parameter after VLM, VLM will look to the NET.CFG settings or to its default.
FIRST NETWORK DRIVE = <NONE< or F. This parameter applies to all the network services you may tie into. If you run the DOS Requester's installation program, you will have the first network drive equal to F as the default. However, the default may change to be the first available drive letter.
If you don't have this parameter in the NET.CFG, the GENERAL module will look at your local drive table and map the first available drive letter as the first network drive. If your users are used to having F or G as their first network drive, you can place this entry in the NET.CFG file to ensure the drive mapping will always be what you select.
HANDLE NET ERRORS = ON. This entry is used by the IPXNCP module, and shows whether the DOS Requester presents a generic critical error to the application or whether the Requester returns the actual error code. While most applications are not prepared to handle the actual error code given back from a NetWare network, some are.
Internally, the NetWare utilities can handle those error codes which are a part of the CLIB messages, but applications in general don't use these messages. The libraries are provided for application vendors and developers if they want to use them.
Setting this entry to ON allows DOS Int 24 to handle all network errors. When set to OFF, applications will receive the raw error code.
LOCAL PRINTERS = 0. Use this parameter to set up to 4 local printers that are attached to a workstation. If your workstation doesn't have a local printer, leave this parameter set to 0; then your workstation won't hang (or appear to hang) if you accidentally press <Shift<- <Print Screen> and you don't have CAPTURE running.
If you add a local printer to your workstation, or if you run NPRINTER (NetWare 4.0) or RPRINTER (NetWare 3.x) to use the printer as a network resource, that printer won't work if the Local Printers parameter is set to 0. When you attach a printer to a workstation, change or add the Local Printers parameter in that workstation's NET.CFG file to reflect that number.
SEARCH MODE = 1. This parameter helps determine how an application can use the search drives to search for auxiliary files. Many applications, when started, also open a number of other files (such as overlay files and data files) that are used as a resource to the application. The "Search Mode" option determines when applications can look in your NetWare search drives to find these auxiliary files.
Search Mode has five possible settings: Mode 1, Mode 2, Mode 3, Mode 5, and Mode 7. (Modes 4 and 6 are not presently used.) Each mode specifies a different way of using search drives. A brief explanation of each mode appears below. DOS will always look in a specific path (if specified in the application), and then in the default directory, regardless of which search mode you specify. You may need to read your applications documentation to determine if the application just reads its auxiliary files, or reads and writes to them.
Mode 1 is the default search mode for the DOS Requester. When you use this setting, the DOS Requester will look in the search drives only when no path is specified in the application (and after DOS has searched the default directory).
Mode 2 causes the DOS Requester to not look in any search drives to find auxiliary files. The application will behave as if you were running it on a stand alone machine with DOS only. If the application has a defined directory path that allows it to search and open files, the application will search for the files in that defined path. NetWare refers to this mode as "Do not search."
Mode 3 is exactly like Mode 1, except that if the application has no defined directory path to search and open files, the DOS Requester will look in the search drives only if the open request is a read- only request. NetWare calls this "Search on Read- Only opens with no path."
Mode 5 causes the DOS Requester to always be able to look in the search drives, even if the application specifies a path. NetWare refers to this mode as "Search on all opens."
Mode 7 is exactly like Mode 5, except that the DOS Requester will look in the search drives only if the open request is a Read- Only request. NetWare calls this mode "Search on all Read- Only opens."
The search mode you set in your NET.CFG file applies to all applications, so you should choose the mode that works for the majority of your programs. The table below shows when the "Search Mode" option allows the DOS Requester to use the search drives, according to whether a path is specified in the application and whether the open request is a Read- Only request or a Read- Write request.
|
NO PATH |
PATH |
|||
|
Mode |
Read- Only |
Read- Write |
Read- Only |
Read- Write |
|
1 |
Yes |
Yes |
No |
No |
|
2 |
No |
No |
No |
No |
|
3 |
Yes |
No |
No |
No |
|
5 |
Yes |
Yes |
Yes |
Yes |
|
7 |
Yes |
No |
Yes |
No |
READ ONLY COMPATIBILITY = OFF. Some applications open files for read-write access, but then only read from them. If the file is marked Read-only or if they have Read-Only access to it, the application could fail to open the file.
When this parameter is set to ON it allows the application to open the file and still deny the user to write to the file. It delays the failure to when they try to write to the file rather than when the file opens. Applications like The Coordinator do that. There are also some compilers that don't provide an option for open on a read-only.
SHOW DOTS = OFF. Programs like Windows allow you to move up directories in the directory path by highlighting "." and ".." entries and pressing <Enter< or by clicking on these path entries. The "Show Dots" option allows these programs to use the "." and ".." options to change directories.
It's best to leave this option to OFF if you're not running programs that use dots to traverse directories. If you're using Microsoft Windows, set SHOW DOTS = ON in the NET.CFG file. Otherwise, Windows assumes it's in the root directory, which may not be the case.
DOS NAME = MSDOS. This entry allows you to tell the DOS Requester which type of DOS the workstation is running. If you are running DR DOS, change the entry to "DRDOS" to reflect this. You can have between 1 and 5 characters for this entry.
LONG MACHINE TYPE = IBM_PC. The long machine type is used with the %MACHINE variable in the login script. You can use the %MACHINE variable in a "generic" DOS directory mapping, such as shown in the following example:
MAP S2:=SYS:PUBLIC\%MACHINE\%OS\%OS_VERSION
If you are using a non- IBM workstation that runs its manufacturer's own version of DOS (such as a COMPAQ machine running MS- DOS as published by Compaq Computer Corporation), you can place this version of DOS onto a network directory and use the long machine type to indicate what you want the login script to replace the %MACHINE variable with. For example, you can create two DOS directories:
SYS:PUBLIC\IBM_PC\MSDOS\V5.00 SYS:PUBLIC\COMPAQ\MSDOS\V5.00
If you place "LONG MACHINE TYPE = COMPAQ" in the NET.CFG file, those workstations will access the Compaq DOS directory instead of the IBM PC-DOS directory.
IBM_PC is the default long machine type. You can have up to 6 characters in the designation. If you type in more than that, you will receive a warning message telling you that you are using too many characters. Earlier versions of NetWare allowed you to get away with 8 characters by not warning you if you had too many characters (even though it only accepted the first six characters). However, the DOS Requester will warn you if you add more than 6 characters.
SHORT MACHINE TYPE = IBM. Some older monitors emulate color monitors by using gray scales instead of actual colors. These monitors, particularly some of those from AT&T and Compaq, need to use the CMPQ$RUN.OVL file found in the SYS:PUBLIC directory, instead of the default IBM$RUN.OVL file. Without it, you may not be able to see the gray scales differentiated from the background, and your display will be unreadable.
To make your workstation call the CMPQ$RUN.OVL file when you access a NetWare menu utility, use "SHORT MACHINE TYPE = CMPQ" as the short machine name parameter in the NET.CFG file. The short machine type can't be more than four characters long; the default is IBM.
Setting Up to Access Specific Services
This section contains examples of using the DOS Requester for accessing a specific network service. These examples illustrate how people actually use the DOS Requester in various ways. You can control what modules you load by doing any of the following:
Deleting the VLM modules you don't want loaded by VLM.EXE's default list.
Renaming those VLM modules with a different file extension.
Using the "VLM =" entry in the NET.CFG file to control which files are loaded.
You can create a generic NET.CFG script for your network, then use a semicolon to mark all comments and to cancel out commands you don't want to load on certain machines. By using the semicolon, you can work from one NET.CFG file and customize workstations when necessary. The decision of adding or removing modules from the VLM load list can be important if you need to use conventional memory instead of extended or expanded memory managers.
Example CONFIG.SYS and AUTOEXEC.BAT Files
Below are four working examples of CONFIG.SYS and AUTOEXEC.BAT files. From these examples, you can see that the DOS Requester works in many environments and under different memory managers.
Example 1: MS-DOS 3.3. In this example, the CONFIG.SYS and AUTOEXEC.BAT files are using MS-DOS v3.30 without memory management. This configuration gives the user 471KB of conventional memory to run applications. The user is also loading TCP/IP drivers with the DOS Requester.
CONFIG.SYS
BREAK=ON BUFFERS=15 FILES=20 LASTDRIVE=Z SHELL=COMMAND.COM /E:2000 /P
AUTOEXEC.BAT
C:\WINDOWS\SMARTDRV.EXE PATH=C:\WINDOWS;%PATH% SET TEMP=C:\WINDOWS\TEMP NUMLOCK PROMPT $P ECHO OFF VERIFY ON BREAK ON CLS VER QUICKKEY CED - B1024,128,1024,256,128,128 - FINITCED SET TMP=C: LSL NE2- 32 IPXODI TCPIP TELAPI CD VICE VLM F: LOGIN DANA SET LIB=X:LIB CASTOFF ECHO ON
Example 2: MS-DOS 5.0. In this example, the user's CONFIG.SYS and AUTOEXEC.BAT files are using MS-DOS 5.0. After logging in to the network, the user has 602KB of conventional memory to run applications in.
CONFIG.SYS
DEVICE=C:\DOS\SETVER.EXE DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE NOEMS BUFFERS=30,0 FILES=45 DOS=UMB LASTDRIVE=Z FCBS=4,0 SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:768 /p BREAK = ON STACKS=9,128 DEVICEHIGH=C:\DOS\ANSI.SYS DOS=HIGH
AUTOEXEC.BAT
LH /S C:\DOS\SMARTDRV C 1024 PATH C:\DOS;C:\WIN31;C:\UTIL;C:\HJWIN;C:\;C:\NU SET NU=C:\NU SET TEMP=C:\WIN31\TEMP PROMPT $P$G SET WPC=/NT- 1/U- EAL LH DOSEDIT C:\DOS\MOUSE CALL C:\NWCLIENT\STARTNET F: LOGIN SRD/ELIEBING
STARTNET.BAT
@ECHO OFF C: CD \NWCLIENT SET LANGUAGE=ENGLISH LH LSL LH NE2000.COM LH IPXODI VLM /MX CD\
Example 3: DR DOS 6.0. In this example, the user is running DR DOS 6.0. Because this is an actual working example, the upper memory is relatively unused. The workstation has 96KB left that can be used for TSRs. With this configuration, the user has 532KB of conventional memory.
CONFIG.SYS
SHELL=C:\COMMAND.COM C:\ /P /E:2048 DEVICE=C:\DRDOS\EMM386.SYS /F=AUTO /K=3072 /B=FFFF /R=AUTO BREAK=ON HIBUFFERS=20 FILES=70 FASTOPEN=512 LASTDRIVE=Z HISTORY=ON, 256, OFF, OFF, OFF COUNTRY=001,,C:\DRDOS\COUNTRY.SYS HIDOS=ON
AUTOEXEC.BAT
SET NWLANGUAGE=ENGLISH @ECHO OFF :DRDOSBEG PATH C:\WINDOWS;C:\DRDOS;C:\WP;C:\WORK\TOOLS VERIFY OFF PROMPT $P$G ;SET COMSPEC=C:\COMMAND.COM SET TEMP=C:\DRDOS\TMP IF NOT "%TEMP%"=="" MD %TEMP% >NUL> SET DRDOSCFG=C:\DRDOS\CFG :DRDOSEND CD \CLIENTS\ODI LSL NE2000 IPXODI VLM MEMMAX - U F: LOGIN DMARSHAL
Example 4: Third-Party Memory Manager. This example uses QEMM386 as its memory manager and gives the user 624KB of conventional memory in which to run applications.
CONFIG.SYS
DEVICE=C:\QEMM\QEMM386.SYS RAM DEVICE=C:\NDW\NAV&.SYS /B& DEVICE=C:\DOS\SETVER.EXE DOS=HIGH FILES=60 SHELL=C:\DOS\COMMAND.COM C:\DOS\ /P /E:768 STACKS=9,256 BUFFERS=30 LASTDRIVE = Z
AUTOEXEC.BAT
C:\QEMM\LOADHI /R:3 C:\WINDOWS\SMARTDRV.EXE C:\QEMM\LOADHI /R:4 C:\DOS\DOSKEY @ECHO OFF PROMPT $P$G SET MOUSE=C:\MOUSE1 C:\QEMM\LOADHI /R:3 C:\WINDOWS\MOUSE.COM /Y PATH C:\WINWORD;C:\NDW;C:\QEMM;C:\UTILS; C:\BOOT;C:\WINDOWS;C:\DOS;C:\PKZIP NAV C:\ SET TEMP=C:\DOS C:\UTILS\SCAN.EXE C:\ /M CD NWCLIENT CALL STARTNET.BAT F: LOGIN SRD/GHERBON C:\QEMM\LOADHI /R:1 Y:.\SHARE.EXE
STARTNET.BAT
C: CD \NWCLIENT SET LANGUAGE=ENGLISH C:\QEMM\LOADHI /R:2 LSL C:\QEMM\LOADHI /R:3 NE2000 C:\QEMM\LOADHI /R:1 IPXODI VLM /MX CD\
File Handles
The number of open files is an issue with the DOS Requester. Previously, you set FILES=xx in the CONFIG.SYS for the number of open files needed for the workstation local drives. You then set FILE HANDLES=xx in the NET.CFG file for the number of open files needed for network drives. Now, you set the total number of open files through the CONFIG.SYS file with the FILES=xx statement. (Include enough for Windows, if used.)
If you have an older NET.CFG file with a FILE HANDLES=xx statement in it, remove the statement and increase the number of files in the FILES=xx line in the workstation's CONFIG.SYS file. Otherwise, you may see "Insufficient file" or "Insufficient file handles" error messages.
Environment Size
Another important point to be aware of is the environment size setting in the "SHELL=" line, as shown in the previous examples. Be sure this parameter is set high enough to allow room for search drive mappings (the NetWare drive mappings also use this environment space).
If this parameter is set too low, you won't be able to map search drives. If you see environment errors and can't add search drive mappings, make sure your LASTDRIVE = is set to Z. If the LASTDRIVE parameter is already set to Z, increase the environment size in the SHELL = parameter until you no longer experience the error. For example, if you are receiving error messages and your environment parameter is set to /E:300 in the SHELL = entry, you would want to increase the parameter to /E:600, or a higher number until the problem disappears.
Accessing NetWare 4.0 Services
The DOS Requester defaults to using Directory Services as its initial server connection. By default, the DOS Requester loads into extended memory and then loads the following modules:
CONN.VLM IPXNCP.VLM TRAN.VLM SECURITY.VLM NDS.VLM BIND.VLM NWP.VLM FIO.VLM GENERAL.VLM REDIR.VLM PRINT.VLM NETX.VLM
Notice that the NDS.VLM loads before the BIND.VLM. With this default, VLM.EXE attempts to attach to a server running Directory Services before a server running Bindery Services. If VLM.EXE can't find a server running Directory Services, it will look for a server running Bindery Services.
If you only want to attach to servers running Directory Services, you don't need to load BIND.VLM or NETX.VLM.
NDS Only. Here's an example of a NET.CFG file for a client using ODI, running on thin Ethernet, and loading Directory Services first.
LINK DRIVER NE2000 PORT 300 INT 3 FRAME Ethernet_802.3 MEM D0000 LINK SUPPORT MAX STACKS 8 BUFFERS 8 1500 MEMPOOL 4096 SHOW DOTS ON NETWARE DOS REQUESTER CACHE BUFFERS = 5 BUFFER SIZE = 1024 PB BUFFERS = 8 USE DEFAULTS = OFF VLM = CONN.VLM VLM = IPXNCP.VLM VLM = TRAN.VLM VLM = SECURITY.VLM VLM = NDS.VLM VLM = BIND.VLM VLM = RSA.VLM VLM = NWP.VLM VLM = FIO.VLM VLM = GENERAL.VLM VLM = REDIR.VLM VLM = PRINT.VLM VLM = NETX.VLM VLM = AUTO.VLM PREFERRED TREE = NETADMIN CONNECTIONS = 16 FIRST NETWORK DRIVE = F NAME CONTEXT = "OU=SRD.OU=SERVICES.O=NOVELL" MESSAGE LEVEL = 2 SIGNATURE LEVEL = 2
The "USE DEFAULTS = OFF" entry tells VLM.EXE to load only the VLM modules designated in the NET.CFG file.
NET.CFG entries that are specific to Directory Services include Preferred Tree and Name Context. The NET.CFG entries adding RSA encryption security to Directory Services include loading SECURITY.VLM, RSA.VLM, AUTO.VLM, and setting the Signature Level parameter to the level of security required at the server.
Multiple Protocols. The next NET.CFG example shows the settings for TCP/IP as well as IPX.
LINK SUPPORT BUFFERS 8 1500 MEMPOOL 4096 MAX STACKS 8 LINK DRIVER NE2- 32 FRAME ETHERNET_II FRAME ETHERNET_802.3 FRAME ETHERNET_SNAP PROTOCOL IPX 0 ETHERNET_802.3 PROTOCOL TCPIP 8137 ETHERNET_II PROTOCOL TCPIP IP_ADDRESS 137.65.6.29 IP_ROUTER 137.65.6.254 IP_NETMASK 255.255.255.0 TCP_SOCKETS 8 UDP_SOCKETS 8 RAW_SOCKETS 1 NB_SESSIONS 4 NB_COMMANDS 8 NB_ADAPTER 0 NB_DOMAIN NPD.PROVO.NOVELL.COM NETWARE DOS REQUESTER PB BUFFERS = 5 SIGNATURE LEVEL = 2 LARGE INTERNET PACKETS = ON PREFERRED TREE = GLADTOBEHERE PREFERRED SERVER = RD NAME CONTEXT="OU=OSGROUP.OU=SWTEST.OU=NPD.O=NOVELL" CHECKSUM=OFF FIRST NETWORK DRIVE=E
In this example, the Name Context entry is used to designate the Organization (O) and Organizational Units (OU). The user then fills in his login name as he logs in, and that name is placed at the beginning of the string that you see when you type "CX Enter " at the command line. You can also use the WHOAMI command to see the entire Directory tree context.
For more information on using CX to get around in Directory Services, see the "Logging In and Using the Client Utilities" section later in this AppNote.
Accessing Bindery-Based NetWare Servers
Before switching to NetWare 4.0, you can perform some initial workstation configurations and try them out on a bindery-based server (NetWare 3.x and below). This gives you the opportunity to get the workstations up and running with the DOS Requester before changing over to Directory Services. Then, when you do move to NetWare 4.0, you can update the NET.CFG files with the proper settings, and the client will be able to log in to as an NDS client. You can also use the DOS Requester for Bindery Services without any tie to Directory Services.
Below are two example NET.CFG files for accessing Bindery Services. The first example shows a NET.CFG file that only accesses a bindery server and uses a semicolon to cancel out its link to Directory Services. (You can make this example open to both bindery and Directory Services by taking off the semicolons on the Directory Services parameters you wish to use.)
SHOW DOTS ON NETWARE DOS REQUESTER CACHE BUFFERS = 5 BUFFER SIZE = 1024 PB BUFFERS = 8 USE DEFAULTS = OFF VLM = CONN.VLM VLM = IPXNCP.VLM VLM = TRAN.VLM ; VLM = SECURITY.VLM ; VLM = NDS.VLM VLM = BIND.VLM ; VLM = RSA.VLM VLM = NWP.VLM VLM = FIO.VLM VLM = GENERAL.VLM VLM = REDIR.VLM VLM = PRINT.VLM VLM = NETX.VLM ; VLM = AUTO.VLM ; PREFERRED TREE = doswintree PREFERRED SERVER = SRD CHECKSUM = 0 LARGE INTERNET PACKETS = OFF CONNECTIONS = 8 NETWORK PRINTERS = 3 FIRST NETWORK DRIVE = F ; NAME CONTEXT = "[root]" MESSAGE LEVEL = 2 SIGNATURE LEVEL = 0
The next example shows how to implement performance elements for Bindery Services. Semicolons can be used to mark comments the user makes. The "VLM =" settings match those of the previous example.
NETWARE DOS REQUESTER PREFERRED SERVER=EMBLEM SHOW DOTS=ON NETWORK PRINTERS=1 FIRST NETWORK DRIVE=F ;NAME CONTEXT="O=DSG" ;MEMORY OPTIMIZATION ;SECURITY LEVEL=0 CONNECTIONS=5 AVERAGE NAME LENGTH=10 CACHE BUFFERS=3 LOAD LOW CONN=OFF LOAD LOW IPXNCP=OFF ;PERFORMANCE OPTIMIZATION CACHE WRITES=ON LINK DRIVER NE2000 INT 2 PORT 320 FRAME ETHERNET_802.3
Logging In and Using the Client Utilities
Once you have set up the DOS Requester, you're ready to log in to the network. In NetWare 4.0, you no longer log in to a file server, but to a network of services. How users access and use these services depends on how the network is set up.
Designating a Directory Tree
You may have set up your network with a number of Directory trees. Users may have access to all Directory trees or to only one tree. Once you define which Directory tree users will use as their default, you can use the Preferred Tree = "treename" parameter in the NET.CFG file to designate that tree. This entry places the user in the Directory tree where they have access to the most resources, or where they need to log in to perform their primary tasks.
Name Context
With the proper tree designation in place (if needed), you next need designate where the user logs in to the Directory tree. The Name Context = "context" parameter in the NET.CFG file lets you do this. By setting the correct context in this parameter, the user only has to type "LOGIN username <Enter<" to log in to the network. The user can always change to a different context and access different resources, but setting the "Name Context =" parameter provides a point of reference in the Directory tree where they have access.
In some respects, you can think of a user's default Directory tree access as analogous to a mailing address. Here are the Directory tree terms as they might relate to a standard postal mailing address:
|
CN = Common Name |
(your name) |
|
OU = Organizational Unit |
(street address, PO Box, suite, city) |
|
O = Organization |
(state and ZIP code) |
In a mailing address, these elements must be ordered properly for accurate mail delivery. Likewise, in Directory Services the Common Name (CN) is placed before the Directory tree context, the Organizational Unit (OU) is placed next, and the Organization (O) is last. You can set up a number of Organizational Units (OUs), just like you can have a street address, a suite number, and a mail stop in your mailing address. Or you can have just an Organization (O).
Following the mailing address analogy above, a sample Directory tree context might look like this:
|
Ed Liebing |
CN=ELIEBING (my login name) |
|
122 E. 1700 S. |
OU=SRD (my department's name) |
|
Provo |
OU=SERVICES (my division's name) |
|
Utah |
OU=NOVELL (my company) |
|
USA |
O=US |
If your company is domestic and doesn't require an international Organization structure, you could set up your Directory with O=NOVELL as the top level rather than O=US. However, if you need international containers, we suggest you use Organizations to denote countries.
In Directory Services, you write the identifying context like this (this example has no international organization):
CN=ELIEBING.OU=SRD.OU=SERVICES.O=NOVELL
This context reflects the way a Directory tree can give user ELIEBING access to its resources. Notice that the user's Common Name (CN) is first and the Organization (O) is last.
Most users won't want to write out long contexts every time they log in, so use the "Name Context=" parameter in the NET.CFG file to eliminate this process. For the example above, the parameter would look like this:
Name Context = "OU=SRD.OU=SERVICES.O=NOVELL"
The DOS Requester will then be set to that Directory tree context. As user ELIEBING logs in, he only has to type
LOGIN ELIEBING <Enter<
at the network prompt. When he does this, his Common Name (ELIEBING) is placed at the front of the Directory tree context. Then if he types "WHOAMI <Enter<", he would see the following:
Current Tree: MANUFACTURE Complete Name: CN=ELIEBING.OU=SRD.OU=SERVICES.O=NOVELL
This procedure gives users access to the resources that they have rights to in this part of the Directory tree. From here, they can use the NetWare utilities and login script mappings to access those resources.
You may also allow certain users to have access to other Directory tree contexts. In this case, users can use the CX command to change to those other Directory tree contexts. For example, suppose user ELIEBING wants to log in to a second Directory tree once he either logs in or has started his computer. For the DOS Requester, the current context is still OU=SRD.OU=SERVICES.O=NOVELL. If ELIEBING knows the second Directory tree name (which is NU_TREE), he can use the "LOGIN <treename</<username< /TR" command, as follows:
LOGIN NU_TREE/ELIEBING /TR <Enter<
If ELIEBING knows his entire context within the new Directory tree, he can use the CX command to change over to that context in the Directory tree:
CX .MARCOM.MKTG.WIGITECH <Enter<
The leading period negates the Directory context information stored in the DOS Requester and essentially says "I'm going to specify a complete Directory context, not a partial name." The user can then type
LOGIN ELIEBING <Enter<
and give his password to log in to the second Directory tree.
You can also use "partial names" to move to other areas of the Directory context. For example, if user ELIEBING is working from the MRP Organization Unit context (CN=ELIEBING .OU=MRP.OU=MFG.O=WIGITECH) and wants to work from the ASSEMBLY Organizational Unit, which is at the same level as MRP, he can type:
CX OU=ASSEMBLY. <Enter<
The period at the end of ASSEMBLY removes the first piece (OU=MRP) from ELIEBING's Directory context and adds OU=ASSEMBLY to get OU=ASSEMBLY.OU=MFG.O=WIGITECH as the complete name. Now when he types "WHOAMI <Enter<", he sees:
Current Tree: MANUFACTURE Complete Name: CN=ELIEBING.OU=ASSEMBLY.OU=MFG.O=WIGITECH
Your Directory tree context probably won't be as complex as this example. You may have only one Organizational Unit (OU) and one Organization (O), or your entire Directory tree context may only be one Organization (O). The idea is to use NET.CFG's Context Name and Tree Name parameters to give your users the best entry point into the Directory tree.
If you don't have any O or OU specifications to set through the Name Context parameter, use Name Context = "[root]" for this parameter. This setting bypasses certain anomalies in the login process. You can then type in the whole Organizational Unit (OU) as well as your context name when you log in.
When you set the Name Context parameter in the NET.CFG file, the DOS Requester does not verify that the context actually exists. For example, if you have Name Context = "O=TIDBIT" in your NET.CFG, the name context in the DOS Requester will be set to O=TIDBIT, whether or not there is any TIDBIT Organization (O) defined in a Directory tree. This can confuse users and make it difficult for them to log in.
For example, if you have Name Context = "O=TIDBIT" in your NET.CFG and you log in as ADMIN, the Common Name ADMIN is placed before O=TIDBIT, giving you CN=ADMIN.O=TIDBIT. This entry is passed to Directory services for authentication, but if TIDBIT is not a valid Organization container, you will receive the message "Access Denied."
Again, your Common Name is placed before the context that is set in the DOS Requester, so make sure the information placed in the NET.CFG file is accurate and you are using accurate Common Names when logging in.
Other LOGIN Variations
Here are a few other helpful LOGIN command variations:
LOGIN servername/username
This attaches you to the specified server, but does not runthe login script. You won't be asked for a password if you use the /NSoption
LOGIN username/B
The /B option will enact a bindery emulation login process from NetWare 4.0if you need to use this.
Navigating the Directory Tree: The CX Command
You can use the CX command to find out where you are at in the Directory tree. To view all that you can do with the CX command, type:
CX /? <Enter<
You will see the two screens shown in Figure 10.
Figure 10: Help screens for the CX command.
Following are a few examples of how to use the CX command and its parameters:
|
CX |
View your currentcontext in the Directory tree. |
|
CX /T |
View the Directorytree below your current location. |
|
CX /T /A |
View all theobjects that are defined at or below yourcurrent context location. |
|
CX /R |
Go to the [Root]of the Directory tree. |
Remember, what you see is defined by the rights you have at the [Root] and in the Directory tree. Two people may see different Directory tree resources. There are a lot more things you can do with the CX command, so experiment.
You can also use the WHOAMI command to view the Directory tree and your entire Directory tree context.
Exploring the Directory Tree: The NLIST Utility
The NLIST utility is another way to discover what resources are available to you from your Directory tree context. When you type "NLIST /? <Enter<," you see the initial help screen shown in Figure 11. There are other help screens to expand on the initial parameters you see.
Figure 11: The initial help screen for the NLIST command.
As you can see, there's quite a bit to this utility. A number of quick command variations are listed below for reference. As you try out similar commands on your network, remember that what you can see with the NLIST utility depends entirely on the level of detail that has been defined for each object through the NETADMIN or NWAdmin utilities.
|
NLIST USER= ELIEBING /D |
Display allthe property information associated withuserELIEBING,including login script,telephone numbers, E-mail address, and soon (if you have filled out this kindof information.) |
|
NLIST PRINTER /S |
Search yourlocal Directory context and its subcontainersforprinters. |
|
NLIST PRINTERWHERE"CARTRIDGE" = F |
Find out ifthere are any printerswith an F cartridge(if you havedefined this information). |
|
NLIST PRINTER /CO "." /S |
See what printersare above youin the Directory tree context(assumingyou have rights to seesuch items). |
|
NLIST /TREE= *(or "TREE NAME" for aare availableto you, or see a |
See all theDirectory trees thatare available toyou, or seea specific Directory tree |
|
NLIST USERWHERE"TITLE" EQ MANAGER /S |
Find any userswho have a titleequivalent to "Manager"in yourlocal Directory contextor itssubcontainers. |
|
NLIST SERVER /B |
List all serversthat are bindery-based. (This is the4.0 equivalentto the SLIST command.) |
|
NLIST SERVERWHERE"VERSION" = 4.0 |
List all serversthat are runningNetWare 4.0. |
|
NLIST SERVER=GRACELAND /A |
Find out if a server called GRACELAND is active.(You canalso find out if users are activeby using the /A parameter.) |
|
NLIST GROUPWHERE"MEMBER" = ELIEBING |
See a listof groups thatELIEBING is a member of. |
|
NLIST USER /A |
See a list of all logged in users. |
|
NLIST VOLUME= GRACIESHOW "HOST SERVER" |
Find out whichserver has a particular volume (suchasGRACIE) defined on it. |
|
NLIST USERWHERE NAME EQ"ELIEBING" SHOW"LOGINSCRIPT" |
Display the login script for userELIEBING. |
With Directory Services, you can set things up so that users can see such information as other users' phone numbers and E-mail addresses. Again, what you can see depends on how well you have defined the property attribute information on a particular object. If it's not defined, you won't see it displayed in NLIST.
New NET.CFG Parameters
Just prior to shipping, some last-minute updates were made to the DOS Requester software. These include three additional NET.CFG parameters.
AUTO RETRY = 5. This parameter can be used in conjunction with NetWare's automatic reconnection capabilities. The parameter defaults to five seconds, but it can be set between 0 (OFF) and 3,640 seconds (60 minutes). When you receive a "Error reading (or writing) to the network: Abort, Retry, Fail?" message, this parameter automatically retries for you every five seconds until it can reconnect to the network (or to the server in the case of NetWare 3.x and below). To use this parameter, you must have the AUTO.VLM module running (place "VLM = AUTO.VLM" in the NET.CFG file).
BIND RECONNECT = ON. This parameter is for NetWare 3.x and below. The DOS Requester now has automatic reconnection capabilities for bindery-based servers (NetWare 3.x and below). With this parameter enabled, the DOS Requester stores the workstation's password in encrypted form in its memory to be used when Requester needs to reestablish server connections. You must have the AUTO.VLM module running (place "VLM = AUTO.VLM" in the NET.CFG file) to use reconnection capabilities.
While this capability is not as secure as Directory Services with RSA encryption, it's a nice addition to NetWare and can be a life-saver for Windows users. Of course, this depends on how you are running Windows (locally or from the network) and how the applications you are using react to connection loss. Most applications don't respond congenially to connection interruptions.
LOAD CONN TABLE LOW = OFF. When set to ON, this parameter loads the connection table low enough in memory so that the NetWare 4.0 utilities can find it. The memory used will be either in the Upper Memory Block (UMB) area or in conventional memory. Turning this parameter ON increases the size of VLM.EXE by about 300 bytes.
If you are running the DOS Requester on NetWare 3.x or below, or if you are running NetWare 4.0+ (the international release), use the default of OFF.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.