                                  VLM v1.20
                          
                      VLM v1.20 SHIPS WITH NETWARE 4.10


   The v1.20 NetWare Client for DOS / MS Windows will ship in mid-December as
part of the NetWare 4.10 product, and as a separate red-box product in late
December.

   The December release of the NetWare 4.10 product will not contain the
translated message and read-me files.  NetWare 4.10 with French, Italian,
German, and Spanish (FIGS)  translated files will be released in January. The
NetWare Client for DOS / MS Windows released in December will be a FIGS release
with translated message and read me files.


Product Requirements

   The NetWare DOS Requester (VLMs) is the requester component of the NetWare 
16-bit Client for DOS and MS Windows. VLM is the primary technology that 
provides access to NetWare 4.x servers from the DOS environment. A set of goals
and features was established for the 1.20 version of this product prior to its
development. These goals and features included:

     Improve performance through the optimization of current algorithms.

     Increase reliability through extensive testing with 3rd party applications
     and through extensive Beta testing.

     Provide hooks and features to enable the integration of mobile products.

     Provide capability to load VLMs without active network connection in
     support of mobile products.

     Clean up existing critical discrepancies in the product.

     Provide support for multiple-connection auto-reconnect.

     Ability to load REDIR.VLM into low memory made available in order to
     improve I/O performance.

     Provide better support for EOJ, Lock Retries, and other NET.CFG parameters
     not fully handled.

     Implement the Force First Network Drive parameter for the NET.CFG.

     Handle any outstanding issues to ensure the successful deployment of the
     VLMs in Japan with the release of NetWare 3.12J and PNW J.

     All the goals and requirements for the v1.20 VLMs were general. The
     primary focus was to provide a stable VLM client. Customer concerns
     regarding size and performance were addressed within the constraints of
     the current design.
  

New Features


   The new features and enhancements provided with the v1.20 VLMs provide the
customer with a tested, stable platform. The primary goal of the v1.20 VLMs was
to provide a highly reliable DOS client for release with the NetWare 4.10
product. Additional features and enhancements were included to support other 
NetWare products, and to meet customer needs.

   Feature enhancements made to the v1.20 VLMs which concentrate on new NET.CFG
parameters include:

     Load Low REDIR = Off, On (default Off)
       This parameter is provided to improve small I/O performance. There is an
       increase of conventional memory  usage in exchange for the increased
       performance. Loading REDIR.NLM low uses  additonal conventional memory.

     Load Low FIO = Off, On (default Off)
       This parameter is provided to provide additional tuning in favor of
       performance over size. By loading fio low additional  conventional
       memory is used.

     Load Low NETX = Off, On (default Off)
       This parameter is provided to provide additional tuning in favor of
       performance over size. By loading netx low additional  conventional 
       memory is used.
	
     Force First NetWork Drive = Off, On (default Off)
       This parameter is provided to force the re- establishment of the first
       network drive when logging out from any other network drive. Please note
       that the connection to the first network drive is based upon the default
       drive connection at the time the logout was performed.

     LIP Start Size = 0; 576-65535 (0=off)
       This parameter is provided to improve performance, at connect time,
       across multiple hop routes when one segment of the network has a smaller
       packet size than the local routes, but a larger packet size than the
       minimum of 576 bytes. This new algorithm dramatically improves connect
       time utilization of the wire.

       The following scenerio is provided to demonstrate  the changes in the
       LIP negotiation algorithm:  A given network consisting of 4KB token ring
       segments, capable of handling 1500 byte packets, and positioned  at two
       distant locations are connected by a WAN. Large Internet Packets must be
       used to maximize the throughput of the link. Both scenarios, with and 
       without Lip Start Size, are described below  to demonstrate the new
       algorithm.

       Before: Prior to implementing this parameter, the LIP negotiation
       algorithm consumed the link. The server and the client are both on a 4KB
       capable segment. During the initial negotiation sequence, the client 
       negotiates an initial packet size of 4KB. The server responded to the
       request with an acceptance of the 4KB packet. The initial LIP negotiate
       sequence sends out three 4KB LIP echo packets to the server. No response
       is received, so another three packets are sent to the server, this time 
       at 576 bytes, to ensure that the route is valid. Three echos packets are
       received back from the server. A binary search is then performed to
       identify the optimal LIP size for the given route. The mid between 576
       bytes and 4KB is then sent out in a group of three to the server. If
       that is not successful, then the mid between that number and 576 bytes
       is attempted. If that works, the binary search continues until the
       maximum bound is successful. Over 60KB of data is sent across the WAN
       link to negotiate the WAN link. The time to establish the link can also
       be painfully slow across the WAN.

       Now: The algorithm has been modified in several ways. Primarily the
       administrator can specify the initial LIP negotiate size. If LIP Start
       Size = 1500 was set in this example, the optimal configuration for the
       link can be quickly established with minimal data flow across the WAN.
       In this instance, one 1500 byte packet would be sent to the server. The
       server would echo the 1500 byte packet back to the client. The client
       would then send a 1600 byte packet (1500 bytes + 100 bytes) to the
       server. This packet would not echo back to the client. The addition of
       the 100 bytes to the packet is used to determine if the server is local,
       or if it is being sent  across the WAN. If the server is local, the
       standard negotiation would proceed, the following 4KB packet would  be
       successful. In this case, the echo packet would not be returned. Only 
       one packet was sent during the initial echo request. To determine if
       the link is unreliable, an additional two packets of 1600 bytes each
       are sent to the server. No echo is received back from the server. The
       optimal size is then set at 1500 bytes for the link. A total of 3KB is
       sent across the WAN link. A savings of 60KB is realized, as is an
       increase in performance.

     Confirm Critical Error Action = On, Off (def On)
       This parameter is used to turn off the critical action popup in MS
       Windows. This dialog is popped up prior to tearing down a lost
       connection while in Windows, providing the user with the choice to
       attempt retry (and possible auto reconnect) of the last request. This
       parameter ensures that a critical error message is provided in the
       Windows environment. Many applications turn off the Windows critical
       error handling mechanism. This  forces an automatic failure/cancel,
       thus otherwise overriding any chance for the user to retry the
       connection before it is torn down.

     Read Only Compatibility = Off, On (default Off)
       This parameter is not new. It was set to On with the last major release
       of the product. Because this caused problems with many applications,
       this parameter's default is now set to Off.

     Lock Delay and Lock Retry. 
       These two parameters were not fully implemented in past releases. They
       have been implemented and tested for this release.


   New v1.20 VLM features include:

     If the Node address is set to -1, the client does not require the
     presence of a server to complete loading. This capability is provided to
     enable the mobile networking products. This feature works in conjunction
     with the new IPXODI.COM which provides the ability to set the node
     address to the -1 value.  You use this feature with the new IPXODI.COM,
     which allows you to set the node address to the -1 value by placing
     twelve Fs in the node address parameter in the NET.CFG file under the Link
     Driver heading:

	Link Driver drivername
	   node address FFFFFFFFFFFF


     The LIP negotiation algorithm has been changed to improve negotiation
     speed and decrease throughput.  Groups of three packets had been
     previously used in the negotiation of the maximal LIP size. Two states
     have been defined to reduce the number of packets sent across the network.
     The connection is initially  placed into a "trusted state."  When in this
     state, one packet is sent to the server with one accompanying echo reply.
     If a reply is not received from the server when expected, the client is
     placed into a "non-trusted state." In this state, groups of two LIP echo
     packets are sent from the client. This packet count is less than the
     three packets previously used. This generally results in faster
     negotiation of LIP, and fewer packets going across the wire.

     A hook into the INT 24 handler has been provided to enable link
     handling of mobile products. This permits mobile products to bring down
     any dormant connections, then reestablish them without causing critical
     network errors.

     The NUL device support has been implemented into the V1.20 VLMs. This
     enables such command line commands as If exists NetWare path\NUL ....

     The VLMs have been optimized to work cleanly with multiple redirectors.
     Some of the specific redirectors tested include the redirectors from 3COM,
     Novell NFS Client, and DEC Pathworks.

     Additional video modes are supported for incoming messages.

     A sideband network error reporting mechanism has been implemented
     where appropriate to ensure that network errors are not translated into
     DOS errors.

     The auto retry character has been language-enabled. This permits the
     Auto Retry feature to work in other languages where an R does not
     signify retry.

     Support has been added to enable the Auto Retry feature under MS
     Windows.

     The internal notify code has been optimized to the load time
     performance of the VLMs, and to improve performance during login.
 

Product Limitations


    There are several limitations to the v1.20 VLMs due to architectural
    limitations.  These limitations are being addressed in the design of the
    next release of the VLM. The v1.20 VLM limitations include:

    Maximum path length of 67 bytes. Previously this was a 128 byte path
    length limitation. Due to the redirector implementation of the v1.20 VLMs
    this path length cannot be enhanced because of the limitations of DOS. In
    many cases; however, path length limitations can be overcome by map
    rooting into the directory tree.

    Full command-line Device redirection, where a NetWare path is used (i.e.
    F:\..\AUX), cannot be provided due to limitations imposed by DOS. The NUL
    device support is the only device that has been implemented.

    The VLMs do not match the transaction-speed performance of NETX. Where
    NETX can perform 12 transactions per second, the VLMs can perform only 11
    transactions per second. This performance decrease is due to the
    transition through DOS for each request/reply. The transaction metrics are
    based upon a Clipper application designed to perform small record
    transactions. However, the VLMs meet and out perform NETX in mid-and large-
    sized reads and writes.

    The VLMs are not able to operate in either the private or the global DOS
    sessions of NT and OS/2. These DOS environments do not provide the
    back-end INT 2F support upon which the V1.20 VLMs are built.


Major Fixes


   The major problems fixed in the V1.20 VLMs are listed below. These are
generally problems for which we received a large number of complaints, or
which we identified as being  highly  visible with a high impact upon the
customer.

    Fixes to the VLMs, NetWare Libraries, and Utilities. Fixes were
    coordinated to cleanup connection-related problems. Problems resolved
    included hard counts that did not accurately increment and decrement,
    leaving connections in unpredictable states under specific conditions, and
    licensed connections at the server that were being consumed when they
    should not have been.

    Packet burst code was cleaned up for special-case scenarios where
    fragments could be lost. Also fixed were problems that could present
    themselves in WAN environments.

    EOJ code was fixed to work properly under all conditions.

    Problems related to ensuring the use of proper task IDs for the VLMs
    were fixed, along with problems related to ensuring proper interaction
    with other tasks.

    COMSPEC code was modified to handle command processors other than
    COMMAND.COM.

    The behavior of the temp drive and temp directory handle support
    (Int 21 E2) was also corrected.

    The "Qualify" code paths were modified to ensure proper operation, and
    to improve performance.

    Code associated with the NET.CFG  "Search Mode" parameter was fixed to
    ensure proper operation.

    Auto-reconnect code path was changed to support simultaneous auto
    reconnection of multiple connections.

    The cache buffer segment overflow scenario was corrected. Typically,
    related problems were manifested when using large token ring packets where
    the NET.CFG "Cache Buffers" parameter needed to be backed off to fit
    within the memory available to cache.

    The IPX signature string was added next to the INT 7A vector address to
    emulate NETX behavior.

    Compatibility between NETX and DOS return code was improved.

    Errors related to multiple record lock attempts involving three or more
    stations were corrected.
 
    Problems with use of multiple redirectors, including MSCDEX, were
    corrected.

    NUL device redirection and directory detection on a network drive fixes
    were implemented.

    READ ONLY COMPATIBILITY now defaults to OFF instead of ON to match that
    of NETX.

    Anomalies with batch files involving LOGIN.EXE were eliminated. (Note,
    certain caveats apply here.)

    Network path parsing was improved to act more like that of  DOS.

    Packet timing algorithm problems were corrected to better support slow
    WAN links.

    Packet signature problems related to working over WANs while bursting
    were corrected.

    Related negotiation issues were corrected to enforced checksumming and
    packet signatures at the client when requested.

    Short-lived socket support has been disabled under Windows per the MS
    Windows SDK.

    Support for properly handling broadcasts when VLMs are loaded in
    multiple VMs under Windows was corrected.

    Int 24 error string problem--where garbage was displayed in certain
    circumstances--has been corrected.

    Invalid message formatting caused by the use of an incorrect message
    file has been eliminated through implementation of message file version
    control.

    Renaming files across servers is now properly detected, and the correct
    error is reported.

    The old library function "GetPrimaryID()" call has been fixed, as it
    could have caused problems with specific login and logout sequences.

    Improperly formatted or invalid file name information on Qualify remote
    file name calls is now corrected.

    Both the Set Task Mode and Get Task Mode calls were corrected to ensure
    that the bit is set and placed in the correct segment of memory.


Tidbits


  For faster performance in XMS memory, consider loading REDIR.VLM into low
memory using the new NET.CFG parameter. Performance will then be at a level
similar to that of loading the entire VLMs in conventional memory,  but memory
cost will be substantially lower.

  Consider reducing the memory footprint by: 

    *  Excluding PRINT.VLM if no printing is desired.
    *  Lowering the number of Network Printers if LPT1 is the only captured
       port.
    *  Reducing the number of connections if the client is on a small network. 
    *  Excluding SECURITY.VLM if packet signing is not required.
    *  Excluding those NetWare Protocol modules which are not part of your
       network (i.e., BIND.VLM for bindery-based servers, NDS.VLM for
       Directory Services-based servers, and PNW.VLM for Personal NetWare
       servers).

    Develop an understanding of who is using the Upper Memory blcok (UMB), and
  how it is being used. This is one of the best ways to improve memory
  utilization. VLMs always try to maximize the use of the UMB, but will be
  unsuccessful if other TSR's have already used or fragmented the memory.
  Loading these TSR's after loading VLMs may allow the VLMs to maximize the
  memory use of the UMB area. VLMs need more memory at load time than after
  load time, another good reason to load those TSR's which use the UMB area
  after loading VLMs. 

Note: More information on memory utilization and optimization for the DOS
      Requester can be found in the May 1994 and June 1994 issues of Novell
      Application Notes.


Known Problems


  ** Multitaskers which do not generate unique PSP's across VM's (ie. MS
     Windows defaults to generating unique PSP's, system.ini parameter
     uniqueDOSpsp=TRUE) may see a problem in CONN.VLM, if the following
     circumstances are all present:

       *  Two task are running in different VM's and are assigned the same PSP
          number.
       *  One task terminates while the other is still active.

   NOTE: This may cause an endless loop hang depending on the task allocation
         order in CONN, and the termination order of the tasks.

  ** TSR's which do not use the Idle interrupt (Int28), and which base their
     entire re-entrancy availability for NetWare Int21's (B6h and up) on the
     SDA's InDOSFlag may see some re-entrancy problems. The problem is the
     result of reentering a NetWare Int21 based on the InDOSFlag.

  ** Certain MLIDs (Multiple Link Interface Drivers) may show a problem with
     IPXODI. The issue is with certain NCP's which return more data than has
     been provided in the reply buffer. You may see a timeout / Network error
     when encountering this scenario, although it is very uncommon. If you do
     encounter this error, you can fix the problem by running the latest
     IPXODI.

  ** As mentioned in the Limitations section, some DOS device support may
     differ slightly from local DOS behavior. For example, if an application
     opens device F:\USER\TIM\PRN for printing, the DOS Requester passes the
     request on to DOS. DOS then fails the request because it uses a network
     path. 

  ** AutoReconnect will not work with Signing enabled on a NDS connection (4.x
     server).

  ** AutoReconnect will not work with 3.x servers if the LOGIN.EXE is not a 4.x
     version of LOGIN.

  ** The default login drive is always map rooted. For example, if your first
     Network Drive is F, after loading the VLMs, drive F will show as a
     SYS:LOGIN root mapping (F:>, not F:>SYS:LOGIN).

  ** If a print job is deleted while in an ADDING state, the client terminates
     the capture because it receives a file IO error. This is the same behavior
     as NETX except that no message is printed indicating the failure and
     possibility of a full disk. This lack of a message will be remedied in
     the future.

  ** The DOS Requester relies more on the DOS environment PATH variable for its
     Search drive information than did the old shell. For this reason,
     handling of the PATH needs to be watched closer than with the SHELL.

  ** Error mode still has task-based issues. For instance, Task 1 in VM 1,
     which sets the error mode to 2, may not see the proper error mode behavior
     if Task 2 in VM 2 sets the error mode back to 0.

  ** The DEC Pathworks product can use the standard or enhanced MS Redirector
     in parallel with the VLMs. The MS Redirector has a file problem with file
     execution on RO executables. Microsoft is reported to be aware of this
     problem and working on it. You can avoid this problem by setting the file
     attributes to RW.


