DOS ODI WORKSTATION August 1990 Edition Revision 1.0 Novell, Incorporated 122 East 1700 South P.O. Box 5900 Provo, Utah 84606 USA þ Copyright 1990 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express prior written consent of the publisher. Novell Part # 100-000871-001 Disclaimer Novell, Inc. makes no representations or warranties with respect to the contents or use of this manual, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc. makes no representations or warranties with respect to any NetWare software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of NetWare software, at any time, without obligation to notify any person or entity of such changes. FCC warning Computing devices and peripherals manufactured by Novell generate, use, and can radiate radio frequency energy, and if not installed and used in accordance with the instructions in this manual, may cause interference to radio communications. Such equipment has been tested and found to comply with the limits for a Class A computing device pursuant to Subpart J of Part 15 of FCC Rules, which are designed to provide reasonable protection against radio interference when operated in a commercial environment. Operation of this equipment in a residential area is likely to cause interference, in which case the user---at his own expense---will be required to take whatever measures are necessary to correct the interference. Some components may not have been manufactured by Novell, Inc. If not, Novell has been advised by the manufacturer of the component that the component has been tested and complies with the Class A computing device limits as described above. Copyright 1990 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express prior written consent of the publisher. Novell, Incorporated 122 East 1700 South Provo, Utah 84606 USA August 1990 Edition Manual Revision 1.0 For NetWare v3.1 and above Novell Part # 100-000871-001 Table of Contents How to Use This Manual ii DOS ODI Workstation Installation 1 Prepare the workstations 4 Install the network board 5 Create the master workstation diskette 7 Create the workstation boot disk 11 Boot the workstation and log in to the file server 12 NET.CFG Options 17 Link support 20 Protocol 21 Link driver drivername 23 Link driver LANSUP 30 Appendix A: Using the IBM Token-Ring Source Routing Driver 31 Using the Source Routing Driver with DOS ODI 33 Appendix B: System Messages 37 Trademarks 69 Index 71 How to Use This Manual This manual explains how to set up and install a DOS ODI workstation. The installation section tells you how to prepare the workstation and create boot diskettes for use with DOS ODI. The NET.CFG section contains configuration information for the NET.CFG file. Use the information in this section if you are not using the default options for your workstation. Appendix A contains information on using the IBM Token-Ring Source Routing Driver. Appendix B contains system messages. DOS ODI Workstation Installation Novell's interconnectivity strategy for the 1990s, Open Data-Link Interface (ODI), adds functionality to NetWare and network computing environments by supporting multiple protocols and drivers. ODI creates a þlogical network boardþ to send different packet types over one network board and wire. You can benefit from ODI in the following ways: You can expand your network by using multiple protocols (such as IPX/SPX, AppleTalk, or TCP/IP as they become available) without adding network boards to the workstation. You can communicate with a variety of workstations, file servers, and mainframe computers via different protocol stacks without rebooting your workstation. You can protect your investment because protocols send packets through any LAN driver written to ODI specifications. You can spend less time and money on support. With one LAN driver supporting multiple protocols, you have fewer hardware components to support. You can use the NET.CFG file to configure the LAN driver for any possible hardware configuration, instead of being limited by SHGEN choices. You can free up memory by using only the portions of IPX/SPX and diagnostics that you need. As new LAN drivers and protocol transports are released, they will be available on NetWire. Using DOS ODI workstation software You can convert a standalone personal computer into a DOS ODI network workstation by adding one or more network boards, cabling, and the DOS ODI workstation software. If you are using a third-party network board, DOS ODI will not function unless you have a DOS ODI LAN driver for the board. Check the documentation that came with your network board for more information. DOS ODI Workstation software can be stored on a diskette or on a workstation's hard disk. Three sets of files allow workstations to þtalkþ to each other, to the file server, and to other third-party hosts. The first file is LSL.COM, the Link Support Layer file. This file enables the workstation to communicate over several protocols. Next are the LAN driver files, such as NE2000.COM and NE2.COM. Third are the protocol stack files, such as IPXODI.COM for NetWare networks, that manage communications among the network stations. In addition, you may need files specific to the networking product you are using. For example, if you want to install an ODI workstation on a NetWare network, you need the shell file (NETx.COM) that redirects messages from DOS to the network. This section documents how to install a DOS ODI workstation on a NetWare network using the IPX protocol stack. To install a DOS ODI workstation using another protocol stack or network, use these instructions as an example. You will have to modify them to fit your situation. You will need to follow the basic procedures of loading the LSL.COM, the ODI LAN drivers, a protocol stack, and then any other files specific to your software. Remote boot is not available for DOS ODI workstations with this release. What you will need To install DOS ODI workstations, you need the following: The DOS ODI Workstation Installation flow chart (Quick Path) to get an overview of the process A working copy of the DOS ODI WORKSTATION SERVICES diskette Enough DOS system diskettes to make master workstation diskettes and boot diskettes A þdiskþ (formatted diskette or hard disk) for each workstation to boot from The DOS ODI Workstation Installation flow chart (Quick Path) is found at the beginning of this manual. Table of Contents Task Page Prepare the workstations 4 Install the network board 5 Create the master workstation diskette 7 Create the workstation boot disk 11 Boot the workstation and log in to the file server 12 Troubleshooting tips 13 Where to go from here 15 Prepare the workstations Check the hardware and memory requirements. Use any of the following computers as workstations: IBM PC or compatible IBM PC XT or compatible IBM PC AT or compatible IBM Personal System/2 (any model) NetWare workstations have the following memory requirements: Up to 80KB of memory to load the NetWare workstation files At least 512KB of memory to run application programs and NetWare menu utilities If your workstations need more memory, install additional memory boards available from your computer dealer. Consult the manuals from your computer manufacturer for installing memory boards. Record the hardware information for the workstation on the Workstation Configuration Worksheet. Set up your workstations. Install all equipment for the workstation except the network board and cabling. Follow the hardware setup instructions in the Guide to Operations or Quick Reference for each computer. Boot each workstation with DOS. Booting each workstation with DOS ensures that the station is functional as a standalone computer. When each workstation has booted successfully, turn it off and continue with installation. Install the network board Make sure the network board conforms to your cabling topology (such as RX-Net or Ethernet). Select and set network board configurations. Use the following guidelines. Refer to the documentation that came with the network board to select and set the board configuration. Set the same configuration option on like boards for all your workstations. This reduces the number of master diskettes you will have to make. Choose the default configuration (shown as option 0 in the network board supplements) if no other devices are using the settings. (Many network boards are factory set to the default.) Make sure the configuration option of each board is unique from those of other boards or hardware installed in the computer (network boards, graphics and modem boards, etc.). Record the network board configuration settings on the Workstation Configuration Worksheet. These settings can be helpful if you need to troubleshoot problems on your network later. Install the network board. Make sure the workstation is turned off before installing the board. Create the master workstation diskette The master workstation diskette is a copy of the files necessary to boot one type of workstation. You will copy files from the DOSODI subdirectory of the DOS ODI WORKSTATION SERVICES diskette to the master workstation diskette. Then you will make individual workstation boot diskettes by copying the files from the master workstation diskette to the boot diskettes and by customizing the boot diskettes. Create system diskettes by using the DOS FORMAT command with the /s parameter. Format these diskettes using the correct version of DOS registered for each workstation on the network. Label the master workstation diskette. Label the master workstation diskette with the name of the LAN driver (such as þMaster Workstation NE2000þ), and list the configuration settings on the diskette. Configure software files (such as DXMAID) that came with your network board (optional). If you received additional software with your network board (for example, the DXMAID program for Token-Ring network boards), see the installation supplement or accompanying documentation for steps to configure those files. Copy the shell file you want from your NetWare diskette to the master workstation diskette. (The x in NETx.COM refers to the DOS version that runs on your workstations.) If you are using the extended or expanded memory shells, copy the .SYS files from the diskettes that come with the extended or expanded memory applications. Specify those files as device drivers in your CONFIG.SYS file so that they will be loaded when the workstation boots. For example, DEVICE = HIMEM.SYS Copy the workstation files from the DOSODI subdirectory of the DOS ODI WORKSTATION SERVICES diskette to the master workstation diskette. The following files are required to communicate with a NetWare server: LSL.COM The LAN driver for your network board (NE2000.COM, for example) The protocol stack file (IPXODI.COM, for example) NETx.COM The LANSUP.COM driver is for Token-Ring networks using the IBM LAN SUPPORT PROGRAM. The LANSUP.COM file can be used with PC Network and with Token-Ring networks. The following files are optional on the master workstation diskette: Put the executable files you selected into an AUTOEXEC.BAT file on the master workstation diskette. Use a DOS text editor to create the AUTOEXEC.BAT file, and save it to the master workstation diskette. It is important to load the files in the following order: link support layer, LAN driver, protocol stack, then the shell. This is a sample AUTOEXEC.BAT file: LSL NE2000 IPXODI NET3 See your DOS manual for ideas. Create a CONFIG.SYS file on the master workstation diskette using a DOS text editor (optional). If you are using memory managers, you need a line in CONFIG.SYS to specify the memory managers as devices. See your memory manager documentation for details. If you are using the IBM LAN SUPPORT PROGRAM, you must add two to three device drivers to CONFIG.SYS. See your DOS manual for details. Create a NET.CFG file on the master workstation diskette (optional). Usually, you do not need a NET.CFG file because the established defaults are adequate for your network. Test boot a workstation with the master workstation diskette. Create the workstation boot disk Copy the master workstation diskette files to each workstation boot disk. If you are copying files to diskette, use the DOS FORMAT command with the /s parameter to make a system diskette. Personalize the boot disk with executable files, and update the AUTOEXEC.BAT file (optional). If the owner of the bootable files wants any other commands executed or programs loaded during the boot process, add those files to the boot area, and make the appropriate changes to the AUTOEXEC.BAT file. Label the workstation boot diskette (optional). If you are using a boot diskette, label it with the LAN driver, the configuration option, and the custom boot files included. This prevents the boot diskette from being confused with other diskettes. Record the boot file information. This information is helpful for troubleshooting. Repeat Steps 1 through 4 for each workstation. Boot the workstation and log in to the file server Boot the workstation. Boot your workstation either of the following ways: Insert the workstation boot diskette into drive A and turn the workstation on. Copy the boot diskette files to the workstation's root directory on the hard disk, and reboot by pressing simultaneously. Log in to the file server. If your AUTOEXEC.BAT file does not contain login commands, type F: LOGIN SUPERVISOR Troubleshooting tips If you get the message þA File Server could not be found,þ check to see if The network board is seated properly. The cable is connected properly. (Run COMCHECK to verify the connections.) All cabling is terminated properly. The workstation node address conflicts with any other node address. If you want information about the drivers that are loaded, type a question mark after the driver name. For example NE2000 ? or LSL.COM ? or IPXODI ? Remove parts of IPXODI.COM to save memory. The IPXODI.COM file actually contains three parts: IPX SPX Remote Diagnostics Responder Since many applications do not need SPX or the Remote Diagnostics Responder (required for third-party applications that gather diagnostics information), some workstations can save memory by not loading these parts of the IPXODI.COM file. Some NetWare utilities, such as RCONSOLE and NVER, require SPX and the Remote Diagnostics Responder to be loaded. Use the chart below to see how to load IPXODI.COM without the other two parts of the file. To unload ODI drivers from the workstation, unload them in reverse order. For example, if you work with a protocol that requires a different shell or if you are working with two protocols that conflict when both are running on the workstation, unload the first set of files (in reverse order) before you load the next set. Unload the workstation files as follows: NET3 u IPXODI u NE2 u LSL u If you do not unload the files in reverse order, you get an error message similar to this: FATAL: There is a TSR above the loaded IPXODI. Where to go from here Notes NET.CFG Options The NET.CFG file contains the configuration information for the workstation. It is a control file that contains section headings and the currently defined options that deviate from the established defaults of the regular workstation boot process. Usually, you do not need a NET.CFG file because the established defaults are adequate for your network. Use any DOS text editor to create the file. Specify only options that will change from the defaults. If you have installed a dedicated IPX workstation, you are probably familiar with the SHELL.CFG file that also contains network configuration information. The information in SHELL.CFG is now migrating to the more versatile NET.CFG file. Any options from the SHELL.CFG file can be addressed in the NET.CFG file. Use the chart below to determine whether to use both .CFG files or to combine them into NET.CFG. If you place any SHELL.CFG options in the NET.CFG file, they will be ignored. See your NetWare manual for SHELL.CFG options. Conventions The NET.CFG file is left-justified for main section headings and indented (with either a space or a tab) under each heading. Keywords and main headings are not case sensitive. Below are the most common section headings in the NET.CFG file: Link support Protocol (protocol_name) Link driver (drivername) The heading must precede the options you want to include in that section. End each line with a hard return. Write all numbers in decimal notation except where noted otherwise. Precede comments by a pound (#) sign. Sample NET.CFG file LINK DRIVER NE1000 # Change the interrupt (IRQ) to 5. INT 5 # Change the DMA channel to 3. DMA 3 # Change the base memory address (hex) to an # absolute value of C0000. MEM C0000 # Change the port to 300 (hex) PORT 300 The following chart lists the options unique to the NET.CFG file. Main section headings are in white print and flush with the left margin. The options are listed under each heading and indented. Following the chart is a brief explanation of each option's function and some possible reasons for changing the setting. If you are using third-party protocol or LAN drivers, see their documentation for any additional parameters. In the following definitions, these conventions are used: [ ] An optional element number A decimal number hex A hexadecimal number Link Support BUFFERS communication_number [size] This option configures the number of receive buffers and their size on the network. The number of communication buffers must be large enough to hold all media headers and the maximum data size. Default: 0 The IPXODI protocol stack does not use the Link Support Layer communication buffers. Refer to the documentation for the third-party protocol stack for settings. Buffer size is optional. The minimum size is 586. The total buffer space must fit into approximately 59KB (number times buffer size). Default: 1130 MEMPOOL number [k] Some protocols use this option to configure the size of the memory pool buffers that the Link Support Layer will maintain. The IPXODI protocol stack does not use the MEMPOOL buffers. Refer to the documentation for the third-party protocol stack for settings. The k notation means multiply by 1024. Protocol "protocol_name" BIND name Usually IPXODI binds to the first network board it finds. This option limits the search to the network board you specify. Replace name with one of the following LAN driver names: TRXNET (for Novell RX-Net and Turbo RX-Net) NE2 (for Novell Ethernet NE/2) NE2-32 (for Novell Ethernet NE/2-32) NE1000 (for Novell Ethernet NE1000) NE2000 (for Novell Ethernet NE2000) LANSUP (for the IBM LAN Support program only) 3C503 (for 3Com EtherLink Series 503) 3C523 (for 3Com EtherLink/MC 3C523) In a DOS environment, you can bind IPXODI.COM to only one network board. For example, if you have an NE1000 board in slot 0 and an NE2000 board in slot 1 in your workstation, IPXODI binds to the NE1000 board if you specify nothing in the NET.CFG file. However, if you place BIND NE2000 in the NET.CFG file, IPXODI binds to the NE2000 board. DEFAULT name This option requests the protocol stack to bind with the LAN driver (MLID) and configures the protocol to a default stack. IPXODI ignores this parameter. Replace name with one of the LAN driver names listed for BIND on the previous page. PRESCAN name This option requests the protocol stack to bind with the LAN driver (MLID) named and configures the protocol to a default prescan stack. IPXODI ignores this parameter. Replace name with one of the LAN driver names listed for BIND on the previous page. SESSIONS number This option configures the number of sessions that the protocol stack will be required to maintain at one time. See the third-party protocol documentation for the minimum and maximum values. IPXODI ignores this parameter. Link Driver drivername To use this heading, replace drivername with the name of the driver you are using; then use one or more of the following options. The name is typically the LAN driver's filename. You can use these options with as many different network boards as you have, but you must have a separate Link Driver drivername heading for each board. Replace drivername with one of the following driver names: TRXNET (for Novell RX-Net and Turbo RX-Net) NE2 (for Novell Ethernet NE/2) NE2-32 (for Novell Ethernet NE/2-32) NE1000 (for Novell Ethernet NE1000) NE2000 (for Novell Ethernet NE2000) LANSUP (for the IBM LAN Support program only) 3C503 (for 3Com EtherLink Series 503) 3C523 (for 3Com EtherLink/MC 3C523) Place both hardware commands and software commands under the Link driver heading. Hardware commands DMA [#1 | #2] channel_number This option specifies the hardware setting of the network board used in the workstation. This option allows one of two DMA channels to be configured. Enter the channel number to be used. (The driver for the board will automatically select its default channel number.) If you do not specify which of the two configurable DMA channels (#1 or #2) to configure, this option defaults to the first configurable channel (#1). You do not need to include the #1 option if you are using only the default option. For example, if the first configurable DMA channel on your board uses DMA channel 3, place the following lines in your NET.CFG file: Link Driver name DMA 3 For example, if the first configurable DMA channel on your board will use channel 3 and the second configurable channel will use channel 4, place the following lines in your NET.CFG file: Link Driver name DMA 3 DMA #2 4 Notice that the second DMA channel requires you to use the pound sign (#). INT [#1 | #2] interrupt_request_number This option specifies which interrupts the network board uses. Use the interrupt request number set on the board. If you do not specify which interrupt line (#1 or #2) to configure, this option uses the default, which is the first configurable interrupt line (#1). Do not include the #1 option if you are using only the default option. For example, if the first configurable interrupt line on your board will use IRQ 2, place the following lines in your NET.CFG file: Link Driver name Int 2 If your board can use two configurable interrupt lines and you want to use both of them or only the second one, you must specify the interrupt line (#1 or #2) to configure. For example, if the first configurable interrupt line on your board will use IRQ 2 and the second will use IRQ 3, place the following lines in your NET.CFG file: Link Driver name Int 2 Int #2 3 The second DMA channel requires you to use the pound sign (#). MEM [#1 | #2] hex_starting_address [hex_length] This option specifies a memory range to be used by the network board. Use the hexadecimal physical (absolute) address of the memory used by the board. (This starting address must match the starting address configured on the board.) Enter the length (in hexadecimal paragraphs) of the memory address range used by the board. A paragraph is normally 16 bytes. For example, to address a board from D0000 to D4000 (bytes), the starting address is D0000 and the range is 400 (paragraphs in 16KB decimal length). In this case, place the following lines in your NET.CFG file: Link Driver name Mem D0000 Usually, the length is not needed. PORT [#1 | #2] hex_starting_address hex_number_of_ports Use this option to specify the starting port and number of ports in the range. Use the starting hexadecimal I/O port number. Use the hexadecimal number of ports in the range. If your network board can use two ranges and you want to use either the second range or both ranges, you must specify which range (#1 or #2) to use. All values must be written in hexadecimal notation. For example, suppose you want to specify the starting port and the number of ports in the first range on your board. The starting I/O port is 300; 16 ports are in the first range. Place the following lines in the NET.CFG file: Link Driver name Port 300 The number of ports is optional. NODE ADDRESS hex_address This option overrides any hard-coded node address in the network board, if the hardware allows it. Use the hexadecimal address number. Changing the node address on a board can create conflicts with other network boards. Stay with the hard-coded node address whenever possible. The example below shows how to change the node address on a 3C523 board: Link Driver 3C523 Node Address 12D43 PS/2 SLOT number Use this option if you want to access two separate Ethernet backbones. Use the number of the slot into which you inserted the board. The slot number is found on the back of the computer. The LAN driver will use the board in this slot. For example, if you are using two NE/2 boards in the same workstation and you insert one board into slot 1 and the other into slot 2, place the following lines in your NET.CFG file: Link Driver NE2 Link Driver NE2 PS/2 Slot 2 Then place the following lines in your AUTOEXEC.BAT file: LSL NE2 NE2 PS/2 SLOT ? Use this option if you have inserted only one of the same kind of network board in the workstation. This option signals the LAN driver to scan for its board. Software commands FRAME frame_type This option specifies the frame type that is used with the network board. Use this option with boards that support more than one frame type. For example, to specify an Ethernet board using the Ethernet II frame type, place the following line in the NET.CFG file beneath the heading for that driver: Frame ETHERNET_II Usually, Ethernet LAN drivers default to Ethernet_802.3; Token-Ring LAN drivers default to Token-Ring. Drivers that support more than one frame type (such as Ethernet) allow multiple "frame" commands. LOOK AHEAD SIZE number This option specifies the number of bytes in the packet that the LAN driver will send to the Link Support Layer to determine how to route the packet. The range is 0 to 128 bytes depending on the protocol. See the protocol documentation for the recommended size. If two or more protocols are using a LAN driver, select the highest value for the look-ahead size. Default: 18 bytes PROTOCOL name hex_protocol_ID frame_type This option enables new protocols to be handled by existing LAN drivers. Replace name with the name of the new protocol. Use the hexadecimal protocol ID number. Replace frame_type with the frame type that the new protocol ID applies to. For example, if you attach a new protocol (XYZ) to your NE2-32 network board, the NET.CFG file could look similar to the following: Link Driver NE2-32 Frame ETHERNET_SNAP Protocol XYZ 904A ETHERNET_SNAP SEND RETRIES number This option specifies the maximum number of times the network board driver will try to resend a packet following a communications error. Use the number of times you want the driver to try resending the packet. The default value is determined by the driver. Link Driver LANSUP The options below are unique to the LANSUP driver. SAPS number If you use the LANSUP driver with a network board, you must specify the number of Service Access Points (SAPs) needed. Set the option to allow for all applications using the IBM LAN Support Program. The maximum value depends on the type of board used. Default: 1 LINK STATIONS number If you use the LANSUP driver with a network board, you must specify the number of link stations needed. Set the option to allow for all applications using the IBM LAN Support Program. The maximum value depends on the type of board used. Default: 1 Appendix A: Using the IBM Token-Ring Source Routing Driver This appendix explains the use of the IBM Token-Ring Source Routing Driver. The IBM Token-Ring Source Routing Driver enables communication across IBM Token-Ring network bridges. Any type of protocol stack can use this DOS ODI feature to communicate across IBM Token-Ring network bridges. All nodes that need to communicate across a source route bridge must be running the IBM Token-Ring Source Routing Driver. For more information on using source routing, see the IBM Token-Ring Network Architecture Reference manual. The following figure shows an example network configuration using IBM source routing bridges. Figure A.1A network configuration using IBM source routing bridges Using the Source Routing Driver with DOS ODI To install source routing on workstations, complete the following steps. Create a boot disk according to the instructions on page 11 of this manual. Copy the ROUTE.COM file from the DOS/ODI WORKSTATION SERVICES diskette to the boot disk. If you are creating an AUTOEXEC.BAT file for a DOS ODI workstation, the command to load ROUTE.COM should be added after LANSUP.COM but before the protocol stack you are using. Set the parameters for ROUTE.COM. See "Additional Information" on the next page for the parameters that ROUTE.COM can be loaded with. Add the parameter in the AUTOEXEC.BAT file. The default parameters for ROUTE.COM can be used with most network communications. Additional Information The following parameters can be entered when ROUTE.COM is first loaded. BOARD = number MBR CLEAR NODES = number DEF REMOVE = number GBR The parameters can also be changed by loading ROUTE.COM a second time. For on-line help, type ROUTE ? Most of the parameters have default values that should work with simple configurations for IBM bridges. If you have installed parallel IBM bridges, you can change some of the parameters to reduce traffic on some of the paths. Each parameter is described below. BOARD = number Use this parameter to specify a board number for the Token-Ring network board. If this parameter is not specified, the default of 01 is used. If you have loaded more than one LAN driver in the workstation, the board number is determined by the order in which the LAN drivers are loaded (the first board is 1). See your AUTOEXEC.BAT file for the order you have specified. CLEAR Use this parameter to manually clear the Source Routing table and force a dynamic rebuilding of the table by sending a default frame to each node in the network. Use this parameter when an IBM bridge on the network has gone down and an alternate route is available. DEF Use this parameter to prevent frames that have unknown (DEFault) destination addresses from being sent across Single Route IBM bridges. If this parameter is specified, all frames that have addresses not in the workstation's Source Routing table are forwarded as All Routes Broadcast frames. If this parameter is not specified, all frames that have addresses not in the workstation's Source Routing table are forwarded as Single Route Broadcast frames. If ROUTE.COM has already been loaded with the DEF parameter, reloading ROUTE.COM with this parameter broadcasts all subsequent Single Route Broadcast frames as All Routes Broadcast frames. GBR Use this parameter to specify that all General BRoadcast frames are to be sent as All Routes Broadcast frames. If this parameter is not specified when ROUTE is loaded, all General Broadcast frames are broadcasted as Single Route Broadcast frames. If ROUTE has already been loaded with the GBR parameter, reloading ROUTE with this parameter broadcasts all subsequent General Broadcast frames as All Routes Broadcast frames. MBR Use this parameter to specify that all Multicast BRoadcast frames are to be sent as All Routes Broadcast frames. If the parameter is not specified when ROUTE is loaded, all Multicast Broadcast frames are broadcast as Single Route Broadcast frames. If ROUTE has already been loaded with the MBR parameter, reloading ROUTE with this parameter broadcasts all subsequent Multicast Broadcast frames as All Routes Broadcast frames. NODES = number Use this parameter to specify the number of table entries in the Source Routing table. This parameter must be entered the first time ROUTE.COM is loaded. The parameter cannot be changed by reloading ROUTE.COM. Replace number with a value from 8 to 255. The default is 16. REMOVE = number Use this parameter to remove a specified node address from the workstation's Source Routing table. Use the parameter when a bridge has gone down. Removing the node from the Source Routing table forces the workstation to determine an alternate path. Replace number with a 12-digit (6-byte) hexadecimal number. If fewer than 9 digits are entered, ROUTE.COM prefixes the address with 4000h. For example, REMOVE=2 is interpreted as REMOVE=400000000002. Appendix B: System Messages Connector is BNC. Source: 3C503.COM Explanation: The connector selected for the board is for Thin Ethernet cabling. Action: None Connector is DIX. Source: 3C503.COM Explanation: The connector selected for the board is for Thick Ethernet cabling. Action: None. FATAL: 3C503 -Card not found. Source: 3C503.COM Explanation: The 3C503.COM driver could not locate a 3C503 board at the specified hardware settings. Action: Make sure that a 3C503 board is installed. Verify the hardware jumper settings. If the settings do not match the defaults, specify the settings in the NET.CFG file. FATAL: 3C503 -Card will not initialize. Source: 3C503.COM Explanation: A hardware failure occurred. Action: Check for possible hardware settings that conflict with other installed boards. FATAL: 3C503 -Interrupt is invalid (2,3,4,5,9 valid). Source: 3C503.COM Explanation: An invalid interrupt value was specified in the NET.CFG file. Action: Correct the þINT numberþ entry in the NET.CFG file; then try again. FATAL: 3C503 -I/O port does not match NICs jumper. Source: 3C503.COM Explanation: The specified base I/O port address (the driver default or the value specified in the NET.CFG file) is different from the address setting on the 3C503 board. Action: Make sure that the value for the driver matches the value set on the board; then try again. FATAL: 3C503 -Memory does not match NICs jumper. Source: 3C503.COM Explanation: The specified base memory address (the driver default or the value specified in the NET.CFG file) is different from the address setting on the 3C503 board. Action: Make sure that the value for the driver matches the value set on the board; then try again. FATAL: Board # doesn't provide enough look ahead, IPX needs 18 or more bytes. Source: IPXODI Explanation: IPX requires at least the first 18 bytes of incoming packets for it to preview the packets properly. Action: Increase the MLID look-ahead size by specifying þLOOK AHEAD SIZE 18þ in the NET.CFG file under the MLID main section heading, as in the following example: LINK DRIVER NE1000 LOOK AHEAD SIZE 18 FATAL: Board failed to initialize correctly. Source: MLID Explanation: The MLID could not initialize its board correctly. A hardware failure usually prevents initialization. Action: Refer to the MLID documentation for a description of the error. FATAL: Could not find a board that supports IPX (See PROTOCOL keyword). Source: IPXODI Explanation: IPX could not find a board to bind with. For IPX to bind, it must have a protocol ID registered with the Link Support Layer. Most MLIDs will register an IPX Protocol ID by default. However, if you have specified the PROTOCOL keyword under an MLID's section heading in the NET.CFG file, this error may be generated. When a protocol ID has been specified for another protocol stack, the MLID does not register a default protocol ID for IPX. Action: If you want to use IPX, register a protocol ID for IPX along with the other Protocol IDs you are registering. FATAL: Could not find an enabled 3C523 adapter in any slot. Source: 3C523.COM Explanation: By default, the 3C523.COM driver scans the PS/2 slots to find the 3C523 board it should use. The driver starts scanning at slot 1. The driver was unable to find a 3C523 in any slot. Action: Make sure that the 3C523 board is firmly seated in the slot. FATAL: Could not find an NE2 adapter in any slot. Source: NE2.COM Explanation: By default, the NE2.COM driver will scan the PS/2 slots to find the NE2 board it should use. The driver starts scanning at slot 1. The driver could not find an NE2 in any slot. Action: Make sure that the NE2 board is firmly seated in the machine's slot. FATAL: Could not find an NE2-32 adapter in any slot. Source: NE2-32.COM Explanation: By default, the NE2-32.COM driver will scan the PS/2 slots to find the NE2-32 board it should use. The driver starts scanning at slot 1. The driver was unable to find an NE2- 32 in any slot. Action: Make sure that the NE2-32 board is firmly seated in the slot. FATAL: Could not find MLID to unload. Source: MLID Explanation: A request was made to unload the MLID, but the MLID is not loaded. Action: None. FATAL: Different IPX or a IPX interrupt has been hooked. Source: IPXODI Explanation: You tried to unload the IPX from memory, but the IPX detected a condition that would not allow IPX to be removed from memory safely. This can occur for two reasons: The resident IPXODI and the IPXODI used to unload the resident IPXODI are not the same version. Another program has been loaded that has hooked one of IPXODI's interrupt vectors. IPXODI uses the following interrupt vectors: INT 08h, INT 2Fh, INT 64h, and INT 7Ah. Action: Complete one of the following: Use the same version of IPXODI to unload IPX as you used to load. Unload the program that has hooked to one or more IPX interrupt vectors and then unload IPXODI. FATAL: Different LSL or a LSL interrupt has been hooked. Source: LSL Explanation: You tried to unload the LSL from memory, but it detected a condition that would not allow it to be removed safely. This can occur for two reasons: The resident LSL and the LSL used to unload the resident LSL are not the same version. Another program has been loaded that has hooked one of the LSL's interrupt vectors. The LSL uses the following interrupt vectors: INT 08h and INT 2Fh. Action: Complete one of the following: Use the same version to unload LSL as you used to load it. Unload the program that has hooked to the LSL's interrupt vectors before unloading the LSL. FATAL: Direct Station 0 already in use by another application. Source: LANSUP.COM Explanation: The LANSUP.COM driver uses Direct Station 0. Only one application running on the IBM LAN Support program can use Direct Station 0. Action: Unload the other application. FATAL: Error initializing board. Source: LANSUP.COM Explanation: The LAN Support Program could not initialize the network board. Action: Check the installation of the LAN Support software. FATAL: Error opening board. Source: LANSUP.COM Explanation: The LAN Support Program could not open the network board. Action: Check the installation of the LAN Support software. FATAL: Error shutting down MLID, unload operation aborted. Source: MLID Explanation: The MLID was attempting to remove the resident MLID from memory. The MLID was unable to successfully shut down the resident MLID. A hardware failure has probably occurred. Action: Run diagnostics on the network board and workstation. Replace the faulty hardware. FATAL: Failed to locate MLID Section Heading in NET.CFG file. Source: MLID Explanation: You tried to load the MLID again. Normally you would do this so that you could use two or more boards in the workstation. When two or more of the same type of network boards are installed in the workstation, an associated MLID section heading must be specified in the NET.CFG file. An entry in the NET.CFG file for two boards would look similar to the following: #Allow the first one to use default values. LINK DRIVER NE1000 #This section is for the second board. LINK DRIVER NE1000 INT 4 PORT 320 Action: Add the commands for both MLID boards to the NET.CFG file. Then reboot the workstation. FATAL: IBM LAN Support Program has not been loaded. Source: LANSUP.COM Explanation: The LANSUP.COM driver requires that the IBM LAN Support Program be loaded. Action: Load the LAN Support Software and retry the operation. Add lines similar to the following to the CONFIG.SYS file: DEVICE=DXMA0MOD.SYS DEVICE=DXMC0MOD.SYS FATAL: Init586: Configure command failed. Source: 3C523.COM Explanation: A hardware failure has occurred. Action: Install the 3C523 board in a different slot. If the driver still fails to load, the 3C523 board is probably bad and should be replaced. FATAL: Init586: IA_Setup command failed. Source: 3C523.COM Explanation: A 3C523 hardware failure has occurred. Action: Install the 3C523 in a different slot. If the driver still fails to load, the 3C523 board is probably bad and should be replaced. FATAL: Init586: Initial communication with 82586 failed. Source: 3C523.COM Explanation: A hardware failure has occurred. Action: Install the 3C523 board in a different slot. If the driver still fails to load, the 3C523 board is probably bad and should be replaced. FATAL: Invalid base memory address - Must be C0000 or D0000. Source: NE2-32.COM Explanation: Because the NE2-32 board is a true 32-bit board, the board has the option to have its base memory located above the 1MB real mode memory limit. Since DOS ODI is executing in real mode, the NE2-32.COM driver cannot access the board's RAM when it is located above the 1MB address range. Action: Use the Reference diskette to change the board's base memory setting to either C0000 or D0000. FATAL: Invalid Ethernet node address specified. Source: MLID Explanation: You used the þNODEþ option in the NET.CFG file to override the node address on the network board. The number specified was not a valid Ethernet node address. An Ethernet address is 6 bytes in length. This error occurs if Bit 0 of the first address byte is a 1. This bit must always be 0. For example, if the first byte has the following address, an invalid Ethernet address is generated. First Byte 7 6 5 4 3 2 1 0 ÚÄÂÄÂÄÂÄÂÄÂÄÂÄÂÄ¿ ³0³0³0³0³0³0³0³1³ ÀÄÁÄÁÄÁÄÁÄÁÄÁÄÁÄÙ This byte will produce node addresses in the 0100 0000 0000 to 01FF FFFF FFFF range, all of which will be invalid. Action: Change the NET.CFG file so that a valid node address is specified. FATAL: Invalid parameter. Source: IPXODI Explanation: When you tried to load IPXODI, you specified an invalid parameter on the command line. IPXODI was not loaded. The only valid parameters are ? for information and U for unload. Action: Specify a valid parameter. or Source: LSL Explanation: When you tried to load the LSL, you specified an invalid parameter on the command line. The LSL was not loaded. The only valid parameters are ? for help and U for unload. Action: Specify a valid parameter. or Source: MLID Explanation: When you tried to load the MLID, you specified an invalid parameter on the command line. The MLID was not loaded. The only valid parameters for MLID are ? for information and U for unload. Action: Specify a valid parameter. FATAL: Invalid Token-Ring node address specified. Source: MLID Explanation: You used the þNODEþ option in the NET.CFG file to override the node address on the network board. The number specified was not a valid Token-Ring node address. A Token- Ring address is 6 bytes in length. This error will occur if Bit 7 of the first address byte is a 1. This bit should always be a 0. For example, if the first byte has the following address, an invalid Token-Ring address is generated. First Byte 7 6 5 4 3 2 1 0 ÚÄÂÄÂÄÂÄÂÄÂÄÂÄÂÄ¿ ³1³0³0³0³0³0³0³0³ ÀÄÁÄÁÄÁÄÁÄÁÄÁÄÁÄÙ This byte will produce node addresses in the 8000 0000 0000 to 8FFF FFFF FFFF range, all of which will be invalid. Action: Change the NET.CFG file so that a valid node address is specified. FATAL: IPX already loaded. Source: IPXODI Explanation: IPX has already been loaded. It needs to be loaded only once. Action: None. FATAL: IPX is already registered with the LSL. Source: IPXODI Explanation: IPX was not removed from the LSL's register when it was unloaded. The system may be corrupted. Action: Reboot the workstation. FATAL: IPX is not loaded. Source: IPXODI Explanation: You tried to unload IPX, but IPX has not been loaded. Action: None. FATAL: Loading MLID again requires configuration information in NET.CFG. Source: MLID Explanation: You tried to load the MLID a second time. Normally you would do this so that you could use two or more boards in the workstation. When two or more of the same type of network boards are installed in the workstation, an associated MLID section heading must be specified in the NET.CFG file. An entry in the NET.CFG file for two boards would look similar to the following: #Allow the first one to use default values. LINK DRIVER NE1000 #This section is for the second board. LINK DRIVER NE1000 INT 4 PORT 320 Action: Create a NET.CFG file and add the commands for both MLID boards to the file. Then reboot the workstation. FATAL: LSL already loaded. Source: LSL Explanation: The Link Support Layer has already been loaded. The LSL can be loaded only once. Action: None. FATAL: LSL is not loaded. Source: LSL Explanation: You tried to unload the LSL, but it is not loaded. Action: None. FATAL: Multiplex interrupt 2Fh has no free slots. Source: LSL Explanation: LSL could not find a free slot for use with INT 2F (Hex). When your computer is first booted, approximately 63 multiplex slots are available. All available slots are already being used by applications. Action: Unload an application that is using a INT 2F multiplex interrupt; then load the LSL. FATAL: NE1000 NIC command port failed to respond. Source: NE1000.COM Explanation: The NE1000 board has malfunctioned, is not installed, or is not configured to the same port as selected for the driver. Action: Complete one or more of the following: Make sure that an NE1000 board has been installed and configured. Make sure that the configuration for the NE1000 board matches the configuration for the NE1000 driver. Configuration options other than the defaults must be entered in the NET.CFG file. Replace the board. FATAL: NE1000 NIC RAM failure. Source: NE1000.COM Explanation: The NE1000 board's on-board memory has malfunctioned. Action: Replace the board. FATAL: NE2 NIC command port failed to respond. Source: NE2.COM Explanation: The installed NE2 board has malfunctioned. Action: Replace the board. FATAL: NE2 NIC RAM failure. Source: NE2.COM Explanation: The NE2 board's installed on-board memory has malfunctioned. Action: Replace the board. FATAL: NE2000 NIC command port failed to respond. Source: NE2000.COM Explanation: The NE2000 board has malfunctioned, is not installed, or is not configured to the same port as selected for the driver. Action: Complete one or more of the following: Make sure that an NE2000 board has been installed and configured. Make sure that the configuration for the NE2000 board matches the configuration for the NE2000 driver. Configuration options other than the defaults must be entered in the NET.CFG file. Replace the board. FATAL: NE2000 NIC is NOT supported in a 8-bit slot. Source: NE2000.COM Explanation: The NE2000 board is located in an 8-bit slot in the machine. The NE2000.COM driver only supports the NE2000 in a 16-bit AT bus slot. Action: Place the NE2000 board in a 16-bit slot and try again. FATAL: NE2000 NIC RAM failure. Source: NE2000.COM Explanation: The NE2000 board's on-board memory has malfunctioned. Action: Replace the board. FATAL: NE2000 NIC was not found at specified hardware settings. Source: NE2000.COM Explanation: The NE2000.COM driver found a board at the specified hardware settings, but the board is not an NE2000 board. Action: Check the installed hardware. FATAL: NE2-32 NIC command port failed to respond. Source: NE2-32.COM Explanation: The installed NE2-32 board has malfunctioned. Action: Replace the board. FATAL: NE2-32 NIC RAM failure. Source: NE2-32.COM Explanation: The installed NE2-32 board's on-board memory has malfunctioned. Action: Replace the board. FATAL: No more room in the LSL for another protocol stack. Source: IPXODI Explanation: The maximum number of protocol stacks have been registered with the Link Support Layer. The DOS ODI LSL can support up to eight protocol stacks. Action: Remove an existing protocol stack. FATAL: RXNet command port failed to respond. Source: TRXNET.COM Explanation: The TRXNET.COM driver could not find an RX- Net board in the workstation. Action: Make sure that an RX-Net board is installed in the workstation and that it is firmly seated. Make sure that the values for the hardware settings in the driver (the default or the values set in the NET.CFG file) match the values set on the board. FATAL: RXNet RAM failure. Source: TRXNET.COM Explanation: The RX-Net board's RAM has failed the RAM test. Action: Replace the board. FATAL: Specified PS/2 slot contains an NE2 but it is not enabled. Source: NE2.COM Explanation: The located NE2 board was not enabled. The NE2 board has probably malfunctioned. Action: Replace the board. FATAL: Specified PS/2 slot contains an NE2-32 but it is not enabled. Source: NE2-32.COM Explanation: The located NE2-32 board was not enabled. The NE2-32 board has probably malfunctioned. Action: Replace the board. FATAL: Specified PS/2 slot does not contain an enabled 3C523 adapter. Source: 3C523.COM Explanation: A þPS/2 SLOT numberþ option was specified in the NET.CFG file. The specified slot does not contain a 3C523 board. Note that slot numbers are 1 based and correspond to the slot numbers on the back of the computer. Action: Modify the NET.CFG so that the specified slot number matches the slot that the board is installed in. FATAL: Specified PS/2 slot does not contain an NE2 adapter. Source: NE2.COM Explanation: A þPS/2 SLOT numberþ option was specified in the NET.CFG file. The specified slot does not contain an NE2 board. Note that slot numbers are 1 based and correspond to the slot numbers on the back of the computer. Action: Modify the NET.CFG file to specify the correct slot number. FATAL: Specified PS/2 slot does not contain an NE2-32 adapter. Source: NE2-32.COM Explanation: A þPS/2 SLOT numberþ option was specified in the NET.CFG file, but the specified slot does not contain an NE2- 32 board. Slot numbers are 1 based and correspond to the slot numbers on the back of the computer. Action: Modify the NET.CFG file to specify the correct slot number. FATAL: The LSL is not loaded. Source: IPXODI Explanation: IPX requires that the LSL be loaded first. Action: Load LSL.COM; then load IPXODI.COM. or Source: MLID Explanation: LSL must be loaded before an MLID can be loaded. Action: Load LSL.COM; then load the MLID. FATAL: There is a TSR above the loaded IPX. Source: IPXODI Explanation: You tried to unload IPX from memory, but IPX detected another Terminate-and-Stay-Resident program loaded above IPX. For IPX to unload safely, TSRs that were loaded after it must be unloaded first. Action: Either load the TSR before loading IPX or unload the TSR before trying this operation. FATAL: There is a TSR above the loaded LSL. Source: LSL Explanation: You tried to unload the LSL from memory, but the LSL detected another Terminate-and-Stay-Resident program loaded above the LSL. For the LSL to unload safely, TSRs that have been loaded after it must be unloaded first. Action: Either load the other TSR before loading the LSL or unload the TSR before trying this operation. FATAL: There is a TSR above the loaded MLID. Source: MLID Explanation: You tried to unload the MLID from memory, but the MLID detected another Terminate-and-Stay-Resident program loaded above the MLID. For the MLID to safely unload, TSRs that were loaded after it must be unloaded first. Action: Either load the other TSR before loading the MLID or unload the TSR before trying this operation. FATAL: This old LSL is not supported. Source: IPXODI Explanation: IPXODI cannot run correctly using this version of the LSL. Action: Update your LSL.COM to a newer version. or Source: MLID Explanation: The MLID cannot run correctly using this version of the LSL. Action: Update your LSL.COM to a newer version. FATAL: Work Area Exceeded, reduce number of SAPs and/or Link Stations. Source: LANSUP.COM Explanation: The number of SAPs or Link Stations specified in the NET.CFG file exceeded the maximum number of SAPs or Link Stations that the network board can handle. Action: Modify the number of SAPs or Link Stations specified in the NET.CFG file. IPX protocol bound to MLID Board # . Source: IPXODI Explanation: This message is displayed after IPX has successfully loaded. It is not a error message but simply tells you which logical MLID IPX is using. The MLID's short name (NE1000, for example). The logical board number of the MLID. This number is 1 based (for example, the first MLID is assigned board #1). Action: None. IPX protocol successfully removed. Source: IPXODI Explanation: A request was made to unload IPXODI, and IPXODI was removed (unloaded) from memory. Action: None. LSL successfully removed. Source: LSL Explanation: A request was made to unload the LSL, and the LSL was removed from memory. Action: None. Number of buffers , Buffer size bytes, Memory pool bytes Source: LSL Explanation: This information appears when the LSL has read configuration information from the NET.CFG file. (LSL does not display default values when it loads.) The number of communication buffers allocated by the LSL. Normally, the LSL does not need buffers; therefore, none should be allocated unless directed by a protocol's documentation. This number may be less than requested due to memory limits within the LSL. The size of the LSL's communications buffers (106 bytes of this value are reserved for protocol and media headers). This value cannot be smaller than 618 bytes. The amount of memory allocated to the LSL's free memory pool. This free memory pool is used by protocols. This value may be smaller than requested due to memory limits within the LSL. The LSL first allocates the requested number of communications buffers and then allocates the free memory pool from the remaining memory. Normally, a free memory pool is not needed and should not be allocated, unless directed by a protocol's documentation. Action: None. MLID successfully removed. Source: MLID Explanation: A request was made to unload an MLID, and the MLID was removed from memory. Action: None. WARNING: Byte value greater than 255 was truncated Source: IPXODI Explanation: An IPX or SPX parameter specified in the NET.CFG or SHELL.CFG file was set to a value greater than 255. The value used will be 255 (the maximum configurable value). Action: Change the NET.CFG file so that the IPX or SPX parameter has a valid value. WARNING: Error registering Protocol=, PID=, Frame= Source: MLID Explanation: The MLID could not register the specified Protocol ID. The name of the protocol. The value of the Protocol ID used to register the Protocol ID. The frame type for which the Protocol ID was registered. Action: Verify the protocol information in the NET.CFG file. WARNING: Invalid LOOK AHEAD SIZE value, will be set to maximum (128 bytes). Source: MLID Explanation: The þLOOK AHEAD SIZEþ option was specified in the NET.CFG for an MLID. The value specified was greater than 128 bytes. The MLID will use 128 bytes for its look ahead size. Action: Change the þLOOK AHEAD SIZEþ option in the NET.CFG file to a valid value. WARNING: MLID does not support Frame - Protocol keyword ignored. Source: MLID Explanation: The þPROTOCOLþ option was specified in the NET.CFG for an MLID. The specified frame type is not supported by the MLID. Action: Check the þPROTOCOLþ line in the NET.CFG file for possible omissions of required dashes and underscores or any misspellings. Check the MLID documentation for supported frame types. WARNING: NET.CFG ignored - file length must be less than 4097 bytes. Source: IPXODI Explanation: The NET.CFG file is larger than 4,096 bytes. IPX still loads, but ignores the information in the NET.CFG file. Action: Reduce the size of the NET.CFG file. or Source: LSL Explanation: The NET.CFG file is larger than 4,096 bytes. The LSL still loads, but ignores the information in the NET.CFG file. Action: Reduce the size of the NET.CFG file. or Source: MLID Explanation: The NET.CFG file is longer than 4,096 bytes. The MLID still loads, but ignores the information in the NET.CFG file. Action: Reduce the size of the NET.CFG file. WARNING: NET.CFG ignored - MLID name cannot be more than 8 characters long. Source: IPXODI Explanation: The þBind MLIDþ option in the NET.CFG file specified an MLID with a name longer than 8 characters. Action: Refer to the MLID's documentation for more information on the name. WARNING: Node Address override not supported. Specify override when loading IBM LAN Support Software. Source: LANSUP.COM Explanation: A node address was specified in the NET.CFG file for the LANSUP.COM driver. The node override must be specified when loading the IBM LAN Support software. Action: Refer to the IBM LAN Support documentation for instructions. WARNING: No room in the LSL for another board. Board will not be activated. Source: MLID Explanation: The maximum number of boards has been registered with the Link Support Layer. The DOS ODI LSL can support up to eight boards. Action: Reduce the number of active boards in the system by unloading a board. WARNING: Protocol keyword must have a frame type - entry ignored. Source: MLID Explanation: The þPROTOCOLþ option was specified in the NET.CFG for an MLID. The entry failed to specify the associated frame type for the protocol ID addition. An entry in the NET.CFG file for the þPROTOCOLþ option would look similar to the following: LINK DRIVER NE1000 PROTOCOL IPX 8137 ETHERNET_II Action: Specify a frame type with the þPROTOCOLþ option. WARNING: Specified MAX PACKET SIZE too big for this adapter, max size used. Source: LANSUP.COM Explanation: The specified maximum packet size in the NET.CFG file was too large for the network board installed in the workstation. The maximum packet size for the network board was used. Action: Modify the maximum packet size in the NET.CFG file. Notes Trademarks Novell, Inc., has made every effort to supply trademark information about company names, products, and services mentioned in this book. Trademarks indicated below were derived from various sources. 3Com, 3Com EtherLink, and EtherLink Plus are trademarks of 3Com Corporation. AppleTalk is a registered trademark of Apple Computer, Inc. IBM is a registered trademark of International Business MachinesCorporation. IBM PC AT/XT are trademarks of International Business MachinesCorporation. IBM Personal System/2 is a registered trademark of InternationalBusiness Machines Corporation. Internetwork Packet Exchange (IPX) is a trademark of Novell, Inc. Micro Channel is a trademark of International Business Machines Corporation. MS-DOS is a trademark of Microsoft Corporation. NetWare and Novell are registered trademarks of Novell, Inc. NetWire is a trademark of Novell, Inc. Novell RX-Net is a trademark of Novell, Inc. OS/2 is a registered trademark of International Business Machines Corporation. PC-DOS is a trademark of International Business Machines Corporation. Personal Computer AT and Personal Computer XT are trademarksof International Business Machines Corporation. Personal System/2 is a trademark of International BusinessMachines Corporation. Token-Ring is a trademark of International Business Machines Corporation. Notes Index A AUTOEXEC.BAT copying to workstation boot diskettes 11 creating for master workstationdiskette 9 B BIND (NET.CFG) 21 Boot disk, workstation booting with 10, 12 creating master 7 creating users' diskettes 11 BUFFERS (NET.CFG) 20 Communication buffers 20 C Computers, workstation requirements 4 CONFIG.SYS 10 D DEFAULT (NET.CFG) 22 DMA (NET.CFG) 23 Drivers. See also LAN drivers accessing information about 13 unloading ODI 14 E EMSNETx.EXE, expanded memory shell file 8 Expanded memory shell 8 Extended memory shell 8 F File server, logging in to 12 FRAME (NET.CFG) 28 H Hardware, workstations supported 4 I IBM Token-Ring Source Routing Driver 31 using with DOS ODI 33 INT (NET.CFG) 24 INT2F.COM file on master workstation diskette 9 IPXODI copying to master workstation diskette 9 explained 2 removing parts of 13 L LAN drivers accessing information about 13 supporting multiple protocols 1 unloading workstation ODI 14 LANSUP.COM driver 9, 30 Link driver LANSUP options 30 Link driver options in NET.CFG 23 LINK STATIONS (NET.CFG) 30 Link support options (NET.CFG) 20 LOOK AHEAD SIZE (NET.CFG) 28 LSL.COM file on master workstation diskette 8 M MEM (NET.CFG) 25 Memory requirements workstation 4 Memory settings for NET.CFG 25 MEMPOOL (NET.CFG) 21 N NET.CFG conventions 18 creating 10, 17 example 18 options 19 using with SHELL.CFG 17 NETBIOS.EXE adding to master workstation diskette 9 Network boards installing in workstations 5 interrupt settings in NET.CFG 24 NETx.COM adding to master workstation diskette 8 NODE ADDRESS (NET.CFG) 26 P PORT (NET.CFG) 26 PRESCAN (NET.CFG) 22 Protocol options in NET.CFG 29 using multiple on a workstation 1 PS/2 SLOT (NET.CFG) 27 PS/2 SLOT ? (NET.CFG) 27 R RAM, workstation memory requirements 4 ROUTE.COM 9 setting parameters for 34 Routing, source. See IBM Token-Ring Source Routing Driver S SAPS (NET.CFG) 30 SEND RETRIES (NET.CFG) 29 SESSIONS (NET.CFG) 22 SHELL.CFG, using with NET.CFG 17 Source routing. See IBM Token-Ring Source Routing Driver T Troubleshooting, workstation installation 13 W Workstation booting 12 hardware requirements 4 installing (DOS ODI) 3 memory requirements 4 troubleshooting 13 X XMSNETx.EXE, extended memory shell file 8