                     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 <Ctrl> <Alt> <Delete>
simultaneously.


Log in to the file server.
If your AUTOEXEC.BAT file does not contain login commands, type

F:  <Enter>
LOGIN SUPERVISOR  <Enter>     



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 ?  <Enter>

or

LSL.COM ?  <Enter>

or

IPXODI ?  <Enter>

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  <Enter>
IPXODI u  <Enter>
NE2 u  <Enter>
LSL u  <Enter>

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 ?  <Enter>

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 # <number> 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 <name> 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 <name> 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
        Ŀ
        00000001     
        

      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
        Ŀ
        10000000     
        

      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 <name> 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 <name> MLID Board # <number>.

      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.

      <name>      The MLID's short name (NE1000, for example).

      <number>    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 <number1>, Buffer size <size> bytes, Memory pool
<number2> 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.)

      <number1>         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.

      <size>            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.

      <number2>         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.


<name> 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=<name>, PID=<number>,
Frame=<type>

      Source:  MLID

      Explanation:  The MLID could not register the specified Protocol
      ID.  

      <name>      The name of the protocol.

      <number>    The value of the Protocol ID used to register the
                  Protocol ID.

      <type>      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 <type> - 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 <number> 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
