FILES FOR DOS ODI WORKSTATIONS:
-----------------------------------------------------------------
NOTE: This README file is an explanation of the files contained in this
directory and their usage. More detailed information can be obtained
about many of these files in either the "Workstation for DOS and
Windows" manual (comes with NetWare v4.0 documentation), the "NetWare
ODI Shell for DOS" manual (comes with NetWare v3.11 documentation),
the "Novell ODI for DOS User's Guide.", or the "NetWare Workstation
for DOS" manual.
LSL.COM:
This file implements the Link Support Layer for DOS ODI workstations. It
is the program that is generally loaded first when booting. It performs
a switching function to route packets and allow communication between the
LAN drivers and the communication protocol. The LSL allows one network
board to service several protocol stacks, or several network boards to
service the same protocol stack. It also provides a buffer pool, packet
queuing, administrative services, and timer functions.
IPXODI.COM:
This is Novell's IPX protocol stack for DOS ODI workstations. It is loaded
after the workstations LAN driver. IPXODI.COM takes requests destined for
the network, packages them with transmission information, and hands them
to the LSL.
IPXODI.COM actually contains 3 protocols; IPX, SPX and Remote Diagnostics
Responder. Normally all of these are loaded, but IPX can be loaded by itself
to save memory if the application doesn't require all three. The following
chart shows how to load IPXODI.COM without the other two parts of the file:
TO LOAD TYPE MEMORY SAVED
------------------------------------------------------
IPX and SPX only IPXODI d 3KB
IPX only IPXODI a 9KB
NET.CFG:
NET.CFG is an optional, specialized text file that you can create with any
ASCII text editor. It is not generally needed if you are using the default
hardware options. If you are using non default options, place the file in
in the drive that will be the default drive when the LSL.COM is loaded. If
the NET.CFG file is in the default drive when the LSL.COM is loaded, it will
automatically be read and implemented by the workstation files that use it.
Thus it will have to be removed or renamed if you later chose not use it.
The NET.CFG is responsible for setup and configuration of a network
workstation. Hardware options, other than default, must be set in a NET.CFG
file for DOS ODI workstations. Also if you are using protocols other than
IPX, or multiple frame types, you will need a NET.CFG to load these. You
will also need it if you are using Novell's LAN Workplace.
NET.CFG overrides the SHELL.CFG file settings, and any options set in the
SHELL.CFG file can be specified in the more versatile NET.CFG file. It can
change the operating parameters of the NetWare shell or IPX. You can use it
to change the way the workstation handles packets, print jobs, DOS versions,
and search drives.
Applications such as database, multitasking, or NetBIOS (involved in
peer-to-peer communications or distributed processing) may require parameter
values different from the default values to properly function on the network.
To find out which parameters you might need to modify, consult the setup
reference for each application used on your network.
There are many other NET.CFG options available. These options are defined
in the manuals referenced at the beginning of this document.
LAN.BAT:
This is an example of a file that will load your driver and the other files
necessary to bring up your DOS ODI workstation. It should be on your
workstation boot diskette or hard disk along with NETX, IPXODI, LSL, the LAN
driver for your adapter and any other files you wish to load when booting.
For booting off the hard disk with an existing AUTOEXEC.BAT, place the
statement CALL LAN.BAT in your AUTOEXEC.BAT before any programs needing
network resources. This batch file should work fine for most situations,
but you can modify it as necessary to fit your application.
NETX.COM:
This file is being replaced with NETX.EXE. You will need to delete the
NETX.COM from your boot disk (if present) so that the new NETX.EXE will
be found.
NETX.EXE:
The NetWare shell, NETX, is a TSR that is loaded after the driver and
protocol stack, and attaches you to the network file server. It functionally
lies on top of the workstation operating system, and between the application
layer and DOS. It handles requests made by the application, and determines
whether to pass them to DOS or the NetWare operating system to be serviced.
NETX.EXE may be replaced by the NetWare DOS Requester. The NetWare DOS
Requester is also included on this disk. See READVLM.TXT for futher
information. The NetWare DOS Requester provides several new improvements
over NETX. It does the following:
Supports NetWare Directory Services
Provides a modular architecture that has advantages for current
and future applications
Takes advantage of memory-swapping technology and DOS redirection
capability.
Includes Packet Burst protocol and Large Internet Packet.
Supports installed base of NetWare users by providing backward
compatibility with NETX
EMSNETX.EXE:
This file is the NetWare Expanded Memory shell. It can be loaded in place
of the NETX shell, if an EMS-compatible memory manager is loaded.
EMSNETX.EXE may also be replaced by the NetWare DOS Requester. The NetWare
DOS Requester is included with NetWare 4.0, available on NetWire through
Compuserve, or available from Novell.
Expanded memory refers to memory in addition to the 640KB limit of
conventional memory. An expanded memory manager swaps other memory into
the upper memory area (from 640KB to 1MB). This allows DOS applications to
access up to 32KB of expanded memory.
The NetWare Expanded Memory shell moves most of the shell out of conventional
DOS memory and puts it in expanded memory. This frees up 33KB of memory.
The remaining 7KB of the shell must remain in conventional memory to handle
interrupts and some data.
The NetWare Expanded Memory shell was written to the specifications of
LIM/EMS (Lotus/Intel/Microsoft Expanded Memory Specification) v4.0 memory
manager.
Expanded memory manufacturers provide Expanded Memory Specification
(EMS)-compatible driver programs. You must load an EMS-compatible driver
before loading the NetWare Expanded Memory shell.
To install the NetWare Expanded Memory shell, you need to
* Load a third-party EMS-compatible driver;
* Copy the NetWare Expanded Memory shell file, EMSNETX.EXE,
to the workstation boot diskette;
* Include the filename EMSNETX.EXE in the AUTOEXEC.BAT file
Because the Expanded Memory Shell operates in expanded memory, larger
applications can run in the conventional memory space. This approach is
faster than disk swapping and overlays. The NetWare Expanded Memory shell
works with NetWare v2.1 and above.
All the shell configuration (NET.CFG) parameters work with the NetWare
Expanded Memory shell. EMSNETX.EXE can only be used with DOS 3.0 and above.
The expanded memory shell is not designed to work on a machine running
non-dedicated NetWare.
XMSNETX.EXE:
This file is the NetWare Extended Memory shell. It can be loaded in place of
the NETX shell, if an XMS-compatible memory manager is loaded previously.
Extended memory refers to memory above the 1MB range. Up to 15MB of extended
memory is addressable.
XMSNETX.EXE may also be replaced by the NetWare DOS Requester. The NetWare
DOS Requester is included with NetWare 4.0, available on NetWire through
Compuserve, or available from Novell.
The NetWare Extended Memory shell moves most of the shell out of conventional
DOS memory and puts it in extended memory. This frees about 34KB of
conventional memory. 9KB of the extended memory shell must remain in
conventional memory to handle interrupts and some data.
The extended memory shell requires the support of an XMS (Extended Memory
Specification) v2.0 memory manager (or compatible), such as DR DOS 6.0's
EMM386.SYS. The memory manager makes the first 64KB (beginning at the 1MB
address) of extended memory directly available to DOS-based applications.
To install the NetWare Extended Memory shell, you need to
* Install a third-party extended memory manager;
* Copy the NetWare Extended Memory shell file, XMSNETX.EXE, to the
workstation boot disk;
* Include the filename XMSNETX.EXE in the AUTOEXEC.BAT file
Because the Extended Memory shell operates in extended memory, larger
applications can run in the conventional memory space. This approach is
faster than disk swapping and overlays. The NetWare Extended Memory shell
works with all versions of NetWare v2.1x and above.
All the shell configuration (NET.CFG) parameters work with the NetWare
Extended Memory shell. XMSNETX.EXE can be used only with DOS 3.0 and above.
The current VDISK.SYS from IBM is not compatible with HIMEM.SYS, so do not
use the extended memory shell with VDISK.SYS. Do not use the extended memory
shell on a machine running non-dedicated NetWare.
This shell requires a high degree of IBM compatibility. Depending on the
brand of IBM compatible you are using, you may experience keyboard
sluggishness or other hardware problems.
TBMI2.COM:
The "Task-Switched Buffer Manager 2" file allows programs that access IPX/SPX
directly to work in a multitasking environment (such as Microsoft Windows 3.1).
The multitasking environment in real and standard modes allows application
task switching (swapping). Each application runs in a separate DOS session
(DOS Prompt) in 640K of memory. Global memory--available to all--contains
drivers and TSRs such as COMMAND.COM and NETX.EXE. Local memory, only
contains the application and the applications data.
This program provides the data buffers needed to virtualize the IPX and SPX
requests made from applications running in a DOS session. These buffers need
to be allocated before a task switcher is loaded. Therefore, TBMI2 must be
executed before starting the task switcher.
Only the local memory is switched; the global memory with its drivers and TSRs
stays intact and is used with the new session. This means that separate local
memory segments exist, one for each DOS session, while only one global memory
segment exists. You do not need to use TBMI2 if:
1. The application goes through the NetWare shell (NETX) to
access IPX or SPX, or
2. You will not be switching between sessions.
You must use TBMI2 if:
1. You will be switching between sessions, and
2. The application bypasses the NetWare shell (NETX) and
accesses IPX or SPX directly.
If your application requires TBMI2 and you don't use it, the session will fail.
Note: If you aren't sure your application needs TBMI2, go ahead and run it,
it will use only a small amount of memory. After running the application for
a period of time, enter the command TBMI2 /D, and look at the number in the
Far Call Usage field. If this number is zero, then your application is not
using TBMI2; you can run your application without TBMI2.
The following are valid command line parameters:
/? or /H Display help or usage information.
/C=<filename> Load TBMI2 using this configuration file.
For example, enter "TBMI2 /C=TBMI2.CFG"
on the command line.
/D Display diagnostic information and
current allocation limits.
/I Display version information.
/U Unload TBMI2 from memory after exiting
Windows.
This program reads configuration information from a configuration file in the
current directory. One parameter is entered on each line in the configuration
file. This file's name is NET.CFG by default; a different name can be
specified using the /C= parameter on the command line.
The following are valid configuration file parameters:
INT 64 This is similar to the IPX configuration parameter; it specifies
that TBMI2 should support interrupt 64h IPX and SPX calls. This should
be set to either OFF or ON. For example, enter the line "INT 64 = ON"
in the configuration file. The default is ON for maximum compatibility.
INT 7A This is similar to the IPX configuration parameter; it specifies
that TBMI2 should support interrupt 7Ah IPX and SPX calls. This should
be set to either OFF or ON. For example, enter the line "INT 7A = ON"
in the configuration file. The default is ON for maximum compatibility.
ECB COUNT This specifies how many non-data event control blocks (ECBs) will
be allocated for use by DOS programs needing virtualization. These ECBs
apply to most AES events. If TBMI2 runs out of non-data ECBs, data ECBs
can be allocated for use. If no ECB can be allocated from TBMI2's pool
of ECBs, a failure will result with a completion code of FEh (or -2).
The minimum allowed value for this parameter is 10, the maximum is 255,
and the default is 20. For example, enter the line "ECB COUNT = 20" in
the configuration file. Each allocated ECB requires 52 bytes of memory;
the 20 ECB default will require 1040 bytes. The maximum allocation also
depends upon available memory, and the total size of all ECBs must be
less than 64K, which will normally limit the ECB count to less than 255.
Use the /D command line parameter to verify actual allocations.
DATA ECB COUNT This specifies how many data ECBs will be allocated for use
by DOS programs needing virtualization. These ECBs apply to most IPX and
SPX send-and-receive packets. If a non-data ECB request is made when none
are available, a data ECB will be used. If no ECBs are available from
TBMI2's pool of ECBs, a failure will result with a completion code of
FEh (or -2).
The minimum allowed value for this parameter is 10, and the default is
60. The theoretical maximum is 255, but 89 is the practical limit. For
example, enter the line "DATA ECB COUNT = 60" in the configuration file.
Each allocated data ECB requires 628 bytes of memory; the 60 ECB
default will require 37680 bytes. The maximum allocation also depends
upon available memory, and the total size of all ECBs must be less than
64K, which will normally limit the data ECB count to less than 255. Use
the /D command line parameter to verify actual allocations.
TBMI2 Usage
Do the following to start TBMI2:
1. Start TBMI2 by entering the command "TBMI2" on the command line, followed
by optional command line parameters listed above.
2. Start the task switching program normally.
TBMI2 could be included in a batch file starting the task switcher to ensure
that it is always started before the task switcher and unloaded afterwards.
The following will show examples of what a batch file could include for
different task switchers.
DOSShell example Windows example
---------------- ---------------
TBMI2 TBMI2
DOSShell WIN
TBMI2 /U TBMI2 /U
Troubleshooting TBMI2
If while using TBMI2 you encounter problems, you may need to troubleshoot the
TBMI2 configuration. Use the /D option with TBMI2 to display diagnostic
information and the current allocation limits.
Check the values associated with "Max Buffers Used," which tells you how many
buffers are used, and "Configured Data ECBs," which tells you how many are
available. If the number of buffers used approaches or equals the number of
buffers available, then you should increase the number of buffers available
using the ECB COUNT and DATA ECB COUNT parameters in the configuration file.
If the "Unavail buffer count" is ever more than zero, you should also increase
the number of buffers available using the ECB COUNT and DATA ECB COUNT
parameters in the configuration file.
The COMCHECK and RCONSOLE utilities are known to use too many buffers and
cannot be used with TBMI2.
RPLFIX.COM:
This file allows workstations to remote program load properly with DOS 5.x
and above.
RPLODI.COM:
This file is not used in the boot sequence with Boot ROM's created with the
RPL specification dated 9 July 1992 or later. This file is required for
remote program loading on DOS ODI workstations with older Boot ROM's. It is
a temporary protocol stack that is loaded before the LAN driver (MLID), and
is automatically unloaded when IPXODI loads. It is not necessary to use this
file if you are using the following LAN adapters:
IBM TOKEN-RING, PCN2, or Western Digital 8003.
DOS ODI UNLOADING:
Unlike DOS/IPX workstation drivers, you can unload DOS ODI files and drivers
without rebooting the workstation. You may find this particularly useful if
you need to load a different shell in place of NETX.EXE. The files must be
unloaded in reverse of the order they were loaded. For example:
NETX u <enter>
IPXODI u <enter>
<driver> u <enter>
LSL u <enter>
Where <driver> is the name of the workstations LAN driver. You may also
want to try typing an 'i' in place of the 'u' as above, which will display
useful information on each of these files.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.