
-------------------------------------------------------------------
NOV-VLM.DOC -- 19951222 -- Email thread on Virtual Loadable Modules
-------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Fri, 7 Jan 1994 08:37:50 +0100
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: PC Tools and VLM 1.1
To: Multiple recipients of list NOVELL <NOVELL@SUVM.SYR.EDU>

Terry,

>I just upgraded a Gateway 486/33 VLB system running DOS 5.0 with a
>3Com 3c509 card to version 1.1 of the VLMs.  I started having a couple
>of problems when using PC Tools Desktop.  None of these problems
>occurred with PROGMAN.
>
>1) When I exited and restarted Windows, the system told me that my
>Desktop was in use by another user.  I could either select another
>desktop office or reboot the system.
>
>2)  Sometimes when I restarted Windows, the startup would fail saying that it
>could not find krnl386.exe even when I was in the windows\system directory.
>
>3)  CPS File finder started giving me GPFs in nwnetapi.dll.
>
>I started hacking on my system to find out what the problem was.  I
>started reinstalling things, including Windows and PC Tools for
>Windows.  I then installed vlm 1.02 and then upgraded everything to
>1.1.  With 1.02 installed things were fine.  When I upgraded to 1.1, I
>had the same problems again, except the GPFs.  Those did not return.
>(I was more careful to make sure that I only had one version of the
>DLLs this time.  CPS does use some of the old DLLs with their tools.)
>At that point, I started removing things.  I removed Smartdrive,
>emm386, my Intel Satisfaction drivers, increased files to 80 stacks
>to 9,256, and nothing seemed to help.  Just out of a fluke, I removed
>share.exe from autoexec, and everything was fine!  I came back to work
>where I am also running 1.1 of the VLMs and loaded share.exe here
>under DOS 6.0 and things were fine!  BTW: The problems exist whether
>or not I load the network drivers.
>
>Any clues as to what the problem is with share.exe in DOS version 5.0?
>Anyone think that upgrading the machine to DOS 6.2 would solve the problem?
>
>I have already spent far too much time on this problem, but I do think
>I will try the upgrade to DOS 6.2 and see if that solves the problem.  Any
>suggestions would be appreciated, but otherwise, just be warned. . .

Send *detailed* information & verify it with Kirk Baum <KBaum@Novell.COM> or
Ben_Hendrick@Novell.COM. Kirk is part of the VLM development team and Ben is
part of the support department and is responsible to hand out bugs to the
enigineers who write/debug the software.

They are *very* willing to fix bugs in they're software, they do a great job
in customer support.

------------------------------

Date: Sat, 2 Jul 1994 22:39:43 -0600
From: Joe Doupnik <JRD@@CC.USU.EDU>
Subject: Re: VLM.EXE in high memory?

>I expect to be told to RTFM...but can someone tell me how to convince
>VLM.EXE to load into a UMB?  The readme files I've got don't seem to
>address the issue.
>
>I'm being pushed to move us from NETX to VLM use, and my initial tests
>show that VLM.EXE winds up in conventional memory no matter how I invoke
>it (with or without a LOADHIGH command, and certainly with enough UMB
>space for it to fit).
>
>A part of the problem is that I'm not the resident NetWare specialist:
>he's out for a while, and my part of this is the design of our standard
>configuration package for all our users.  That's why I'll happily
>accept a response of RTFM if someone will just tell me which FM to R.
-------------
	Don't even dream about loading VLM.EXE high. Leave it in conventional
memory as it's designed to be. Recall, VLM.EXE is mostly a bunch of pointers
to the real workers (the .VLM guys) located far far away, and it takes only
4KB of conventional memory.
	Then Read those Fine Manuals to see the command line for VLM.EXE, or
just type VLM /?. See the /mX guy? That means put the .VLMs in extended (not
expanded, please) memory, so leave free say 200KB or so of that stuff.
	If you are hobbled by using only DOS' feeble attempts at memory
management then I wish you luck with the affair. If you use a real manager,
such as say QEMM/386, then there should be no trouble finding room for
everything, and that means the approx 40KB region labeled "UMB" (just
a label, not a definition) used by the VLMS as a workspace under the 1MB
barrier.
	Something to keep in mind on memory management: one size definitely
does not fit all.
	Joe D.

------------------------------

Date: Mon, 4 Jul 1994 00:29:14 GMT
From: Joe Morris <jcmorris@MWUNIX.MITRE.ORG>
Subject: Re: VLM.EXE in high memory?

>>I expect to be told to RTFM...but can someone tell me how to convince
>>VLM.EXE to load into a UMB?  The readme files I've got don't seem to
>>address the issue.

>Add the switch /MX to force VLM to load into extended memory.
>VLM /MX
>does the trick.

>If you type the name of the .EXE file followed by /? you will usually get
>the available switches for the program.

That was one of the first things I tried, and the /MX switch appears in
the cheat sheet it produces in response... but:

The /MX switch seems to be loading the individual *.VLM files into
extended memory, but VLM.EXE itself still resides in conventional memory,
even if it was invoked with the command LOADHIGH VLM /MX .  Or at least
the output of MEM /D shows it in conventional memory, with mucho less memory
used than shows as the "largest free upper memory block".

------------------------------

Date: Mon, 4 Jul 1994 06:54:07 GMT
From: Roger Foss <edbrfo@SIO25.UIO.NO>
Subject: Re: VLM.EXE in high memory?

Look *closely* at the MEM /C output.  It probably states that VLM uses
40k, of which 5k is below 640k!  The /MX switch is what VLM.EXE defaults
to anyway, so it won't help much.  All the .VLM files are loaded into
extended...

------------------------------

Date: Thu, 7 Jul 1994 02:50:32 GMT
From: "Stephen M. Dunn" <stephen@BOKONON.UUCP>
Subject: Re: VLM.EXE in high memory?

$That will allow those particular vlm components to load high.  I believe their
$default is to load into conventional memory.  However, I warn you that if you
$do this your performance will drop.

   This is one of the things I like so much better about Novell's DOS
requester as compared to their shells - there's so much more room for
fine-tuning.  With the shell, you can go for all-out speed with lots
of memory usage (the late BNETX), normal operation (NETX), and two
varieties which sacrifice speed for low conventional RAM usage (EMSNETX
and XMSNETX).

   With the requester, you can tune where it loads VLMs, three different
packet burst parameters, whether IPXNCP and the connection table load
high (more free memory, less speed) or low, just which little bits
and pieces you can load (don't need printer redirection?  No problem;
don't load it!), etc.

   I just wish they'd get around to making it as stable on my machine
as BNETX 3.32 is.  I understand BNETX causes problems in some environments,
but it doesn't in mine.  VLM 1.10/1.11 does cause problems.  So which
one does Novell say I definitely should not use, and which one does
Novell suggest I should use?

   Go figure.  We've had VLM 1.0, 1.02, 1.10, 1.11, and probably a
couple of other minor releases in there that I have forgotten about,
and it's still only beta-quality software.

------------------------------

What I find anoying on VLM 1.x compared to BNETX (3.31 in my case),
is its slow directory read's.
VLM is really slowwwww with utilities that scan a directory tree, for
example Jon Glaser's Mwatch utility, that checks the SYS:MAIL/...
directory tree for *.cnm (PMail ) files.
Bnetx flies here, VLM jurks, even with extended tuning on cache
buffers, pburst window size etc.

------------------------------

Subject: Re: VLM's

>Has anyone used the Novell *.VLM's to connect to more than 8 Netware
>3.11 file servers? If so, could you send me a copy of your configuration? I
>am trying to connect to more that 8 3.11 servers but I am getting
>a message about exceeding 8 connections....

In your NET.CFG file, under the Netware DOS Requester section, put a line
that says Connections=xx, where xx is the maximun number of servers you want
to be able to connect to. I would also recommend adding another line in the
same section that says Average Name Length=yy, where yy is the average file
server name length of the servers you will be attaching to (this saves RAM).

You have probably already tried the above settings, but there is something
that the documentation doesn't tell you, the Login and Map and Attach
commands that ship with 2.x and 3.x are hard coded to only allow up to 8
connections. In order to go beyond 8, you must use the utilities that ship
with Netware 4.x. There is no ATTACH.EXE, instead use the command LOGIN /NS.
The /NS stands for No Script, and causes LOGIN.EXE to behave like the old
Attach command.

Sean Stanton

------------------------------


Subject: Re: VLM's

>Has anyone used the Novell *.VLM's to connect to more than 8 Netware
>3.11 file servers? If so, could you send me a copy of your configuration?
>I am trying to connect to more that 8 3.11 servers but I am getting
>a message about exceeding 8 connections....

The problem exists with the LOGIN utility not the VLM's.  The VLMs have a
configuration parameter that can be set up to 50 connections.  Put
CONNECTIONS = (some number) in the DOS REQUESTER section of your net.cfg.

This may fix the problem but if you are using 3.11 login utilities you
will have a problem.  They do not understand more than 8 connections.
Get the latest login from netwire or the Novell ftp site and it will work
with more connections.

Note: you will have the same problem with other utilities (eg map, attach, etc)

Kirk Baum

------------------------------

Date: Fri, 7 Jan 1994 07:58:18 -0600
From: Joe Doupnik <JRD@@CC.USU.EDU>
Subject: VLM 1.1, DOSUP9
To: Multiple recipients of list NOVELL <NOVELL@SUVM.SYR.EDU>

	Renewed interest in VLM shell components suggest a few brief notes.

	The latest VLM suite is version 1.1, available in files
	netwire\novfiles\DOSUP9.EXE     (normal distribution, ftp.novell.com
					 and official mirrors thereof)
	odi\vlm11\VLM11.EXE             (advance copy, netlab2.usu.edu and
					 sjf-lwp.novell.com only, will vanish)
DOSUP9 had a decent documentation file readvlm.txt to assist with configuration
information, and this list's FAQ has additional material. Pictures and spiffy
fonts are available in the NW 3.12 manuals: big archive file nw312d8.zip in
directory netwire\document\corppubs\nw312.
	VLMs are replacements for NETX. They require the ODI support material
of IPXODI and your board's MLID (driver in ODI-speak). With a little care
about loading IPXODI and your MLID into upper memory blocks and using the
/mX switch on the VLM.EXE command line the footprint of the shell in 640K
memory becomes as small as 4KB. Token Ring systems may require more, but
my place is all Ethernet so I can't help with TRN. VLM.EXE must be in 640K
memory.
	A carefully constructed NET.CFG file is needed to govern matters
on the client. Note that the preferred comment character in NET.CFG this
season is a semicolon (;) rather than it and/or a sharp sign (#).
	VLM 1.1 is as fast as, or typically faster than, NETX or the old
withdrawn BNETX. Packet Burst technology is built-in. Some tuning can help,
and some hints are in the FAQ and in my quicky file dsktests.txt in directory
apps on netlab2.usu.edu.
	Novell Directory Services (NW 4) is supported only by VLMs. VLMs
are suitable client shells for NetWare 2, 3, and 4 servers.
	VLMs operate as a formal DOS Redirector located one level below the
top of DOS, rather than an Inteceptor above DOS. Thus DOS filename rules
are first enforced by DOS and then VLMs see the results; interceptors can
invent new rules and pass the dregs to DOS. Novell has been extremely
successful with the older interceptor tactic (having provided the notion
of subdirectories in DOS 1.0, before they appeared in DOS). Today's mixed
operating environment says we should have fewer variations, and thus with
VLMs we have a redirector, lastdrive=z, and the Lan Manager style notation
\\server\volume\what\not\stuff. (Can we spell Windows NT? Good.)
	VLMs are not yet fault free (what is?) but version 1.1 is pretty
good. Doubts have been expressed about printing, some MAP ROOT usage, and
with some third party programs (Central Point Software most recently).
Whether these are VLM problems or not remains to be seen. However, this is
a good time to get warmed up on VLMs in preparation for converting client
stations in due course.
	Joe D.

------------------------------

Date: Mon, 29 Aug 1994 16:12:10 +0200
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: VLM slows throughput

>After much dillegence and reading of the FAQ, mail, and The Manual, I've
>successfully installed VLM drivers on my workstation.  Everything works
>beautifully, and I've recovered 43K of DOS memory.  Yeah!
>
>However,  I had run throughput tests using IOZONE (Thanks Joe D.) before
>installing VLMs (i.e. with NETX).  Running subsequent tests after installing
>VLMs shows a dramatic drop in the throughput.  As much as 50%.  The initial
>tests were done every hour on the hour for an entire day.  I reference the
>NETX throughput value for the particular time I'm checking the VLMs IO.

Some things to check:
-  Are you running Netware 3.11 ? If so, use pburst.nlm 2.02 on the
   server(s), get PBURST.EXE from ftp.novell.com.
-  Which version of VLM are you using ? 1.00, 1.02 where horribly
   buggy, use 1.10 from DOSUP9 with VLMUP2 to get 1.11.
-  Get the latest versions of Himem.sys/emm386 or Qemm.
-  Use my net.cfg as example:
;
;       Algemene Net.cfg (VLM)
;
Link Driver 3C507
	Int 5
	Port 300
	Mem C8000
	Frame Ethernet_802.3
	Protocol Ipx 0000 Ethernet_802.3
;
Protocol IPXODI
	Bind 3c507
	Ipx Sockets             = 40
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = Bind
	Load Low Conn           = On
	Load Conn Table Low     = On
	Bind Reconnect          = On
	Connections             = 8
	Average Name Length     = 16
	Max Tasks               = 64
	Checksum                = 0
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 10
	Cache Writes            = Off
	Pb Buffers              = 6
	Pburst Read Window Size = 128
	True Commit             = Off
	Local Printers          = 0
	Network Printers        = 3
	Print Buffer Size       = 64
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Show Dots               = On
	Preferred Server        = ZEUS
	Long Machine Type       = COMPAQ
	Dos Name                = MSDOS
;

------------------------------

Date: Tue, 4 Oct 1994 10:56:17 GMT
From: Rick Troha <rickt@NWSUP.NORTH-OLMSTED.OH.US>
Subject: Re: 3.12 problem

>	I have a problem with my workstation. when I booted up my machine,
>the computer echoed:
>	The VLM.EXE file is pre-initializint the VLMs.......
>and then it got hung up .
>	Can any one of you tell me what went wrong????

If you load VLM.EXE with the /V4 parameter, it might tell you what
went wrong. It'll probably say something like "A file server could
not be found".

------------------------------

Date: Tue, 11 Oct 1994 08:53:07 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: NETX vs. VLM

>>>    There is a rumor going around that Novell is still having
>>>problems with the VLM's to the point that they will issue a new
>>>version of NETX.  Has anyone else heard anything like this?  Did I
>>>miss a press release somewhere?  Is this known to be completely
>>>false?
>
>This is an interesting rumor... but it is not true.  Novell will not be going
>back to Netx technology.  The VLMs v1.20 are on Compuserve and Netwire right
>now.  They are the current release of the VLMs and we are working on a new
>version.  The main problems that people see with the VLMs is that they are a
>redirector rather than a shell.  This limits them to the capabilities of DOS.
>Some of these limitations will be addressed in furure versions.  The VLMs are
>here to stay, the Netx Shell is a thing of the past.
>Kirk Baum, kbaum@Novell.com
-----------
	Well, there we have it from a source who ought to know.  Netx is out,
VLMs are the current strategic direction.  Goodness knows what will occur
when Chicago/Win95 arrives in 1997 or so.  I have hints but my lips are not
watchable (sealed).  IPX.OBJ is now doubly deceased.
	To get the full VLM suite I've purchased the US$99 site license
(that is indeed US$99 to cover everyone, a bargain, and it includes winsock
for LWP/DOS), and then applied the current updates from netwire\novfiles.
VLM v1.20 is faster and more bug free than v1.1x.  And the files are still
marked internally as pre-release.
	Thus as we list regulars advise new members about shell vintages
we should urge them to acquire and deploy the VLMs.  I am not sure how
non-US sites go about getting the equivalent of the $99 Dos/Windows upgrade
kit so perhaps a Novell person (Janet?) can give hints to the list.
	Joe D.

------------------------------

Date: Tue, 11 Oct 1994 13:42:07 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: VLM's

>Can someone give me details for where to download the VLM's and
>installation procedure? I found the 1.20 update, but I need the original
>install.
>------------
	Contact Novell [ 1-800-Netware in the States ] and ask for the
DOS/Windows update kit at an educational site license cost of US$99.
I can't speak for availability or price outside the US. That gives you
a lot. For example, below is my local redistribution directory for this
material (omitting details of many subdirectories). Futher updates to
VLMs are in netwire\novfiles, and to LWP/DOS core TCP/IP stack are in
netwire\novlib\01.
	That's US$99 for the entire site, not per server or per client.
We have mentioned this item very many times on the list.
	Beware of one gotcha here. The ODI Install program flunks if it
can't find an existing ODI board driver. Cure is to create and invoke
a simple ODI client to placate the install program.
	Please save this message so we do not have to repeat it.
	Joe D.

 Directory of O:\NWCLIENT.VLM
READ     ME            982 04-12-94   8:01a << from me
NET      CFG         4,009 04-11-94   8:02p << from me
STARTODI BAT           264 04-11-94   5:42p << from me
OPTIONS  TXT         8,632 04-12-94  12:16p << from me, NET.CFG options, all
WSDOS_1      <DIR>         04-11-94   4:25p
WSDOS_2      <DIR>         04-11-94   4:27p
NWCTCPIP 41  <DIR>         04-11-94   4:29p
WSDRV_2      <DIR>         04-11-94   4:30p
NWTCPUP      <DIR>         04-13-94   8:10p

 Directory of O:\NWCLIENT.VLM\WSDOS_1
_RUN     OVL         2,815 01-19-93  10:33a
AUTO     VL_         3,003 12-09-93   1:06p
BIND     VL_         3,401 12-09-93   1:05p
CMPQ_RUN OVL         2,815 01-19-93  10:33a
CONN     VL_         3,239 12-09-93   1:04p
INSTALL  CFG         4,990 12-20-93   8:45a
FIO      VL_         7,928 12-09-93   1:06p
GENERAL  VL_         3,298 12-09-93   1:06p
IBM_RUN  OVL         2,815 01-19-93  10:33a
WSDOS_1             32,606 12-21-93  10:00a
INSTALL  EXE        86,105 11-30-93   2:59p  << gotcha producing program
IPXNCP   VL_         6,421 12-09-93   1:04p
IPXODI   CO_        17,537 10-07-93   4:52p
LSL      CO_        11,574 09-10-93   3:48p
NDS      VL_         3,735 12-09-93   1:05p
NETX     VL_        10,410 12-09-93   1:06p
NWUNPACK EXE        38,640 11-30-93   1:47p
NMR      VL_         6,527 12-09-93   1:05p
NWP      VL_         4,107 12-09-93   1:05p
PRINT    VL_         5,167 12-09-93   1:06p
REDIR    VL_        10,233 12-09-93   1:06p
RSA      VL_         7,365 12-09-93   1:07p
SECURITY VL_         2,791 12-09-93   1:05p
TRAN     VL_         1,092 12-09-93   1:04p
TEXTUTIL IDX         9,170 12-10-90   1:37p
VLM      EX_        15,578 12-09-93   1:03p
RPL          <DIR>         04-11-94   4:26p
NLS          <DIR>         04-11-94   4:26p


 Directory of O:\NWCLIENT.VLM\WSDOS_2
ET       IN_         1,773 07-27-93   3:24p
NETWARE  DR_        69,830 11-24-93   9:02a
NETWARE  HL_        23,191 06-17-93  12:17a
NOVELL   BM_        41,006 04-17-92  10:53a
NOVLOGO1 BM_        10,731 01-28-92   4:58p
NWCALLS  DL_        65,530 11-02-93   2:30p
NWIPXSPX DL_        15,392 11-02-93   5:47p
NWGDI    DL_        29,366 11-19-93   4:50p
NWLOCALE DL_        19,287 11-02-93   6:12p
NWNET    DL_        90,022 05-18-93   1:00p
NWPOPUP  EX_         2,335 10-28-93   8:06a
NWPSRV   DL_        63,922 05-14-93   5:29p
NWRCON   PI_           223 01-03-92   1:25p
NWADMIN  INI           100 01-20-93   5:19p
NWUSER   EX_         2,212 10-28-93   8:12a
PNW      DL_        50,696 12-08-93  10:43a
TASKID   CO_         4,929 01-22-93  10:47a
TBMI2    CO_         9,013 06-03-93   4:36p
VIPX     38_        10,410 10-11-93   9:00a
VNETWARE 38_         5,433 11-19-93   8:39a
HRMIB    EX_        16,519 12-02-93   3:19p
HRMIB    IN_           319 11-22-93   5:51p
ODINSUP  CO_         7,177 02-23-93   8:58a
ROUTE    CO_         3,939 05-11-93   8:59a
TSA_SMS  CO_         9,738 10-18-93   4:37p
DOSNP    EX_         7,374 05-26-92  11:00a
NETBIOS  EX_        13,531 11-19-93  11:05a
PNW      VL_         6,654 12-09-93   1:06p
WSDOS_2             22,293 12-20-93   4:14p
SAMPLNET CF_           438 08-17-93   1:00p
NWUNPACK EXE        38,640 11-30-93   1:47p
NLS          <DIR>         04-11-94   4:28p

 Directory of O:\NWCLIENT.VLM\NWCTCPIP.41
$RUN     OVL         2,662 01-09-92   7:27a
IBM$RUN  OVL         2,662 01-09-92   7:27a
SYS$ERR  DAT         9,170 12-10-90   1:37p
SYS$HELP DAT        14,092 01-29-91   2:39p
SYS$MSG  DAT        25,161 01-08-92   1:35p
README               2,703 12-29-93   9:12a
INSTALL  EXE       246,066 09-28-93   5:00p
INSTALL  MSG        10,136 09-28-93   5:00p
SCRIPT   HLP        23,234 09-28-93   5:00p
SCRIPT   MSG         5,686 09-28-93   5:00p
MSTRING  MLH         8,675 09-28-93   5:00p
NWCTCPIP PSF         3,174 09-28-93   5:00p
WS_CONF  CPF        12,869 09-28-93   5:00p
WS_ODI   CPF        13,252 09-28-93   5:00p
WS_TCPIP CPF        13,062 09-28-93   5:00p
WS_DONE  CPF         5,200 09-28-93   5:00p
WS_LWP_D CPF         9,478 09-28-93   5:00p
WS_LWP_W CPF         3,892 09-28-93   5:00p
NET          <DIR>         04-11-94   4:29p

 Directory of O:\NWCLIENT.VLM\NWCTCPIP.41\NET
BIN          <DIR>         04-11-94   4:29p
ODI          <DIR>         04-11-94   4:30p
SAMPLE       <DIR>         04-11-94   4:30p

 Directory of O:\NWCLIENT.VLM\NWCTCPIP.41\NET\BIN
DIALUP   EXE        19,676 09-28-93   5:00p   << yes, SLIP_PPP dialer
IPTUNNEL EXE        13,740 09-28-93   5:00p
LWPCON   EXE       257,504 09-28-93   5:00p
LWPCON   HLP        44,238 09-28-93   5:00p
LWPCON   MSG        14,334 09-28-93   5:00p
PING     EXE        20,448 09-28-93   5:00p
PING     MSG           426 09-28-93   5:00p
RARPD    EXE        24,330 09-28-93   5:00p
RFCNBIOS EXE        57,847 09-28-93   5:00p
SNMP     EXE        32,374 09-28-93   5:00p
TCPIP    EXE        41,188 09-28-93   5:00p
VERSION  EXE        23,071 01-25-91   5:34a
VTCPIP   386        10,557 09-28-93   5:00p
YESNO    EXE         6,189 09-28-93   5:00p
SLIP_PPP COM        36,765 09-28-93   5:00p   << yes, SLIP and PPP
SLIP_PPP INS         3,711 09-28-93   5:00p
WLIBSOCK DLL        43,530 09-28-93   5:00p
WINSOCK  DLL        34,640 11-12-93  10:20a   << yes, winsock
NOVASYNC EXE         4,672 09-28-93   5:00p

------------------------------

Date: Wed, 12 Oct 1994 12:46:33 LCL
From: "A. Grant" <ag129@UCS.CAM.AC.UK>
Subject: Re: NETX vs. VLM

>The main problems that people see with the VLMs is that they are a
>redirector rather than a shell.  This limits them to the abilities of DOS.

You cannot blame the VLMs' unpopularity on DOS.  Much of it is due
to poor quality control from Novell and their inability to deliver
working code more than a year after the VLMs were introduced.
There are several ongoing problems, particularly relating to
coexistence with other redirectors such as MSCDEX and NFS.  I have
been waiting since BrainShare 93 to deploy the VLMs in our 15,000-user
environment, and I'm still waiting.  I have had several 1.20 beta
sets over the last few months and _still_ there are trivial problems
that ought to have been shown up by internal regression testing.

Also the fact that Windows NETWARE.DRV has changed incompatibly
is a piece of really bad design.  In some environments that alone is
sufficient obstacle to a phased gradual migration from NETX to VLM.

------------------------------

Date: Wed, 12 Oct 1994 09:10:35 +0100
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: VLM's [2]

>	Contact Novell [ 1-800-Netware in the States ] and ask for the
>DOS/Windows update kit at an educational site license cost of US$99.
>I can't speak for availability or price outside the US. That gives you
>a lot. For example, below is my local redistribution directory for this
>material (omitting details of many subdirectories). Futher updates to
>VLMs are in netwire\novfiles, and to LWP/DOS core TCP/IP stack are in
>netwire\novlib\01.
>	That's US$99 for the entire site, not per server or per client.
>We have mentioned this item very many times on the list.
>	Beware of one gotcha here. The ODI Install program flunks if it
>can't find an existing ODI board driver. Cure is to create and invoke
>a simple ODI client to placate the install program.
>	Please save this message so we do not have to repeat it.
>	Joe D.

One thing Joe, for those who have the capability (sounds like US
foreign policy {;->), meaning a CDROM player and pay for the NSE-
PRO have the entire client kit on CD, file CLIENT.EXE, about 7.5 Mb
large. It includes all disk's in full extract files. Just extract
them to a floppy & you have it ...for free.

------------------------------

Date: Tue, 18 Oct 1994 12:03:46 EST5EDT
From: "Donald E. Hanley" <SYSDEH@CS.SYR.EDU>
Subject: Re: Netx.exe versu VLM's

>> Would I see benefits by changing some of the workstations
>> from Netx.exe to VLM?
>
>I've tried VLM's several times and I didn't like it!! It causes all kinds of
>peculiar problems like sudden deaths, Windows conflicts, etc. The fact that
>Novell updates the VLM faster than I can update my socks also indicates that
>VLM's aren't quite as stable as the tell you, to say the least.

From one perspective, one could say that this is a non-issue; you
really do not have a choice.  As we have seen on this list, Novell
has moved to VLMs, and NETX development has stopped.  NetWare 4.x,
for example, requires VLMs on the client station if you want more
than bindery emulation.

However, there are also positive reasons for moving away from NETX.

I have been using VLMs since v1.1 was released (more than 6 months),
and my experience has been that they are VERY stable with very few
incompatibilities.

My machine is set up so that it is trivial to switch between
NETX and VLMs (thanks, MicroSoft for DOS 6.x!), and I invariably find
that if I have problems while running one of them, when I reboot with
the other, the problems do not go away.  In other words, it seems
that in a Windows + NetWare + (NETX or VLMs) environment, the
first two factors are far more important determinants of reliability
than the third.

As to memory requirements, since the VLMs are configurable, it is
possible to set them up to use less memory, not more, than NETX.
Moreover, VLM performance can also be better, thanks to pburst and
Large Internet Packets.

Although the VLM implementation still has some shortcomings (the fact
that the current version of NETWARE.DRV does not support both VLMs
and NETX comes immediately to mind), it is, in my opinion, a much
better foundation on which to build than the NETX shell.

------------------------------

Date: Thu, 27 Oct 1994 08:09:06 +0100
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: Novell Client Kit for DOS/Windows

> I just installed the Novell Client kit for DOS/Windows on my PC.
> I was using ODI and a shareware winsock and could use Mosaic & WS_ftp
> with no problems.  Now that I am using Novell's winsock, when I use
> mosaic, I get an error "Socket: Connection been refused"

> Link Driver SMCPLUS

Watch out for leaving spaces between lines of major headings, some
modules (especially Mlid's) can be picky while parsing NET.CFG.

>	INT 5
>	PORT 300
>	MEM d800
	^^^^^^^^
	Shouldn't that be B8000 ?

>	Frame Ethernet_II
>	Protocol IPX 0 ETHERNET_802.3
>	Frame ETHERNET_802.3
>
>NetWare DOS Requester
>	FIRST NETWORK DRIVE = F
>	NETWARE PROTOCOL = NDS BIND
	^^^^^^^^^^^^^^^^^^^^^^^^^^^
You have a 3.11 server, right ? Then NDS will be useless & can be
omitted, which save memory, leaves "NetWare Protocol = Bind".

>show dots=on
>local printers=0
>cache buffers=40
 ^^^^^^^^^^^^^^^^
As discussed just a few message ago, these sometimes slow things
down, try a value of 0 & see what it does, it *will* save a lot of
memory.

>file handles=64
 ^^^^^^^^^^^^^^^
This isn't used anymore, VLM's are DOS re-director beasts, you need
to set related stuff in the config.sys, files =....

>I am running on a 3.11 netware server with a direct internet
>connection.

Do you have PBURST.NLM 2.02 from file PBURST.EXE running on your 3.11
server?  Make sure you select the correct packet signature level on the
server & on the client side.  "Signature Level = 0 " in NET.CFG file yields
max performance, no security.vlm loaded, but also no packet signature
thing enabled, only for systems in a safe environment, not classrooms!!!

------------------------------

Date: Fri, 4 Nov 1994 15:24:30 +0100
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: [3]: WfWG and NETX 3.32

>>JD>>When starting Windows for Workgroups with NETX 3.32 loaded, the logo
>>JD>>appears on the screen then the system hangs.  A warm boot clears it.
>>JD>>This occurs whether the station is logged in or not.  If NETX is not
>>JD>>loaded, the problem does not appear.  Normal network operations are
>>JD>>normal when logged in.
>>JD>>
>>JD>>Conditions:
>>JD>>
>>JD>>NetWare 3.11
>>JD>>Dell 486DX/33 with 8MB RAM
>>JD>>ODI drivers from DOSUP9
>>JD>>	LSL.COM
>>JD>>	SMCPLUS.COM
>>JD>>	IPXODI.COM
>>JD>>	NETX.EXE v3.32
>>JD>	<part omitted>
>>JD>----------
>>JD>	The shared memory of the SMC Ethernet board is not protected
>>JD>against memory management at both DOS level and in Windows. You must
>>JD>exclude= it in both places.
>>JD>	Joe D.
>>
>>I now use VLM and a complete net.cfg (Not that three line one that
>>assumes all defaults are oK) and I do not have these problems anymore. I
>>have heard VLM has its own memory management functions, but I do not
>>have that from an unimpeachable source.
>
>I am tring to get my WFWG to work as of right now I lock up at the logo
>screen.  I am using VLM version 1.11 with IPXODI and ODIPKT and WINPKT
>I have configured the WFWG to use microsoft and novell 4.10 shell some-
>one said I in a message a few days ago that they had to use ODIHLP
>but for the life of me I cannot find it!
>
>Was it you and if so where can I get ODIHLP
>
>My startnet.bat
>
>CD \ NWCLIENT
>SET NWLAUGUAGE=ENGLISH
>LSL		Version 2.12 Link Suport Layer
>E21ODI		Version 1.01 Cabltron NIC Driver
>ODINSUP	Version 2.12 ODI Support Module
>NET START	WFW'S NETWORK REDIRECTOR
>ODIHLP		WFW'S ODI/NDIS MAPPER <--BUT WHERE DO I FIND IT
>IPXODI		Version 2.12 IPX SPX Driver
>DOSNP		Version 2.12 Dos Named Pipes
>VLM /MX /V4	Version 1.10 Netware Dos Redirector
>NETBIOS	Version 3.16 NetBios Driver
>STPIPX		Version 1.0 SNMP/IPX
>ODIPKT 1 96	Version 3.0 TCPIP ODI Packet Driver
>STPUTP		Version 1.0 SNMP/IP
>WINPKT 0x60	Version 1.02 Windows IP Socket Support
>CD \

Upgrade to VLM 1.20 pre-rel, files: VLMUP1 VLMFX11 NWDLL1 WINDR1, it
includes the correct files to work with WfWG


>*********
>*Net.Cfg*
>*********
>Link Support
>	Buffers 20 2000
	^^^^^^^^^^^^^^^
	Wow! that's way too much, try 6 1600

>	MemPool 2048
>	Max Boards 6
>;
>Link Driver E21ODI
>	PORT 380
>	MEDIA PRIMARY
>	INT 5
>	MEM D0000
>	FRAME Ethernet_802.3
>	FRAME Ethernet_II
>	FRAME Ethernet_SNAP
>	FRAME Ethernet_802.2
>	Protocol IPX  0000 Ethernet_802.3
>	Protocol IP   0800 Ethernet_II
>	Protocol ARP  0806 Ethernet_II
>	Protocol RARP 8035 Ethernet_II
> ;
> Protocol IPX
>	BIND 1
	^^^^^^
Remove this, Protocol IPXODI is fine.

>;
>Protocol ODINSUP
>	BIND e21odi
>	BUFFERED
>;
>Protocol STACK IPXODI
	  ^^^^^
	  ?? {;-''

>	Bind E21ODI
>	Ipx Sockets     = 60
>	Spx Connections = 60
>;
>Protocol TCPIP
>	Bind E21ODI
>	PATH SCRIPT     C:\NET\SCRIPT
>	PATH PROFILE    C:\NET\PROFILE
>	PATH LWP_CFG    C:\NET\HSTACC
>	PATH TCP_CFG    C:\NET\TCP
>	ip_address      129.108.111.111
>	ip_router       129.108.1.1
>	ip_netmask      255.255.0.0
>	tcp_sockets     8
>	udp_sockets     8
>	raw_sockets     1
>	nb_sessions     4
>	nb_commands     8
>	nb_adapter      0
>	nb_domain       0
>;
>NetWare DOS Requester
>	VLM = WSSNMP.VLM
>	LOAD LOW WSSNMP = ON
>	VLM = WSTRAP.VLM
>	LOAD LOW WSTRAP = ON
>	VLM = WSREG.VLM
>	LOAD LOW WSREG = ON
>	VLM = WSASN1.VLM
>	LOAD LOW WSASN1 = ON
>	VLM = MIB2IF.VLM
>	LOAD LOW MIB2IF = ON
>	VLM = MIB2PROT.VLM
>	LOAD LOW MIB2PROT = ON
>	VLM = RSA.VLM
>	VLM = PNW.VLM
	^^^^^^^^^^^^^
Do you also run Personal Netware ?? If not, remove this.


>	VLM = AUTO.VLM
>	SET STATION TIME = ON
>	USE DEFAULTS = ON
>	MESSAGE LEVEL = 4
>	NETWARE PROTOCOL = NDS,BIND,PNW
			   ^^^^^^^^^^^^
			   Which Netware version(s) are you using ?
			   Use only the ones you want support for.

>	CONNECTIONS = 8
>	AVERAGE NAME LENGTH = 48
>	MAX TASKS = 254
>	LOAD LOW CONN = ON
>	LOAD CONN TABLE LOW = ON
>	CHECKSUM = 1
>	LARGE INTERNET PACKETS = ON
>	LOAD LOW IPXNCP = ON
>	HANDLE NET ERRORS = ON
>	PREFERRED SERVER = UNET_FS_9
>	MESSAGE TIMEOUT = 540
>	SIGNATURE LEVEL = 0
>	CACHE BUFFERS = 64
>	CACHE BUFFER SIZE = 1024
>	CACHE WRITES = ON
	^^^^^^^^^^^^^^^^^
The cache buffer thing usually eats memory & slows things down. The
Buffer size is automaticlly set to maximum the hardware can handle,
no need for changing. Try the following & check speed:

Cache Buffers = 0
Cache Writes = Off


>	TRUE COMMIT = ON
>	PB BUFFERS = 10
>	PBURST READ WINDOW SIZE = 64
>	PBURST WRITE WINDOW SIZE = 64

>	PRINT HEADER = 1024
>	PRINT TAIL = 1024
	^^^^^^^^^^^^^^^^^
Ouch, this will blow PRINT.VLM's global segment size! Use more
moderate values like:

Print Header = 32
Print Tail = 16


>	PRINT BUFFER SIZE = 256
	^^^^^^^^^^^^^^^^^^^^^^
	Same as above, I use 128 max.

>	NETWORK PRINTERS = 3
>	LOCAL PRINTERS = 0
>	FIRST NETWORK DRIVE = F
>	SEARCH MODE = 5
>	READ ONLY COMPATIBILITY = ON
>	SHOW DOTS = OFF
>	DOS NAME = MSDOS
>	LONG MACHINE TYPE = IBM_PC
>	SHORT MACHINE TYPE = IBM
>	AUTO RECONNECT = ON
>	AUTO RETRY = 10
>	AUTO LARGE TABLE = ON
>	BIND RECONNECT = ON
>	BROADCAST RETRIES = 255
>	BROADCAST SEND DELAY = 255
>	BROADCAST TIMEOUT = 255
>	MOBILE MODE = 255
>	RESPONDER = ON
>	MINIMUM TIME TO NET = 0
>
>Desktop SNMP
>	enable monitor community = any
>	monitor community = "public"
>	enable control community = specific
>	control community = "public"
>	enable trap community = specific
>	trap community = "public"
>	sysName = "LTC_HELP"
>	sysLocation = "LTC"
>	sysContact = "bac9%utep@utepvm.utep.edu"
>	snmpEnableAuthenTraps = on
>
>Transport Provider IPX
>	trap target = ab123456:0123456789ab
>
>Transport Provider UDP
>	trap target = 129.108.111.111

------------------------------

Date: Wed, 9 Nov 1994 18:00:58 +0000
From: Richard Letts <R.J.Letts@SALFORD.AC.UK>
Subject: Re: Batch File Test for VLMs vs NETX

>>Anyone out there have any idea of a utility to test whether or not the
>>VLMs are loaded.
>>
>>My site currently runs a mixture of VLMs and NETX on the clients.  I am
>>attempting to load virus protection from the LOGIN.BAT file but the
>>location of the executables changes depending on whether the
>>requestor or the shell is used.  When I use VLMs the executables are in
>>F:\TOOLKIT and when I use NETX they are in F:\LOGIN\TOOLKIT.
>>
>>I would like to run the batch file (LOGIN.BAT) to load the executables
>>from the correct location, depending on which network drivers are being
>>used.
>
>There is a utility called ISVLM (includes C source).  Unfortunately,
>I don't remember where I picked it up, but it was probably from one
>of the Novell mirrors.

I wrote it; check out ftp.salford.ac.uk
		/network/utils/isvlm.txt
		/network/utils/isvlm.zip

------------------------------

Date: Wed, 8 Feb 1995 13:11:48 +0100
From: Henno Keers <mailbox@ZEUS.ICE.NL>
Subject: Re: PBURST: NETX vs VLM 1.2 - WHAT'S wrong with this picture ?

>After reading about pburst I thought I'd play around. Here's the scoop:
>Does packet burst really make things faster? I'm not sure - here's what
>I found.....what's wrong with this picture?
>
>During each of the following tests I copied 195 files totalling 8,138,113 bytes
>to a sub-directory below the current directory on the file server.  The files
>ranged from 49 bytes to 1MB in size.
>
> SHELL USED           XCOPY                NCOPY           COPY
>
>NETX 3.32          135 seconds          172 seconds    188 seconds
>VLM 1.2            151 seconds          177 seconds    202 seconds
>
>VLM net.cfg had a "pb buffers=10" - all other defaults were used.
>Please remember that the use of xcopy does not preserve all of the
>file attributes (system, ro, etc.) so I might expect it to be a LITTLE slower.
>But WHY do the above tests show that the use of pburst does not
>increase throughput?
>
>SAME FILES COPIED TO LOCAL HARD DRIVE ON WS:
>
>                     XCOPY                NCOPY              COPY
>NETX 3.32          61 seconds           85 seconds         67 seconds
>VLM 1.2            77 seconds          111 seconds        101 seconds

Jim, a few thoughts cross the brain here:
-  Which version of NetWare are you using on the server?  3.11 (then
   you need to do some upgrading) ? or 3.12  ?
-  Don't expect that the NetWare DOS Requester runs fast with
   default parameters. It just doesn't. You have to tweek it. My
   example is below, try that. It's for bindery servers only.
   Remember that the "PB Buffers" line setting only sets Packet
   Burst on or off (0 or 1). The buffers are set by "Cache buffers".
   You also should play with the "Load Low ...." parameters to
   set some .VLM's to transient or global segment for more speed.
;
;       Algemene Net.cfg (VLM)
;
Link Driver 3C507
	Int 10
	Port 320
	Mem d0000
	Frame Ethernet_802.3
	Protocol IPX 0000 Ethernet_802.3
;
Protocol IPXODI
	Bind 3C507
	SPX Connections         = 5
	IPX Sockets             = 20
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = Bind
	Load Low CONN           = On
	Load Low REDIR          = Off
	Load Low IPXNCP         = On
	Load Low NETX           = On
	Load Conn Table Low     = Off
	Connections             = 8
	Average Name Length     = 8
	Max Tasks               = 50
	Checksum                = 0
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 4
	Cache Writes            = Off
	Pb Buffers              = 4
	Pburst Write Window Size= 64
	Pburst Read Window Size = 128
	LIP Start Size          = 1500
	True Commit             = Off
	Local Printers          = 1
	Network Printers        = 3
	Print Buffer Size       = 64
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Show Dots               = On
	Preferred Server        = ZEUS
	Long Machine Type       = IBM_PC
	Dos Name                = MSDOS
;

------------------------------

From: Joe Doupnik <JRD@@CC.USU.EDU>
Subject: Re: What the heck are VLMs ???

>>This is the ugly name given to the nifty new shells for use with NetWare 4.x
>>They are faster and take up less memory than the NETx and automatically load
>>into extended memory. Unfortunately you need a Ph.d to figure out which 'bits'
>>you can disable. eg in a NW3.11 environment there is no need to load the
>>Directory Services modules [big]
>
>How do you do this?  I am using vlm instead of netx in a 3.11 network, but I
>noticed that vlm loads up a bunch of stuff, thus ending up with about the
>same amount of low memory usage as netx!  Despite the ability to use
>extended memory, vlm loads low and occupy in toto about 45 kb.

	Oh really? So how come I use only 4KB of lower memory and everthing
else is either above the 640K mark (UMB style) or in extended memory for VLMs?
That 4KB is VLM.EXE's tiny vector area so it can reach over to extended (or
expanded, your choice) memory. The MLID and IPXODI can be loaded high, and
most of us do so.

	Here is the operative part of the net.cfg I'm using at this moment,
with only 4KB of Novell sitting below 640KB (DOS 6 here):

	# File NET.CFG for NW 4.0, from Joe Doupnik
# Don't forget to say  lastdrive=z  in config.sys!

Netware dos requester
	network printers=1      ; shrinks print.vlm
	average name length=24  ; shrinks connection table
	print buffer size=0
	read only compatibility=on
	first network drive=n
	preferred server=edu-usu-netlab2
	preferred tree=USU-401-TREE
	name context="O=USU"
; VLM selection, order sensitive -
; For Bindery include bind and netx, omit nds.
;   Also preferred server is read for Bindery only.
; For Directory Services include nds, omit bind and netx.
;   Also preferred tree and name context are read for DS only.
	use defaults=off        ; off=use explict list of vlms which 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 is the same as for NetWare 3.11

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

And the startodi.bat file which fires it up:
@echo off
set nwlanguage=ENGLISH
c:\qemm\loadhi /r:1 c:\nwclient\lsl.com
c:\qemm\loadhi /r:2 c:\ne2000.com
c:\qemm\loadhi /r:2 c:\nwclient\ipxodi /d
c:\nwclient\vlm /mX /v4  /c=c:\nwclient\net.cfg

Joe D.

------------------------------

Date: Wed, 4 Oct 1995 09:09:39 +0100
From: Steve_Rooke@mh.blyth.com (Steve Rooke)
To: netw4-l@bgu.edu
Subject: Re: vlmup3 & client problems with wfw311

>I've had a problem with vlmup3.exe on approximately 3 machines:
>
>I was trying to load VTDA.386 in my SYSTEM.INI, and according to it's readme
>file, I was supposed to load at later versions of the lsl and ipxodi,
>specifically the ones that came with VLMUP2. Given that we are now at
>VLMUP3, silly me, I figured that would be fine. On *most* machines, it is
>fine, but I have three machines, all different (but they are all the same as
>at least one other machine that *does* work, seemingly the same config) and
>I can't figure out for the life of me why they aren't working...If I revert
>back to very old versions of the lsl and ipxodi, I'm back in business. If it
>helps, the versions that do work are LSL.COM 2.01 and IPXODI.COM 2.10.

I have an installed base of about 30 PCs running Windows for WorkGroups
(WfWG), some with Lan Work Place 4.2, and all connected to NW 4.1 & 3.1x.
I also have had problems with trying to match pieces of client kit and get
them all to work together.  I found that there was a lot of dependency
between them and found the only reliable (and simple) way round this is to
install the complete client kit.  NW 4.1 came with a good version that
incorporated the vlmup3 kit (I believe) and all the supporting stuff.
Otherwise, if you have NW 3.12 or 4.x, you can legitimately download the
very latest client kit 1.2a (later than the one supplied with 4.1) from:

ftp://ftp.novell.com/pub/netwire/novfiles/client.kit/doswin/

This is six disks worth with the last one containing the TCP/IP stack as
supplied with the 'Netware Client for DOS and Windows' package or with LWP
(accept you only get the PING utility).  This is fully WINSOCK compliant
and will work with a whole lot of free, or cheap, TCP/IP software out
there.

I found that I can just re-install this new client kit on top of the old
installation, including LWP, and thereby upgrade the the whole client PC in
one go.  Just make sure that the installation directory points to the
location of your current NWCLIENT directory.  It will use your current
NET.CFG file during the install and so you shouldn't loose any settings.
You might want to backup this, the INI files, and your autoexec/config
files first but I've had no problems here.

Regarding WfWG and NW Client Kits with VLMs. There are two versions of
WfWG, version 3.1 can only use an NDIS transport layer and causes a few
problems here.  I had a user with this on his PC and wanted to install LWP
4.2.  The way to do this is to install the NW client and setup the ODINSUP
shim layer.  Make sure you remove the calls to startup all the Microsoft
MLID/IPX support layers too.  The biggest drawback of this is that it will
NOT work with VLMs only NETX.  It works but you don't get NDS and I
wouldn't recommend it.

WfWG 3.11 is a completely different kettle of fish and will work well with
the the ODI & VLM stuff.  To setup you have a number of options. Assuming
you are upgrading a straight Windows 3.1 installation, just install the NW
client kit first and then upgrade to WfWG 3.11.  Half way through it will
ask you if you want the networking to be attached to the Novell ODI layer
and you want to say yes.  This should all then work fine and is the easiest
way to do it.

If you are setting up a completely fresh WfWG 3.11, and have no previous
versions of Windows on the machine, perform the WfWG install first and say
NO to the question about installing a network in the setup program.  When
finished, install the NW client kit with Windows support.  Run Windows and
go to the Network Setup utility in the Network group.  Hit the Install
Microsoft Windows Network and set it to add additional network, Novell
NetWare [Workstation Shell 4.0 and above], click OK.  Setup the Sharing
section as needed and then select the Drivers section.  Click Add Adapter
and select IPXODI Support Driver [whatever you need] [ODI/NDIS3].  This
should automatically add the Microsoft NetBEUI and the IPX/SPX Compatible
Transport with NetBIOS protocols, if this is not the case you will have to
add them via the Add Protocol button.

Just an aside here, I don't know what this IPX/SPX Compatible Transport is
for here as NetWare works fine without it (having it's own driver) and the
WorkGroup sharing should use the NetBEUI for it's transport.
Unfortunately, if you delete this driver, your WorkGroup functions fail.
This is no big deal to leave it there accept if you want to run NASI COM
port redirection (ie from NW Connect), where it needs to be disabled to get
this to work.  If anyone has a fix, or explanation for this, I'm all ears.

Accept these changes and select OK from the Main Network Setup screen.  It
will ask you if you want to install new drivers for the Netware side but
just say NO.  You will be asked to provide disks 7 & 8 from the WfWG
distribution (or the CDROM).  It should all work together now.

If you have an existing WfWG 3.11 setup and want to change over to the NW
client kit with VLMs, first you need to go to the Network Setup utility and
select No Windows support for networks.  Make sure there are no Network
drivers either and then save all these changes away before eventually
rebooting the machine.  You should now have a 'straight' Windows
installation and should install the NW client kit as above and then follow
the steps in the previous setup.

One problem you may encounter is an error when starting windows that gives
error 506 (if I remember correctly).  This is caused but the Microsoft
Network Setup program.  It should just attach itself to the ODI layer and
not need to worry at all about what is underneath, including the MLID.  If
you look in the NET.CFG file you will see a new Link Driver XXXX section,
just delete all that and note the name of your real Link Driver section
(NE2000, 3C503, etc.).  You also only need one Max Boards 4 in the Link
Support section, Microsoft's setup program seems to add one with each
incantation.  Now edit the /WINDOWS/PROTOCOL.INI file and change all the
'XXXX's to the name of your real driver.  There should be one [Link Driver
whatever] section, a data=Link Driver whatever, and a couple of
BINDINGS=whatever entries.  Restart the shooting match and you should be
away.

Check the following:

Your CONFIG.SYS files for WfWG 3.11 should include:

LASTDRIVE=Z
DEVICE=C:\WINDOWS\IFSHLP.SYS

AUTOEXEC.BAT should include a call to STARTNET.BAT.  The latest client kit
installer also adds:

C:\WINDOWS\ODIHLP.EXE

to the STARTNET.BAT file just after loading the VLM.EXE.  Just make sure
that the Microsoft Network Setup has not also added one in the
AUTOEXEC.BAT.  You should also find a call to:

C:\WINDOWS\NET START

somewhere AFTER the CALL STARTNET.BAT in the AUTOEXEC.BAT file.  I think
they have tried to move the ODIHLP call so that it is not started if you
want to run as a remote node using the NW Connect stuff and the different
startup branches are taken in the STARTNET.BAT file.

------------------------------

Date: Fri, 22 Dec 1995 08:49:49 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: novelli: Are VLMs slow ?

Let me go over the files that you sent uuencoded to the list;

>DEVICE=C:\WINDOWS\HIMEM.SYS
>DEVICE=C:\WINDOWS\EMM386.EXE NOEMS RAM
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You don't have any cards with RAM or ROM in this system that needs
eXcluding ?

>DOS=HIGH,UMB
>SHELL=C:\COMMAND.COM /E:1024 /P
>FILES=64
>BUFFERS=15,0
>LASTDRIVE=Z
>DEVICE=C:\WINDOWS\IFSHLP.SYS
>STACKS=9,256

I presume that you have your Windows 3.11 set up to use the
NetWare Workstation Shell 4.x or higher ?


@ECHO OFF
SET NSE_DOWNLOAD=D:\DOWNLOAD\
PROMPT $p$g
PATH=C:\WINDOWS;C:\DOS;C:\NWCLIENT;C:\;c:\windows\nls;c:\windows\syste
SET TEMP=C:\windows\temp
CALL C:\NWCLIENT\STARTNET
LH DOSKEY /INSERT
LH C:\DOS\SMARTDRV.EXE
@ECHO ON

I moved the startnet call to the top so that no tsr's get loaded
before the client kit gets loaded.

I've modified the net.cfg extensively, see below. From the old one I
presume you have one NetWare 4.1 server. I removed the preferred
server line because you are using NDS. There are still settings
missing in the Link Driver section, please specify these since
default values might not be correct. You also have specified 2 frames
in this section, you might want to change over your net to 1 frame
since clients can only run IPXODI via one at a time.

;
;	New Net.cfg (VLM)
;
Link Driver INTEL595
	Int ?
	Port ??
	Mem ?????
	Frame Ethernet_802.2
	Frame Ethernet_802.3
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = NDS,BIND
	Load Low CONN           = On
	Load Low REDIR          = On
	Load Low IPXNCP         = On
	Load Low NETX           = On
	Connections             = 8
	Average Name Length     = 8
	Max Tasks               = 50
	Checksum                = 0
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 8
	Cache Writes            = On
	Pb Buffers              = 1
	Pburst Write Window Size= 32
	Pburst Read Window Size = 32
	LIP Start Size          = 1500
	True Commit             = Off
	Local Printers          = 0
	Network Printers        = 3
	Print Buffer Size       = 16
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Show Dots               = On
	Preferred Tree          = CESIPE
	Name Context            = "Cesipe"
	Long Machine Type       = IBM_PC
	Dos Name                = MSDOS
;

------------------------------

Date: Fri, 22 Dec 1995 09:04:07 +0100
From: Henno Keers <Mailbox@ICE.NL>
Subject: Re: Are VLMs slow ? No They just don't work! [2]

>My appologies to everyone for the tripple post!
>Netcom must be having problems with the E-mail 'cause it took a LONG
>while before I saw the original message echo back!!!
>
>Anyway, We are using Netware 3.11 and 3.12 with Ethernet, IPX/SPX
>protocols.  We are also using both Coax and 10Base"T" level 4.  The
>NICs are a mix, SMC, 3Com 3C5X9, Cabletron and Kingstons'.
>
>We do not use PBurst on the File Servers as per Netware
>Bulletin...forgot the bulletin number.

??? Packet Burst works overhere almost for 3 years, upgrade your 3.11
server to be compatible; i.e.;

-  Use the Packet-burst NLM from PBURST.EXE
-  Upgrade your .LAN driver NLM's to be 3.12/4.x compatible, copy
   it to SYS:SYSTEM.
-  Upgrade the .LAN driver support files (you need LSLENH.NLM to
   make NetWare 3.11 to work with the 3.12/4.x drivers) from file
   LANDR4.
-  Modify the autoexec.ncf of the 3.11 server to something like:

FILE SERVER NAME ZEUS
IPX INTERNAL NET C14E8814
LOAD LSLENH
LOAD PBURST
LOAD "lan driver" SLOT=4 FRAME=ETHERNET_II NAME=IPX_NET
BIND IPX TO IPX_NET NET=C14E8800
SET NCP PACKET SIGNATURE OPTION = 1

-  Use the PUBLIC and SYSTEM files of the 3.12 server on the 3.11
   server.

>When ever ANY workstation is
>converted to use VLM's, it will lock up the users on either network.
>It won't matter which File Server I try to access or which
>workstation/NIC I use.... as soon as the VLM portion of the login
>fires up..... everyone freezes....

Check you net.cfg for the NCP packet signing option, take a look at
an example net.cfg below. I have set it to 0, if you have higher
values set, then you might have the problem that the servers will
refuse a connection to your net.

;
Link Driver 3C5X9
	Int 5
	Port 300
	Frame Ethernet_II
	Protocol IPX 8137 Ethernet_II
;
NetWare DOS Requester
	First Network Drive     = F
	Netware Protocol        = BIND
	Load Low CONN           = On
	Load Low REDIR          = On
	Load Low IPXNCP         = On
	Load Low NETX           = On
	Connections             = 8
	Average Name Length     = 8
	Max Tasks               = 50
	Checksum                = 0
	Signature Level         = 0
	Message Timeout         = 540
	Message Level           = 3
	Cache Buffers           = 8
	Cache Writes            = On
	Pb Buffers              = 1
	Pburst Write Window Size= 32
	Pburst Read Window Size = 32
	LIP Start Size          = 1500
	True Commit             = Off
	Local Printers          = 0
	Network Printers        = 3
	Print Buffer Size       = 16
	Print Header            = 64
	Print Tail              = 16
	Read Only Compatibility = On
	Show Dots               = On
	Preferred Server        = ZEUS
	Long Machine Type       = COMPAQ
	Dos Name                = MSDOS
;

------------------------------

From: RBall84213@aol.com
Date: Mon, 20 Jan 1997 07:42:24 -0500 (EST)
To: floyd@direct.ca
Subject: Comment on document NOV-WIN.DOC

Floyd- An excerpt from the referenced document follows:

<<Current as of 31Jul95:

NWDLL2.EXE     Contains updated Windows DLL (Dynamic Link Libraries) for
workstations using either NETX or the VLMs.
VLMUP2.EXE     Contains updates for the DOS ODI drivers, NETX (v3.32 PTF),
and the VLMs (v1.2x)
WINDR2.EXE     Contains updates for the Windows-Specific drivers.

/sys/anonftp/netwire/novlib/05
NETX33X.EXE    Contains updated NETX file
VLMUP3.EXE     Contains latest IPXODI.COM file v2.20, and LSL.COM file v2.16
WN2DLL.EXE     Contain BSD fix if running in standard or real mode,
ignored if in Enhanced mode (386 mode)

ftp.microsoft.com:
/ (Directory is unknown)
WW0863.EXE     Includes VTDA.386>>

The above is very dated information.  The last VLM update file issued
by Novell was VLMUP4.EXE, and the last separate Windows drivers file
issued by Novell was WINDR3.EXE.  NWDLL2.EXE referenced above
is the last separate Windows DLL update file issued by Novell.  (I think
that the WN2DLL.EXE referenced above is a typo.)  The instructions
included with NWDLL2.EXE directed that Microsoft patch WW0863.EXE
also be applied to the VLM client.

Applying these patches to the client brought the client to VLM
version 1.20b.  Personal (repeated) experience has taught me that
applying the patches to a client required a level of effort equivalent
to applying three typical patches to a NetWare server.

Novell's "Minimum OS, NLM, and File Updates" web page
(http://support.novell.com/search/patlst.htm) includes links to the
current VLM version 1.21 install set:  VLM121_1.EXE through
VLM121_6.EXE.  The TID pages referenced there state that the
VLM121_?.EXE install set replaces update patches VLMUP4.EXE,
NWDLL2.EXE, and WINDR3.EXE.

In my mind, the VLM121_?.EXE install set is preferable.  First,
you are getting a more recent VLM client version.  Also, while
VLM121_?.EXE does build six install diskettes, installing those
six diskettes is by a "no-brainer" install program as opposed to
the manual directory manipulation required by VLMUP4.EXE etc.

My 2 cents.  Rich Ballard  CNA4  KD0AZ

------------------------------

