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.