------------------------------------------------------------------- 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 Subject: Re: PC Tools and VLM 1.1 To: Multiple recipients of list NOVELL 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 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 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 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 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" 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 Subject: VLM 1.1, DOSUP9 To: Multiple recipients of list NOVELL 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 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 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 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 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 04-11-94 4:25p WSDOS_2 04-11-94 4:27p NWCTCPIP 41 04-11-94 4:29p WSDRV_2 04-11-94 4:30p NWTCPUP 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 04-11-94 4:26p NLS 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 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 04-11-94 4:29p Directory of O:\NWCLIENT.VLM\NWCTCPIP.41\NET BIN 04-11-94 4:29p ODI 04-11-94 4:30p SAMPLE 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" 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 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" 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 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 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> >>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 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 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 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 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 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: <> 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 ------------------------------