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= 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 IPXODI u u LSL u Where 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.