I. SAMPLE CONFIGURATIONS

I.1 Comparison between NETX, VLM and Client 32 NetWare Client Software

[VLM are now becoming the past, Client32 the future, and NETX obsolete.]

VLM are a lot of different modules rather than one big program. You can choose which modules to load and where they are to be loaded (i.e. conventional, UMB or extended memory). VLM does for NETX what ODI did for IPX.OBJ, and provides more configuration options so the move from NETX to VLMs should be considered as inevitable as the move from IPX.OBJ to the ODI model.

You can use VLMs on NetWare 3.11 but to use packet burst technology you need to get and load PBURST.NLM (available from ftp.novell.com and its mirrors). Nothing else is required on the server but if you do not get and install the related security enhancements, you will need to add the command SET NCP PACKET SIGNATURE OPTION = 0 to your AUTOEXEC.NCF immediately after the line that loads PBURST.NLM. Also, you will need to configure your clients to use ODI drivers before they can use VLM as VLMs do not work with IPX.OBJ/IPX.COM.

Programs needing packet driver software are supported, via ODIPKT.COM, and Windows requires a different NETWARE.DRV for VLMs than for NETX. The DOS client kit can be ordered from any Novell vendor. This gives you a site license for VLM v1.1 and Novell's TCP stack, including WINSOCK.DLL. Price is $US99. You then upgrade to version 1.2 by getting the following files from ftp.novell.com: NWDLL2.exe WINDR2.exe and VLMUP3.exe. While there you may wish to pick up NET33X.exe for your NETX clients. For more information on VLMs, (installing, configuring, etc.), consult the manuals you get with the DOS client kit.

To obtain the latest ODIPKT.COM (now at version 3.0)

ftp://hsdndev.harvard.edu/pub/odipkt

To obtain the latest ODITRPKT.COM (version 3.0 for Token Ring)

ftp://dc.cis.okstate.edu/pub/oditrpkt

By the way, ODIPKT version 3.0 takes hex arguments, earlier versions used decimal values.

[Thanks to Gordon Keith, S.M.D. & James Harvey for this info]

There are huge architectural differences between them. VLM is a proper DOS redirector, doing most of its work underneath DOS. NETX is a shell, which grabs requests before DOS even gets a chance to see them. VLM is modular, allowing you to load only the bits you need; NETX is monolithic, and the whole thing must be loaded. VLM will perform a large degree of memory management on its own; you have to do this yourself for NETX.

There's only one VLM.EXE whether you want it in conventional memory, XMS (and this time it really _is_ XMS, not HMA), or EMS; you have to keep track of separate versions of NETX for these three different configs.

From a features viewpoint, VLM supports Personal NetWare, NDS (an option with NetWare 4.x), and bindery (NetWare 3.x and below, or bindery emulation on 4.x); NETX supports only bindery. VLM includes support for packet burst; no current NETX shell does. The corresponding Windows drivers for VLM have more functionality than those for NETX, too.

NETX is faster on small operations, as it doesn't suffer the overhead of DOS or of swapping bits and pieces of memory around. VLM is faster on larger operations, as it has packet burst.

NETX generally (though not always) eats up a bigger chunk of conventional/UMB memory; with VLM, you may find yourself with more free conventional memory, depending on machine configuration.

Back up one workstation and upgrade it. Beat on it and try out all of your software and make sure it's working perfectly before you roll it out. Chances are it will work once you figure out all the new stuff, but there _are_ still some apps that either won't work at all with VLM or require some adjustments to your configuration. You definitely want to find out about these before rolling VLM out to your workstations.

Also, make sure your 3.11 server is up-to-date on the packet burst, packet signatures, large internet packets (if applicable), and LAN drivers. If it isn't running PBURST, you won't get packet burst working and you'll probably notice a slight _drop_ in performance when in reality you should notice an _improvement_. If you don't have all of the updates for packet signatures, then make sure you disable them entirely at the server, or else all hell will break loose. LIP isn't going to make a difference unless there are some clients who need to go through a router to get to your server. And get the latest LAN drivers because packet burst is going to increase the stress on your server and there have been plenty of people posting here that setting up packet burst exposed weaknesses in the old LAN drivers they'd been using.

NETX is in the past. VLM is the future.

[Thx S.M.D.]

I.2 Sample NET.CFG for conventional NETX shells

Net.cfg is the preferred shell configuration file and replaces the obsolete Shell.cfg. Most troubles using net.cfg are from incorrect syntax, spelling, and punctuation (just the things you loved in school).

Important points. Major section headings are flush left, and their qualifying minor clauses must be indented. The word "protocol" is used twice in completely different and unrelated ways; beware. "Protocol" major sections are for programs which locate the section by the name after the word protocol; subclauses are for that program. The numbers 8137, 0800 etc. are for the indicated protocol kinds only, never to be mixed or used with other kinds. 8137 is only for IPX. Minor clause Bind .. is needed only if two or more logical board choices are available for a given protocol. There can be NO originality in the construction of these lines; if it's not documented then don't say it.

For more details on NET.CFG, see Kermit Project file MSKERM.BWR at:

    	ftp://watsun.cc.columbia.edu/kermit/a/mskerm.bwr
    OR
    	ftp://netlab2.usu.edu/kermit/mskerm.bwr
    For Netscapers:
    	ftp://netlab2.usu.edu/sys/anonftp/kermit/mskerm.bwr

    # Example file NET.CFG for conventional shells (MS-DOS)
    #
    # A "#" in column 1 or a ";" symbol makes what follows on that line a
    # comment. Do not try to use ":", "*" or "rem" as a comment character.

    # The following PB buffers entry is only applicable to the elicit BNETX

    PB buffers=6
    show dots=on
    signature level=0

    # Use only if more that one indented "protocol IPX..." line exists
    protocol IPX
    	bind #1

    # Use only if more that one indented "protocol IP..." line exists
    protocol KERMIT
    	bind #1

    # Below is for Novell's Lan WorkPlace for DOS
    Protocol TCPIP
    	PATH SCRIPT     d:\lwp41\net\SCRIPT
    	PATH PROFILE    d:\lwp41\net\PROFILE
    	PATH LWP_CFG    d:\lwp41\net\HSTACC
    	PATH TCP_CFG    d:\lwp41\net\TCP
    	ip_router       129.123.1.254
    	ip_netmask      255.255.255.0
    	ip_address      129.123.1.145
    	tcp_sockets     16
    	udp_sockets     8
    	raw_sockets     1
    #       nb_sessions     4
    #       nb_commands     8
    #       nb_adapter      0
    	nb_domain       usu.edu
    #       bind slip_ppp

    Link Support
    	Buffers 7 1500
    	MemPool 2048

    Link Driver NE2000
    	Frame Ethernet_II
    	Port  360
    	Int   5
    	Protocol IPX    8137    Ethernet_II
    	Protocol IP     0800    Ethernet_II
    	Protocol ARP    0806    Ethernet_II
    	Protocol RARP   8035    Ethernet_II

    Link Driver SLIP_PPP
    	DIRECT  YES
    	BAUD     9600
    	OPEN    ACTIVE
    	TCPIPCOMP       VJ
    	PCOMP   YES
    	PORT    3F8
    	INT     4
    	FRAME   SLIP
    #       FRAME   PPP
    	Protocol        IP      0800    SLIP

    link driver IPTUNNEL
    	gateway         129.123.1.123

I.3 Sample NET.CFG for VLM redirectors

    # Example file NET.CFG for VLM redirectors
    # Don't forget to say  LASTDRIVE=Z  in CONFIG.SYS!
    # Comments begin with a ; or a line starting with a #

    # Following 6 lines for a 3C507 on a particular machine
    Link Driver  3C507
    	Int 10
    	Port 320
    	Mem d0000
    	Frame Ethernet_802.3
    	Protocol Ipx 0000 Ethernet_802.3
    ;
    # Following 4 lines for a 3C507 on a particular machine
    Protocol IPXODI
    	Bind 3C507
    	SPX Connections         = 5
    	IPX Sockets             = 20
    ;
    NetWare DOS Requester
        Auto Reconnect          = OFF     ; OFF=Do not load auto.vlm
        Average Name Length     = 8       ; Shrinks connection table
        Cache Buffers           = 4       ; 0=Removes cache (default pretty
    				      ;   good)
        Cache Writes            = Off     ; ON=Faster writes but lost data
    				      ; integrity if there's a crash.
        Checksum                = 0       ; 0=OFF=speed up high quality links
        Connections             = 8
        Dos Name                = MSDOS
        First Network Drive     = F
        LIP Start Size          = 1500
        Load Conn Table Low     = Off
    ; Recommend trying defaults for the load low pair shown below
    ; [with low loading giving best performance but least low memory]
        Load Low CONN           = On      ; OFF=Connection table in high memory
        Load Low IPXNCP         = On      ; OFF=Put IPX material in high memory
        Load Low NETX           = Off
        Load Low REDIR          = Off
        Local Printers          = 1
        Long Machine Type       = IBM_PC
        Max Tasks               = 50
        Message Level           = 3
        Message Timeout         = 540
    ; Name Context is read for DS only.
    ;    Name Context           = "O=USU"   ; ? Joe ?
        Netware Protocol        = NDS,BIND
        Network Printers        = 3
        Pb Buffers              = 1
        Pburst Read Window Size = 128
        Pburst Write Window Size= 64
    ; Preferred server is read for Bindery only.
        Preferred Server        = _Your_Server_Name_Here_
    ; Preferred Tree is read for DS only.
    ;    Preferred Tree         = _Your_Tree_Name_Here_
        Print Buffer Size       = 64      ; 0=Disables PrtSc CAPTURE, saves 64b
        Print Header            = 64
        Print Tail              = 16
        Read Only Compatibility = On
        Show Dots               = On
        Signature Level         = 0       ; 0=Don't load security.vlm
        True Commit             = Off     ; OFF=let server buffer writes

    ; VLM SELECTION, *** ORDER SENSITIVE ***
    ; For Bindery include bind and netx, omit nds.
    ; For Directory Services include nds, omit bind and netx.
    	use defaults=off        ; OFF=Use explict list of vlms that follow
    	vlm=conn.vlm            ; Connection tables
    	vlm=ipxncp.vlm          ; NCP over IPX
    	vlm=tran.vlm            ; Transport services worker
    	vlm=security.vlm        ; Security, optional
    ;        vlm=nds.vlm            ; DS, NCP Directory Services
    	vlm=bind.vlm            ; Bindery, NCP
    	vlm=nwp.vlm             ; Transport services worker
    	vlm=fio.vlm             ; File I/O
    	vlm=general.vlm         ; General support routines
    	vlm=redir.vlm           ; Redirector
    	vlm=print.vlm           ; Print services, optional
    	vlm=netx.vlm            ; Bindery, shell compatibility
    ;        vlm=rsa.vlm            ; DS, RSA encryption, optional
    ;        vlm=auto.vlm           ; DS, autoreconnect/retry, optional
    ;        vlm=nmr.vlm            ; Managment responder, optional

    Netx
    	show dots=on

    ## Below this line material (board drivers) is the same as for NW 3.11
    ## net.cfg. Please do not trash with unrelated commands.

    Link Support
    	Buffers 7 1500
    	MemPool 2048
    	 etc. as for regular shells.

[Thanks to H.K. and Joe D. for this info]

I.4 Tuning the performance of the NetWare DOS Requester

I.4.1 General Information

When tuning the performance of the NetWare DOS Requester, there are generally 2 goals (or a blend of both): Maximum speed and Minimum memory footprint.

NOTE: The following is for version 1.20 of the Requester, which ships with NetWare 4.1. NetWare 4.02 ships with 1.10, right ? If you don't use 1.20 yet, then I suggest you upgrade to it. You should get files VLMUP3, NWDLL2 and WINDR2 at your favorite ftp.Novell.COM Mirror. Use the 1.10 docs as a reference.

I.4.2 Memory handling

As you might read on the NOVELL@listserv.syr.edu list, the NetWare DOS Requester is a network requester which uses the DOS Int2F redirection interface. VLM.EXE only creates the environment for the modules that actually provide the functionality, i.e. the .VLM files.

When VLM.EXE starts, it creates 3 segments:

      -  Startup segment [in real mode memory]
      -  Global segment [in real mode memory or Upper Memory Blocks (UMBs)]
      -  Transient segment [in XMS or EMS]

VLM loads a part of the .VLM files in the StSeg but most code goes into the GSeg or TSeg, depending largely on settings in the net.cfg file.

The StSeg is cleaned up when VLM has initilized the GSeg and TSeg and the .VLM's are loaded in it. VLM does the memory management and the swapping of .VLM code from TSeg into GSeg - this takes some time and thus speed.

The "Load Low" parameters in the net.cfg file determine if that module is loaded in Tseg (= Off) or in GSeg (= On). GSeg gives best performance since it is within the (real mode) 1024 KByte memory boundary but it depends on the amount of UMB's you have available.

Play with these, you can change net.cfg settings, unload VLM (VLM /U), re-load and then check memory footprint (mem /c |more), VLM memory status (VLM /d |more) and performance using Perform2.

I.4.3 Module loading tuning / general tips

For maximum speed on directory searches, you should keep IPXNCP in GSeg by using "Load Low IPXNCP = On" in the net.cfg.

For better performance on NETX calls, keep NETX in the GSeg.

For better performance on small files, keep REDIR also GSeg.

For a better overview, don't use the "Load = ....VLM" line.

I.4.4 Packet tuning

This generally means tuning NCP Packet Burst and LIP.

"Pb Buffers = 1" sets packet burst On, 0 sets it Off.

The "Cache Buffers" line determines the amount of packet buffers. You can increase these for speed but it costs GSeg space. The "Read Window" and Write Window sizes are the amount of packets that will pass until an "ack" is required, you should play with these to see the results, they highly depend on buffering of the NIC's that you use.

The LIP start size helps when you use routers in your net, set it to the maximum packet size your net can handle. This prevents the Requester from testing your LAN/WAN on the maximum LIP size it can use.

Another tip regards NCP searches. I found that the Requester performs better on searching through directories when you increase the "Maximum Outstanding NCP Searches" console set parameter from the standard value of 51 to say, 200 or 300. On NetWare 4.x servers you can use SERVMAN NLM to play with these parameters, but on NetWare 3.x you have to work with SET commands, and put the right one in your NCF file manually.

[Thx H.K. & S.M.D.]

I.5 An Example STARTNET.BAT for use with the VLM Redirector

    	@echo off
    	set nwlanguage=ENGLISH
    	lsl.com
    	ne2000.com
    	ipxodi /d
    	vlm /mX /v4 /c=c:\nwclient\net.cfg
    	@echo on

    Notes: /d  omits diagnostics responder, saves memory
           /mX puts shell in eXtended memory, /v4 is extra verbose
    	   during loading
           /c  is path to net.cfg in case there's confusion

[Thx Joe D.]

I.6 Sample Appletalk entries in AUTOEXEC.NCF

Here are portions of two autoexec.ncfs for two file servers that appear in the same zone. Lots ofmacs and printers and AppleShare servers appear in this zone as well:

    file server name GORILLA
    ipx internal net 80e3c201

    load appletlk net=10006 zone={"CIRCA II"}
    load ne2000 port=300 int=3 frame=ethernet_snap  name=public_lab_apple
    bind appletlk to public_lab_apple net=0-0
    load afp

    file server name whale
    ipx internal net 80e3c202

    load appletlk net=10007 zone={"CIRCA II"}
    load ne2000 port=300 int=3 frame=ethernet_snap  name=public_lab_apple
    bind appletlk to public_lab_apple net=10004-10005 zone={"CIRCA II"}
    load afp

Note that file server WHALE is defining zone information while file server GORILLA is learning it.