Ver. 1.20 Revision B Release October 1995
VLM v 1.20 Revision B
Product Component Release - Development Notes
The v1.20 NetWare Client for DOS / MS Windows was shipped in
December 1994 as part of the NetWare 4.10 product, and as a
separate red-box product in late December 1994. An update to the
VLM component of the client was provided in May 1995 as a Revision
A update to the Client. This document addresses the Revision B
update to this client, to be released electronically in November
1995.
Again the VLM component of the Client will be the primary focus of
this product update. Some additional updated components will be
added in support of other Novell Products to be released in the
near future.
Product Requirements
The NetWare DOS Requester (VLMs) is the requester component of the
NetWare 16-bit Client for DOS and MS Windows. This product has
been the primary technology that provides access to NetWare 4.x
servers from the DOS as well as Windows environment. The Intel
80286 DOS/Windows based system is the primary target of this
product, however support will continue for Intel 80386 - 80586
systems. The Client-32 product, when released, is the preferred
client for post 80286 systems.
The key reasons for this product update are to:
Improve performance through the optimization of current
algorithms.
Increase reliability by fixing all known discrepancies in the
product.
Provide additional hooks and features to enable the
integration of mobile products, as well as the Network
Connect product..
Customer concerns regarding size and performance were addressed
within the constraints of the current design. This release of the
product continues to focus upon the stability and performance of
the client workstation.
Tuning the Performance
The release of 100 MBit cards introduced new problems to the
performance of Packet Burst on the NetWare 16-bit Client for
DOS/Windows. The VLMs were not sensitive enough to handle this
increase in LAN speed.
In an effort to optimize thruput, the VLMs weighted the windowing
of the IPG (inner packet gap time) over the windowing of the
Packet Burst windows. The VLMs use a 100 ms timer in the
adjustment of the IPG value. The sensitivity of this timer is not
sufficient to provide effective IPG windowing with the 100 MBit
LAN cards.
A new parameter was provided that controlled the maximum value
that the IPG could reach. This provided a forced maximum IPG for
high speed networks, which effectively kept the maximum IPG within
an acceptable range. The parameter is:
MAX IPG = 0-63,257 (default is to not set parameter)
If the maximum IPG is reached, the Packet Burst Read and Write
windows will be adjusted to maximize thruput. Again, the goal is
to maximize the amount of data that can be sent across the network
in a given period of time. This adjustment of the Window and IPG
are dynamic, permitting the continuous dynamic tuning of Packet
Burst.
Fixes introduced in this update to the client, providing a boost
to performance, include:
When attaching to the network, the VLMs now determine if the
initial temporary server is the target. If it is, it will
simply re-negotiate the connection to go licensed.
If any packets were received out of order, the VLMs would
request all packets from the point where they lost sequence.
The VLMs now re-order these packets, and only request any
lost packets.
Fixed cache boundary problems, to improve upon cache hits.
FIO changes implemented to improve large file I/O
performance.
Several fixes have been added to the IPXODI.COM module in support
of the upcoming mobile products. These fixes center around
watchdog issues when on a dialup connection.
Improving the Stability
A fix to VNETWARE.386 has been provided to alleviate the system
hang for Win95 when a restart is performed (available in the file
WINDR3.EXE).
Some of the problems / symptoms fixed in the v1.20 Rev B VLMs are
listed below. All known problems in the VLMs have been addressed.
Several problems in the other components have also been addressed.
With NETX.EXE, the print flags were not reset when a print
capture was deleted. A subsequent capture would
automatically have the print flags set with this behavior.
These flags are reset when a print capture is deleted under
VLMs. A new parameter has been added to the NET.CFG, in
order to provide the behavior some customers have come to
expect:
Reset Printer Flags = ON/OFF
The default for this parameter is OFF. This maintains the
VLMs current behavior, while permitting the NETX.EXE behavior
for those that rely upon it.
In WAN environments, some hardware routers respond to "Get
Nearest Server" for distant servers. This caused the client
to connect to corporate servers in other states and
countries, when a local server was the actual target. The
VLMs now check the hop count of the servers to make sure
its not the router responding.
The Machine Name is now set properly into the global segment,
when the VLMs are loaded into EMS/XMS memory.
The error mode in the Windows DOS Sessions is now instanced.
Changing the error mode in one session does not effect the
error mode of the other sessions.
The Preferred Server ID, Default Server ID, and the Primary
Server ID are now all instanced for each DOS Session within
Windows.
The SetDefaultCaptureFlags call now allows the user to change
the LPT number, as it did in the NETX.EXE client.
Fixed problems with RETRY COUNT and DELAY COUNT, to insure
that opens will attempt the retries and delays as defined by
the parameters.
Under MS Windows, the operating system was passing an error
message as a full file name. This caused a hang of the
system when programs defined in the startup folder on the
net, and not yet available. The VLMs now check for this
phony file name and prevent the hanging condition.
The VLMs will no longer return "Critical error reading device
NETWORK" for un-licensed connections, when they are dropped.
The error codes for renaming a file across volumes has been
changed to be consistent with NETX.
Changes made to provide for checksumming with NWIP support.
Lock delay and lock retries has been fixed to work properly.
Support for INT 21h Function 69h has been added.
Fixes made to insure maximum use of client cache.
Fixed PSP cleanup problems under multiple VMs within Windows.
Fixed NCP packet sizes. Some packets were rejected at the
server when NCP packet checking was enabled.
Improved NETX compatibility in several areas, to insure
behavior consistent with that of NETX.
International product issues resolved, primarily with
Japanese hardware.
Return error if any VLM modules encounter an error during
init time. Error code 11 returned. Provided for customers
using batch file processing to load clients, per customer
requests.
Provide for handling of system devices when passed with a
path. The VLMs strip the path from the device name, then
pass to DOS, to facilitate proper handling by DOS.
Print bugs that could cause a system hang when printing large
files was fixed.
Check for module version strings. VLM.EXE will not allow
prior version modules to be loaded. Checks do not include the
revision portion of the string.
The attached to server message handling has been changed to
support remote boot scenarios.
Configuration Notes
Reducing the Memory Footprint:
Connections = 2-50: 8 default
The VLMs allocate 8 connections by default. Each connection
takes 50 bytes of conventional memory. This parameter has
minimal impact upon the memory footprint.
**Protocol = NDS,BIND,PNW (default)
Protocol = NDS, BIND
Specify only those protocols required. Not loading PNW can
save 2.5 k in conventional memory.
Exclude VLM = PRINT.VLM
Exclude any VLMs not required:
Print = 2.5 k conventional
PNW= 2.5 k conventional
NETX = 4 k conventional
Load Low Conn = Off (default is ON)
Several VLMs are loaded low by default. These modules are
loaded low for performance reasons. Moving these modules to
EMS/XMS can save conventional memory at the expense of
performance. The following modules are loaded low by default
(moving them high saves conventional memory):
IPXNCP = 5,024 bytes
CONN = 3,888 bytes
LH VLM.EXE
The VLMs can be loaded into UMB space, if available. This
provides more base conventional memory for applications.