ODI for DOS User's Guide June 1991 Edition Novell, Incorporated 122 East 1700 South P.O. Box 5900 Provo, Utah 84606 USA þ Copyright 1991 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-002 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. 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 Machines Corporation. IBM PC AT/XT are trademarks of International Business Machines Corporation. IBM Personal System/2 is a registered trademark of International Business Machines Corporation. Internetwork Packet Exchange (IPX) is a trademark of Novell, Inc. LANtern 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. Open Data-Link and ODI are trademarks of Novell, Inc. PC-DOS is a trademark of International Business Machines Corporation. Personal Computer AT and Personal Computer XT are trademarks of International Business Machines Corporation. Personal System/2 is a trademark of International Business Machines Corporation. Token-Ring is a trademark of International Business Machines Corporation. Windows is a trademark of Microsoft Corporation. þ Copyright 1991 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 June 1991 Edition Novell Part # 100-000871-002 User Comments We are continually looking for ways to make our products and our manuals as easy to use as possible. You can help us by sharing your comments and suggestions about how our manuals could be made more useful to you and about any inaccuracies or information gaps they may contain. You can submit your comments either by filling out the þUser Commentsþ form at the end of this manual or by writing to us directly at the following address: Novell, Inc. Technical Publications 122 East 1700 South MS C-24-1 Provo, UT 84606 USA We sincerely appreciate your comments about our products. Table of Contents How to Use This Manual iii About DOS ODI 1 Installing ODI for DOS 3 Before you begin 3 Create the master workstation diskette 4 Maintenance tips 6 NET.CFG Options 7 Link Driver drivername 9 Link Support 20 Protocol protocol_name 21 Appendix A: Using the NetWare IPX Shell with ODI23 Installation 23 Using NET.CFG 26 Appendix B: Using the Token-Ring Source Routing Driver29 Installing the source routing driver with DOS ODI30 Setting alternate parameters 31 Appendix C: System Messages 35 Index 61 How to Use This Manual This manual explains how to install Novell's Open Data-Link Interface (ODI) for DOS. You may also need to consult the documentation accompanying the protocols and drivers you are using for product-specific information. þAbout DOS ODIþ offers an overview of ODI's function. þInstalling ODI for DOSþ provides detailed information for installing DOS ODI. þNET.CFG Optionsþ contains configuration information for the NET.CFG file. þAppendix A: Using the NetWare IPX Shell with ODIþ explains how to configure DOS ODI to connect to a NetWare server using IPX and the NetWare shell. þAppendix B: Using the Token-Ring Source Routing Driverþ explains how to install the Token-Ring Source Routing Driver with DOS ODI. þAppendix C: System Messagesþ provides possible explanations and corrections for system messages that you may encounter. About DOS ODI Open Data-Link Interface (ODI) adds functionality to network computing environments by supporting multiple protocols and multiple LAN adapters in a single workstation. ODI creates a þlogical network boardþ to allow multiple frame formats 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, LAT, or TCP/IP) without adding network boards to the workstation. þ You can communicate with a variety of workstations, file servers, and mini and mainframe computers via different protocol stacks without rebooting your workstation. þ You can protect your LAN adapter investment, because all protocols written to ODI specification can communicate through any LAN adapter written to ODI specification. þ 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. You convert a standalone personal computer into a DOS ODI network workstation by adding one or more network boards, cabling, the DOS ODI workstation software, and protocol suite software. Three sets of files allow workstations to þtalkþ to each other, to the file server, and to other hosts. LSL.COM LAN drivers (MLIDs) Protocol stacks The Link Support Layer file enables the workstation to communicate using several protocols. Driver files such as NE2000.COM and TOKEN.COM communicate directly with the LAN boards. Drivers are also called MLIDs (Multiple Link Interface Drivers). Files such as IPXODI.COM and TCPIP.EXE manage communications among network stations. You may need additional files specific to the networking product you are using. The following figure illustrates one configuration that would benefit from using ODI. Because the LSL directs information to the appropriate protocol stack, a user can use TCP/IP services as well as IPX and AppleTalk services. Installing ODI for DOS This section explains how to install DOS ODI. You may also need to consult the documentation accompanying the protocols and drivers you are using for additional information. IPX users should see þAppendix A: Using the NetWare IPX Shell with ODIþ of this manual. TCP/IP users should see the LAN WorkPlace for DOS Administrator's Guide. Before you begin What you need þ A working copy of the DOS ODI Workstation Services diskette þ A þdiskþ (formatted diskette or hard disk) for each workstation to boot from 1. Check the hardware and 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) or compatible 2. Make sure that the network board conforms to your cabling topology (such as ARCnet, Token-Ring, or Ethernet) and that you have a DOS ODI LAN driver for the board. For a listing of drivers supplied by Novell, see the DOS ODI Workstation Services diskette or the driver list on page 10. If an appropriate driver is not provided by Novell, you must obtain one from the board's vendor. Create the master workstation diskette The master workstation diskette contains copies of the files necessary to boot one type of workstation. In this section, you will copy files from the DOS ODI Workstation Services diskette to the master workstation diskette. Then you will either make a workstation boot diskette for each workstation or copy the files from the master workstation diskette to the hard disk from which a workstation boots. 1. Copy the workstation files from the DOS ODI Workstation Services diskette to the master workstation diskette. The following files are required to communicate with a server or host: þ LSL.COM þ The LAN drivers for your network boards (NE2000.COM, for example) The following files are optional: Note:The LANSUP.COM driver should be used on workstations using the IBM LAN Support Program. 2. Put the filenames you need into a batch file on the master workstation diskette. Load the LSL and then the LAN drivers. Your batch file should look similar to the following: LSL NE1000 Note:If you are using a 3COM 3C503 board and want to use DIX cabling, you must specify the DIX connector setting in the NET.CFG file (see page 19) or at the command line when you load the driver by entering a D, as follows: 3C503 D BNC/TP, the default connector setting, does not require command line information. 3. Create a NET.CFG file on the master workstation diskette (optional). You must create a NET.CFG file if, for example, you have changed hardware options on your network board or you are using multiple protocols. See the following section, þNET.CFG Options,þ (on page 7) for more information. You should also see the documentation specific to your protocol. 4. Copy protocol suite files to the master workstation diskette or run the necessary install utilities that came with your protocol suite. Refer to the documentation specific to your protocol. 5. Use the master diskette to connect to the file server or host. 6. Create the workstation boot disk. Copy the master workstation diskette files to each workstation boot diskette or hard disk. From each workstation, connect to the file server or host. Maintenance tips 1. If you cannot communicate on the network, check to see if þ The network board is seated properly. þ Board settings match the values displayed when you loaded the LAN driver. þ Board settings do not conflict with settings for other devices in the machine. þ The cable is connected properly. þ All cabling is terminated properly. þ The workstation node address does not conflict with any other node address on the same physical network. 2. If you want information about a DOS ODI executable, type its name followed by a question mark. For example NE2000 ? or LSL.COM ? 3. If you unload ODI drivers from memory, unload them in reverse order. For example, if you work with two protocols that conflict when both are running concurrently on the workstation or if you need to free memory for large applications, unload the first set of files (in reverse order) before you load the next set. Unload the workstation files as follows: PROTOCOL u (for example, IPXODI u) DRIVER u (for example, NE2000 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 NE1000.þ NET.CFG Options The NET.CFG file is a configuration file that contains section headings and options that deviate from the established defaults of the ODI software. If you changed the default hardware settings on the LAN adapter or if you are using multiple protocols, you probably need a NET.CFG file. You may also need to see the documentation specific to your protocol for additional NET.CFG information. Use any DOS text editor to create the file. Specify only options that will change from the defaults. Conventions Main section headings must be left-justified and are not case sensitive. The heading must precede the options you want to include in that section. Options are not case sensitive and must be preceded by a tab or hard spaces. Precede comments with a semicolon (;). End each line with a hard return. Write all numbers in decimal notation except where noted otherwise. The following are common main section headings in the NET.CFG file: þ Link driver þ Link support þ Protocol Sample NET.CFG file LINK DRIVER NE1000 ; Change the interrupt (IRQ) to 5. INT 5 ; Change the port to 320 (hex) PORT 320 The following sections contain an explanation of each option's function and some possible reasons for changing the setting. In the explanations, these conventions are used: [ ] An optional element number A decimal number hex A hexadecimal number The following chart lists the options defined by the DOS ODI software. Other options may be available for the LAN driver or protocol stack you are using. Refer to their documentation for more information. Main section headings are in white print and flush with the left margin. Options are listed under each heading and indented. Link Driver drivername The following table outlines the NET.CFG options available to LAN drivers on the DOS ODI Workstation Services diskette. Square bullets (þ) indicate options available to both ISA (industry standard architecture) and MCA (microchannel architecture). Options marked with an I are available to ISA only; options marked with an M are available to MCA only. Note:If you are using a LAN driver not listed above, refer to its documentation for parameter applicability. To use this heading, replace drivername with the name of the driver you are using; the name is typically the LAN driver's filename. Replace drivername with one of the following driver names: þ 3C501 (for 3COM EtherLink) þ 3C503 (for 3Com EtherLink Series II) þ 3C505 (for 3COM EtherLink Plus) þ 3C523 (for 3Com EtherLink/MC) þ EXOS (for Novell EXOS205 and EXOS215) þ LANSUP (for the IBM LAN Support program only) þ NE2 (for Novell Ethernet NE/2) þ NE2-32 (for Novell Ethernet NE/2-32) þ NE1000 (for Novell Ethernet NE1000) þ NE2000 (for Novell Ethernet NE2000) þ NE2100 (for Novell Ethernet NE2100) þ PCN2L (for IBM PC Network II and II/A) þ TOKEN (for IBM Token-Ring) þ TRXNET (for Novell RX-Net and Turbo RX-Net) After specifying a drivername, place both hardware commands and software commands under the Link Driver heading. You can specify options for each network board you are using, but you must have a separate þLink Driver drivernameþ heading for each network board. Hardware commands DMA [#1 | #2] channel_number This option specifies the hardware setting of the network board used in the workstation. It allows DMA channels to be configured. Enter the channel number to be used. The default is 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 If, however, you are using the first and second DMA channels, you do need to include the # sign for the second channel. 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 INT [#1 | #2] interrupt_request_number This option specifies which interrupt the network board uses. Use the interrupt request number set on the board. The default 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 INT 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 16 bytes. For example, if you address a board from D0000 to D4000 (bytes), the starting address is D0000 and the range is 400 (paragraphs). 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. All values must be written in hexadecimal notation. 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. 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. Use 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 SLOT number In slot-based machines, the driver usually locates the board by scanning through the slots in order from lowest to highest. The SLOT option directs the driver to eliminate the scan and locate the board in the specified slot. Use the number of the slot into which you inserted the board. The slot number is usually 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 Slot 2 Then place the following lines in your batch file: LSL NE2 NE2 The first NE/2 driver scans for an NE/2 board, finding the board in slot 1. The second NE/2 driver, as directed by the SLOT option, uses the NE/2 board in slot 2. Software commands FRAME frame_type This option enables the frame types used by the network board. Use this option with boards that support multiple frame types. For example, to enable the Ethernet II frame type on an NE1000 board, place the following lines in the NET.CFG file: Link Driver NE1000 Frame ETHERNET_II Usually, Ethernet LAN drivers default to the Ethernet_802.3 frame type; Token-Ring LAN drivers default to the Token-Ring frame type. The following chart lists the supported frame types for each LAN driver supplied by Novell. PROTOCOL name hex_protocol_ID frame_type This option allows new network protocols to be handled by existing LAN drivers. Replace name with the name of the new protocol. Replace hex_protocol_ID with the assigned hexadecimal protocol ID that the protocol is assigned. Replace frame_type with the frame type that the new protocol ID applies to. For example, if you want to use a new protocol XYZ with an NE2- 32 network board, the NET.CFG file would look similar to the following: Link Driver NE2-32 Frame ETHERNET_SNAP Protocol XYZ 904A ETHERNET_SNAP SAPS number If you use the LANSUP driver, you may 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 Note:This option is ignored if another application has already opened the adapter before the LANSUP.COM driver was loaded. LINK STATIONS number If you use the LANSUP driver, you may 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 Note:This option is ignored if another application has already opened the adapter before the LANSUP.COM driver was loaded. ALTERNATE Normally the LANSUP, Token, and PCN2L drivers use the primary adapter. Use this option if you want the driver to use the alternate adapter. Specify ALTERNATE under the appropriate driver section heading, as shown below: Link Driver LANSUP ALTERNATE MAX FRAME SIZE number This option sets the maximum number of bytes that can be put on the wire by the LAN driver. The TOKEN.COM driver's default size is 4216 bytes. But if your board has 8 KB of shared RAM available, the default size is 2168 bytes. The LANSUP.COM driver's default is normally 1144 bytes. However, if you are using the IBM LAN Support Program with an Ethernet device driver, the maximum size is 1496. For TOKEN.COM and LANSUP.COM, the value for number must be a multiple of 8. It must include the number of bytes for the data packet, for adapter overhead (6 bytes), and for the largest possible header (currently, 35 bytes LAN header + 5 bytes SNAP header + 74 bytes protocol header = 114 bytes). If the line speed is 16 Mbps, the value for number may be between 632 and 17,960. If the line speed is 4 Mbps, the value for number must be between 632 and 4464. If you wanted to use 2 KB data packets, the number would be calculated as 2048 + 6 + 35 + 5 + 74 = 2168 then rounded up to the next multiple of 8: 2168. The NET.CFG file would look similar to the following: Link Driver TOKEN MAX FRAME SIZE 2168 Note:When the driver loads, the sign-on message does not reflect the 6 bytes of overhead. Therefore, the MAX FRAME for the above example would be displayed as 2162. CONNECTOR DIX This option configures the 3C503 LAN driver to use the DIX (thick) connector. BNC/TP (thin) is the default. DIX may also be selected at the command line, as in the following example: LSL 3C503 D Link Support BUFFERS communication_number [size] This option configures the number and size of receive buffers that will be maintained by the LSL. The number of communication buffers must be large enough to hold all media headers and the maximum data size. Default: 0 Refer to the documentation for the third-party protocol stacks for possible settings. Buffer size is optional. The minimum size is 618. The total buffer space must fit into approximately 59 KB (number times size). Default: 1130 MEMPOOL number[k] Some protocols use this option to configure the size of the memory pool buffers that the LSL will maintain. The k notation means multiply by 1024. Refer to the protocol documentation for settings. Protocol protocol_name BIND #board_number Usually a protocol binds to the first network board it finds. The BIND option forces the protocol to bind to the boards you specify. Board numbers are displayed when you load the LAN drivers. Replace board_number with logical boards you want the protocol to bind to. For example, if you wanted protocol XYZ to bind to the third logical board, the NET.CFG would look like this: Protocol XYZ Bind #3 To bind protocol XYZ to the second and third logical boards, the NET.CFG would look like this: Protocol XYZ Bind #2, #3 Note:Some protocols do not support binding to multiple boards. Refer to protocol documentation for binding information. Notes: Appendix A: Using the NetWare IPX Shell with ODI This chapter explains how to configure DOS ODI to connect to a NetWare server using IPX and the NetWare shell. It highlights the IPX-specific differences, exceptions, and additons to the information in the first two sections of this manual. You need to focus on the following areas: þ Installation þ Using NET.CFG Installation Follow the installation instructions in the þInstalling ODI for DOS,þ section (page 3) using IPXODI as the protocol suite and using the NetWare shell file. 1. Copy IPXODI.COM from the DOS ODI Workstation Services diskette to the master workstation diskette. 2. Copy the shell file you will use from your NetWare release diskette to the master workstation diskette. (The x in NETx.COM refers to the DOS version that runs on your workstations.) 3. Place IPXODI and then the shell file after the LAN drivers in the batch file you created. Your batch file should look similar to the following: LSL NE1000 IPXODI NET3.COM You can remove parts of IPXODI.COM to save memory. The IPXODI.COM file actually contains three protocols: þ 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), 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. The chart below shows how to load IPXODI without the other two parts of the file. Note:If you will use remote boot with a DOS ODI workstation, follow the remote boot instructions in your NetWare manual, with one addition: include RPLODI.COM in the AUTOEXEC.BAT. The RPLODI.COM file is located on the DOS ODI Workstation Services diskette. Use the following chart to locate remote boot instructions: When you create the batch file, place RPLODI.COM after the LSL but before the driver files, as shown below: LSL.COM RPLODI.COM driver.COM IPXODI NET3 Using NET.CFG When using the NET.CFG options with IPX and the NetWare shell, you need the information contained in this section for the following parameters: þ Link Driver, PROTOCOL þ Link Support, BUFFERS þ Link Support, MEMPOOL þ Protocol, BIND Note:The SHELL.CFG file also contains NET.CFG network configuration information. Any options from the SHELL.CFG file can be specified in the more versatile NET.CFG file. Use the chart below to determine whether to use both .CFG files or to combine them into NET.CFG. If a SHELL.CFG file exists and you place SHELL.CFG options in the NET.CFG file, they will be ignored. See your NetWare installation manual for SHELL.CFG options. Link Driver, PROTOCOL The PROTOCOL parameter assigns a board and frametype combination. If you use a protocol in addition to protocol IPX, you must explicitly include the protocol ID for IPX and for the additional protocol. The NET.CFG would look like the following: Link Driver NE2-32 Frame Ethernet_II Frame Ethernet_802.3 Protocol IPX 0 Ethernet_802.3 Protocol ADD 1234 Ethernet_II The following table lists the protocol IDs for frametypes available with IPX. Link Support, BUFFERS The IPXODI protocol stack does not require the Link Support Layer communication buffers. Link Support, MEMPOOL The IPXODI protocol stack does not require MEMPOOL buffers. Protocol, BIND If you do not specify a BIND parameter, IPXODI binds to the first board it finds. If you are using multiple boards and frametypes, you may want to specify a BIND parameter. For example, if you wanted protocol IPXODI to bind to the third logical board, the NET.CFG would look like this: Protocol IPX Bind #3 In a DOS environment, you can bind IPXODI.COM to only one network board/frametype combination. Appendix B: Using the Token-Ring Source Routing Driver This appendix explains the use of the IBM Token-Ring Source Routing Driver with DOS ODI. The IBM Token-Ring Source Routing Driver enables communication across IBM Token-Ring network bridges. Any type of DOS ODI protocol stack can use this source routing 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. The following figure shows an example network configuration using IBM source routing bridges. Installing the source routing driver with DOS ODI To install source routing on workstations, complete the following steps. 1. Copy the ROUTE.COM file from the DOS ODI Workstation Services diskette to the boot disk. The command to load ROUTE.COM should be added after LANSUP.COM or TOKEN.COM, but before the protocol stack you are using. Note:If you are are using ROUTE.COM with remote boot, you must load ROUTE.COM before the LAN driver in the AUTOEXEC.BAT. See Appendix A for more information. 2. Set the parameters for ROUTE.COM. The default parameters for ROUTE.COM can be used with most network communications. For additional ROUTE.COM parameters see þSetting alternate parametersþ on the next page. Add the parameters at the command line. Note:The ROUTE.COM module can be removed from memory by specifying the u command line switch, as in the following example: ROUTE U Setting alternate parameters 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 online 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. A sample ROUTE file is included on page 34. BOARD = number Use this parameter to specify a board number for the network board. þ If this parameter is not specified, the default of 1 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 batch file for the order you have specified. þ Load ROUTE for each logical board number (frame type) enabled by the Token-Ring LAN driver. 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 broadcast 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. Sample ROUTE.COM The following command shows one possible ROUTE setting: ROUTE BOARD=3, DEF, GBR, MBR If you set these parameters, ROUTE.COM would do the following: þ Send packets through logical board 3 þ Send all frames that are not addressed in the workstation's source routing table as All Routes Broadcast þ Send General Broadcast frames as All Routes Broadcast þ Send Multicast Broadcast frames as All Routes Broadcast When the NODES parameter is not set, ROUTE assumes the default of 16. The CLEAR and REMOVE parameters are not needed for the initial load of ROUTE.COM. However, if a bridge goes down, you can reload ROUTE with these parameters to reconfigure the Source Routing table. Note:For more information on using source routing, see the IBM Token- Ring Network Architecture Reference manual. Appendix C: System Messages Connector is BNC/TP (Thin). Source: 3C503.COM Explanation: The connector selected for the board is for Thin Ethernet cabling. Action: None. Connector is DIX (Thick). Source: 3C503.COM Explanation: The connector selected for the board is for Thick Ethernet cabling. Action: None. FATAL: 3C501 -Card not found. Source: 3C501.COM Explanation: The 3C501 card did not respond to a reset command by the 3C501.COM driver at the specified I/O port settings. Action: Make sure a 3C501 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 not found. Source: 3C503.COM Explanation: The 3C503.COM driver could not locate a 3C503 board at the specified hardware settings. Action: Make sure 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 hardware settings that conflict with other installed boards. FATAL: 3C503 -Interrupt is invalid (2, 3, 4, 5, and 9 valid). Source: 3C503.COM Explanation: An invalid interrupt was selected in the NET.CFG file. Action: Correct the NET.CFG entry with a valid interrupt. FATAL: 80186 Failed to Reset Properly. Source: EXOS.COM Explanation: The 80186 on the EXOS 205/215 board failed to function properly. Action: Try a different slot. If the error persists, replace the board. FATAL: 82586 Failed in IA Setup. Source: EXOS.COM Explanation: The 82586 on the EXOS 205/215 board could not set the individual node address. Action: Try a different slot. If the error persists, replace the board. FATAL: 82586 Failed to Configure Properly. Source: EXOS.COM Explanation: The 82586 on the EXOS 205/215 board failed to configure itself properly. Action: Try a different slot. If the error persists, replace the board. FATAL: 82586 Failed to Diagnose Command. Source: EXOS.COM Explanation: The 82586 on the EXOS 205/215 board failed its self- diagnostics routines. Action: Try a different slot. If the error persists, replace the board. FATAL: 82586 Failed to Reset Properly. Source: EXOS.COM Explanation: The 82586 on the EXOS 205/215 board failed to initialize. Action: Try a different slot. If the error persists, replace the board. FATAL: 82586 Failed to Start RU Properly. Source: EXOS.COM Explanation: The 82586 on the EXOS 205/215 board was unsuccessful in getting the receive unit to start. Action: Try a different slot. If the error persists, replace the board. FATAL: An Interrupt Failed to Occur During Dir.Open.Adapter. Source: TOKEN.COM Explanation: After the Dir.Open.Adapter command was given, the adapter failed to respond. Action: Try a different slot. If the error persists, replace the adapter. 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: Bring Up Error After Call to DIR.Initialize = xx. Source: TOKEN.COM Explanation: DIR.Initialize has returned a value for the bring-up diagnostics result code of xx. Action: For the description of the actual error, refer to the interface chapter of the IBM Local Area Network Technical Reference. 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: Register a protocol ID for IPX along with the other Protocol IDs you are registering. Refer the chart on page 27 for a listing of IPX protocol ID numbers. 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 could not 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 scans 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 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 scans the PS/2 slots to find the NE2-32 board it should use. The driver starts scanning at slot 1. The driver could not find an NE2-32 in any slot. Action: Make sure 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 an IPX interrupt has been hooked. Source: IPXODI Explanation: You tried to unload the IPX from memory, but IPX detected a condition that would not allow it to be removed 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 it. þ 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: Dir.Open.Adapter Failed to Respond Properly. Source: TOKEN.COM Explanation: After receiving false completions and trying several times to get the card to respond to the Dir.Open.Adapter command, the driver has given up. Action: Try a different slot. If the error persists, replace the card. FATAL: Dir.Open.Adapter:-Lobe Media... -Physical Insertion... -Addr. Verification... -Ring Poll... -Request Parameters... Action: Refer to the þToken-Ring Network Adapter Open errors for all CCBSþ section in Appendix B of the IBM Local Area Network Technical Reference. FATAL: Dir.Open.Adapter: Returned Error Code = xx. Source: TOKEN.COM Explanation: The Dir.Open.Adapter call has returned an error code. Action: The driver will try again. The definition of the error code is in the interface chapter of the IBM Local Area Network Technical Reference. 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 trying to remove the resident MLID from memory. The MLID could not 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: EXOS 215 Card Not Found. Source: EXOS.COM Explanation: The EXOS.COM driver scans by default through all the slots starting at slot 1. Either the EXOS 215 board was not present in the slot designated by the NET.CFG file, or the driver could not find the board at all. Action: Verify the EXOS 215 card is installed and the slot number is described correctly by the NET.CFG if the file is present. FATAL: EXOS Card Memory Failure. Source: EXOS.COM Explanation: The EXOS 205/215 has not passed the memory test. Action: If the card's jumper settings are not the defaults, verify that they match the NET.CFG file's settings. If the settings match, try a different slot. If the error persists, replace the board. 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 board are installed in the workstation, you must specify an associated MLID section heading 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: Install the LAN Support Software using the IBM-supplied DXMAID utility and retry the operation. 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, it can 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 IBM 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 ADDRESS 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 long. 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³ ÀÄÁÄÁÄÁÄÁÄÁÄÁÄÁÄÙ 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, U for unload, D to load IPX and SPX only, and A to load IPX only. 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. FATAL: Invalid Token-Ring node address specified. Source: MLID Explanation: You used the NODE ADDRESS 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 long. This error occurs 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³ ÀÄÁÄÁÄÁÄÁÄÁÄÁÄÁÄÙ 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 it 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 board are installed in the workstation, you must specify an associated MLID section heading 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 LSL has already been loaded. It 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: The 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 an INT 2F multiplex interrupt; then load the LSL. 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: 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: 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: 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 supports the NE2000 only 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: No more room in the LSL for another protocol stack. Source: IPXODI Explanation: The maximum number of protocol stacks has been registered with the LSL. The DOS ODI LSL can support up to eight protocol stacks. Action: Remove an existing protocol stack. FATAL: No room in LSL for board using FRAME . Source: MLID Explanation: The maximum number of boards, whether virtual or physical, has been registered with the LSL. The DOS ODI LSL can support up to eight boards. Action: Reduce the number of active boards in the system by unloading a board or by decreasing the number of frame types activated by the MLID. 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 an RX-Net board is installed in the workstation and 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 slot contains an NE2 but it is not enabled. Source: NE2.COM Explanation: The located NE2 board was not enabled. It has probably malfunctioned. Action: Replace the board. FATAL: Specified slot contains an NE2-32 but it is not enabled. Source: NE2-32.COM Explanation: The located NE2-32 board was not enabled. It has probably malfunctioned. Action: Replace the board. FATAL: Specified slot does not contain an enabled 3C523 adapter. Source: 3C523.COM Explanation: A 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 to specify the correct number. FATAL: Specified slot does not contain an NE2 adapter. Source: NE2.COM Explanation: A 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 slot does not contain an NE2-32 adapter. Source: NE2-32.COM Explanation: A SLOT number option was specified in the NET.CFG, 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: The 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: Token-Ring Adapter Not Found at Designated Slot/IO Port. Source: TOKEN.COM Explanation: The TOKEN.COM driver by default scans each slot on a microchannel machine. If a Token-Ring card is located, the I/O port address is checked to determine if the correct board has been found. Either the Token-Ring card is not present or the NET.CFG does not reflect the POS register settings. Action: Verify that the Token-Ring card is installed. Verify that the NET.CFG and the POS registers correctly describe the desired configuration. FATAL: Token-Ring Buffer Memory Failure. Source: TOKEN.COM Explanation: The TOKEN.COM card has failed the shared RAM memory test by the driver. Action: Try a different slot. If the error persists, replace the board. FATAL: Token-Ring Hardware Failed to Respond After Retry. Source: TOKEN.COM Explanation: The TOKEN.COM driver has tried twice to initialize the Token-Ring card and failed. Action: Try a different slot. If the error persists, replace the board. FATAL: Token-Ring Hardware failure during card initialize. Source: TOKEN.COM Explanation: The TOKEN.COM driver waited for the card to complete its internal diagnostics and produce an interrupt, but the card has not responded. Action: Try a different slot. If the error persists, replace the board. FATAL: Token-Ring Shared RAM is on Incorrect Boundary. Source: TOKEN.COM Explanation: The TOKEN.COM driver has found the base address for shared RAM is not on a 16K boundary. Action: Verify that the addresses given in the NET.CFG file do not conflict and that they match the jumper (ISA) or POS (MCA) settings. FATAL: Token-Ring Signature Hardware Failure. Source: TOKEN.COM Explanation: The TOKEN.COM card failed the signature test. Action: Verify that the Token-Ring card is installed and that the settings in the NET.CFG match the jumper settings (ISA) or that POS register values (MCA) are correct. FATAL: Token-Ring ROM/MMIO Domain and Shared RAM Overlap. Source: TOKEN.COM Explanation: The base address settings for the shared RAM and the ROM/MMIO are too close and overlap. Action: Change the base address settings for the shared RAM or the ROM/MMIO. 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 exceed the 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. Inserting into ring...Please wait Source: TOKEN.COM Explanation: The Token-Ring card is trying to insert into the Token- Ring. Action: None. IPX protocol bound to MLID Board # . Source: IPXODI Explanation: This message is displayed after IPX has loaded successfully. 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 1based (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 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. MLID successfully removed. Source: MLID Explanation: A request was made to unload an MLID, and the MLID 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. (The 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 in the LSL. The size of the LSL's communications buffers (106 bytes 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. Programmed I/O Mode Selected. Source: 3C503.COM Explanation: The adapter is jumpered with the shared RAM disabled. The driver and adapter support either shared RAM or programmed I/O. Action: To configure the adapter for shared RAM mode, change the jumpers to the appropriate settings for the base-shared RAM address. Trying again...Dir.Open.Adapter Return Code = xx. Source: TOKEN.COM Explanation: The Dir.Open.Adapter call has returned an error code. Action: The driver will try again. The definition of the error code is in the interface chapter of the IBM Local Area Network Technical Reference. WARNING: 3C503 DMA Mode not Supported Source: 3C503.COM Explanation: The 3C503.COM supports only programmed I/O or shared RAM modes. The NET.CFG contains a DMA entry. The driver issues this warning and ignores the setting. Action: DMA is not supported with this driver. Use either programmed I/O or shared RAM mode. Shared RAM mode is faster. WARNING: 3C503 NET.CFG Specified Shared RAM Address--NIC Configured PIO. Source: 3C503.COM Explanation: The 3C503 adapter is shipped with the shared RAM memory disabled. The NET.CFG file has specified a shared RAM address, and the adapter is jumpered with memory disabled. This is not fatal, however; the driver supports both shared RAM and programmed I/O (PIO) modes. The driver will use PIO mode without modification. Action: Set the jumper on the adapter to the appropriate address if you want shared RAM mode. Shared RAM mode is faster than PIO or DMA modes. The 3C503.COM driver supports only shared RAM and PIO modes. 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 is valid. 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: Frame type is already activated--duplicate entry ignored. Source: MLID Explanation: Two FRAME keywords under the same main section heading specified the same frame type. A specific frame type can be specified only once per driver. Action: Remove the duplicate entry. WARNING: Max Frame Size is too Large in NET.CFG. Max = 17960. Source: TOKEN.COM Explanation: The NET.CFG file has defined the maximum frame size to be larger than the maximum allowed value. Action: Adjust the NET.CFG entry. The driver will use the maximum value until the correction is made. WARNING: Max Frame Size is too Small in NET.CFG. Min = 632. Source: TOKEN.COM Explanation: The NET.CFG file has defined the minimum frame size to be smaller than the minimum allowed value. Action: Adjust the NET.CFG entry. The driver will use the minumum value until the correction is made. 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 omissions of required dashes and underscores or misspellings. Check the MLID documentation for supported frame types. 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: 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 should look similar to the following: LINK DRIVER NE1000 PROTOCOL IPX 8137 ETHERNET_II Action: Specify a frame type with the PROTOCOL option. Index A ALTERNATE (NET.CFG) 17 B Batch file, creating for master workstation diskette 5 BIND (NET.CFG) 21 BOARD (ROUTE.COM) 31 Boot disk, creating master 4 Bridges, IBM source routing 29 BUFFERS (NET.CFG) 20 C CLEAR (ROUTE.COM) 32 CONNECTOR (NET.CFG) 19 Connector setting, 3C503 board 5 D DEF (ROUTE.COM) 32 DMA (NET.CFG) 11 E EMSNETx.EXE, expanded memory shell file 23 Expanded memory shell 23 Extended memory shell 23 F FRAME (NET.CFG) 15 G GBR (ROUTE.COM) 32 H Hardware, workstations supported 3 I IBM Token-Ring network bridge 29 IBM Token-Ring Source Routing Driver guidelines for using 29 installing with DOS ODI 30 using with ROUTE.COM 30 INT (NET.CFG) 12 IPXODI copying to master workstation diskette 23 loading and unloading 23 removing parts of 24 L LAN drivers accessing information about 6 configuration options 9 drivernames 10 loading 4 NET.CFG options 9 supporting multiple protocols 1 unloading 6 LAN SUPPORT, adding device drivers for 4 LAN WorkPlace for DOS 3 LANSUP.COM driver 4 LINK STATIONS (NET.CFG) 17 Link support options (NET.CFG) 20 LSL.COM 2, 4, 6 M MAX FRAME SIZE (NET.CFG) 18 MBR (ROUTE.COM) 33 MEM (NET.CFG) 13 Memory saving 24 setting for NET.CFG 13 MEMPOOL (NET.CFG) 20 N NET.CFG conventions 7 creating 5 example 7 options 8, 9 using with SHELL.CFG 26 NETx.COM on master workstation diskette 23 NODE ADDRESS (NET.CFG) 14 NODES (ROUTE.COM) 33 P PORT (NET.CFG) 13 PROTOCOL (NET.CFG) 16 Protocol, options in NET.CFG 21 protocol, unloading 6 R Remote boot 25 Remote Diagnostics Responder, unloading 24 REMOVE (ROUTE.COM) 33 ROUTE.COM 30 S SAPS (NET.CFG) 17 Shell files 23 SHELL.CFG 26 SLOT (NET.CFG) 14 Source routing driver 29 SPX, unloading 24 T Troubleshooting, installation 6 X XMSNETx.EXE, extended memory shell file 23 User Comments Novell manuals and Novell products We at Novell would like to hear from you if you have comments about our manuals and products, or have suggestions for improving them. Please address responses to Novell, Inc. NPD Technical Publications 122 East 1700 South MS C-24-1 Provo, UT 84606 USA Please indicate the relevant chapters and page numbers and other pertinent information as requested below. Product Name: Manual Name: ODI for DOS User's Guide Part Number: 100-000871-002 Your Name: Company Name: Address: City: State/Province: Country: Zip/Postal Code: Phone Number: ( ) FAX Number: ( ) Comments or suggestions