CMDGODI.LAN - 32-bit ODI Driver
===============================
                                               LSS 5.0(0), August 1996
                                               -----------------------
Summary
-------

This  file contains information relating to CMDGODI.LAN - a 32-bit ODI 
driver for Madge Smart Ringnodes, based on Madge Fastmac Plus  adapter 
MAC  code.  CMDGODI.LAN runs on Novell NetWare 3.x and 4.x servers and 
on NetWare client workstations.

This file contains the following information:

  (1)  Associated Files
  (2)  Driver Overview
  (3)  Supported Environments
  (4)  Supported Adapters
  (5)  Client32 Overview
  (6)  Loading the Driver
  (7)  Required Support Modules
  (8)  PCMCIA Support
  (9)  Using Machines with over 16Mb RAM
  (10) Memory Usage
  (11) Adapter Mirroring Support
  (12) Statistics
  (13) Lost Interrupt Alerts
  (14) Using IBM LAN Client Software
  (15) Driver Parameters

For further information, refer  to  the  User  Documentation  and  the 
appropriate  Novell  documentation.  Latest  Novell information can be 
accessed from the Novell World Wide Web   sites   www.novell.com   and 
netwire.novell.com.


(1) Associated Files
--------------------

CMDGODI.LAN - The driver.
CMDGODI.LDI - NetWare installation script.
ODICMDG.INF - Windows 95 installation script.


(2) Driver Overview
-------------------

CMDGODI.LAN is a 32-bit ODI driver  written  to  Novell's  C  Language 
Hardware  Support  Module  (HSM)  specification, part of Novell's Open 
Data-Link Interface (ODI) architecture.  The ODI  architecture  allows 
multiple  adapters  and  multiple  protocols  to  co-exist in the same 
machine.

Within the ODI architecture, network drivers are termed Multiple  Link 
Interface  Drivers  (MLIDs).  An  MLID consists of a Hardware Specific 
Module (HSM) plus a  Topology  Specific  Module  (TSM)  plus  a  Media 
Support  module.  HSMs  (e.g. CMDGODI.LAN)  are  typically provided by 
network equipment vendors whilst the TSM and MSM modules are  provided 
by  Novell. Novell provide TSMs for the common network topologies, the 
TSM which supports Token Ring is called TOKENTSM.NLM. The MSM and  TSM 
modules  provide  support to the HSM and allow the HSM to be operating 
system  independent  which  is  important  for  providing  portability 
between different client and server environments.

A   single   MLID   can   support  multiple  adapters  simultaneously, 
CMDGODI.LAN supports up to nine adapters within a single machine. Each 
adapter  may  support  up  to  two   frame   types   (TOKEN-RING   and 
TOKEN-RING_SNAP).  The frame types required depends upon the protocols 
loaded in the system.

A  software  layer  called  the  Link  Support  Layer  (LSL)   handles 
communication  between  multiple  protocols  and  multiple adapters. A 
protocol is bound to a specific logical board (adapter  /  frame  type 
combination).  When a frame is transmitted by a protocol, the frame is 
passed to the LSL which then passes the frame to  the  relevant  MLID/
adapter for transmission onto the wire. When a frame is received by an 
adapter  off the wire, the MLID passes the frame to the LSL which then 
passes the frame to the relevant protocol.


(3) Supported Environments
--------------------------

Historically, 32-bit HSM  drivers  (.LAN  drivers)  only  executed  on 
NetWare  3.x  and  4.x  servers.  Novell's  Client32  architecture now 
provides support for 32-bit HSM drivers on client  workstations  under 
operating systems such as DOS and Windows 95.

The Client32 architecture makes use of the inherent portability of HSM 
drivers  provided  by  the  MSM  and  TSM  layers. To run an HSM under 
different operating systems, MSM and TSM modules for each  environment 
must be provided but the HSM remains unchanged.

Currently, the following environments are supported:

- DOS/Windows 3.1 client (Client32).
- Windows 95 client (Client32).
- NetWare 3.x and 4.x server.

In addition to NetWare environments,  32-bit  HSM  drivers  (including 
CMDGODI.LAN)  may  be  used  in  the  IBM  LAN Client environment. See 
Section 14 for more details.


(4) Supported Adapters
----------------------

CMDGODI.LAN supports all Madge Smart 16/4  Ringnodes,  and  the  Madge 
Smart 16 Ringnode.


(5) Client32 Overview
---------------------

(5.1) General
-------------
Client32  is  Novell's new NetWare client architecture. It is based on 
32-bit networking components (drivers, protocol stacks and requesters) 
and allows 32-bit HSM drivers, such as CMDGODI.LAN  and  MADGEODI.LAN, 
to be loaded on client workstations as well as NetWare servers. 

At the heart of Client32 is the NetWare  I/O  subsystem  (NIOS).  This 
software layer provides partial NetWare operating system emulation and 
acts  as  a  loader for NLM format executables such as LAN drivers. It 
provides the interface between  the  host  operating  system  and  the 
32-bit networking components.

(5.2) Client32 for DOS/Windows
------------------------------
Under DOS, NIOS is implemented as a single executable called NIOS.EXE. 
An  extended  memory  (XMS) manager, such as HIMEM.SYS, must be loaded 
prior to loading NIOS. Once NIOS.EXE is loaded the "LOAD" and "UNLOAD" 
keywords may be used at the command prompt  to  dynamically  load  and 
unload NLMs (including .LAN drivers and protocols) in extended memory. 

The use of extended memory (memory above 1Mb) means that  the  sub-1Mb 
memory footprint of Client32 under DOS is very small, typically around 
4Kb. NIOS will use upper memory blocks (UMBs) if they are available in 
preference to conventional memory. UMBs are blocks of memory allocated 
by a memory manager, such as EMM386, in the 640Kb-1Mb region. To  make 
UMBs  available,  a  memory  manager  must be loaded and the "DOS=UMB" 
command must be added to CONFIG.SYS.  Refer  to  your  memory  manager 
documentation for more details.

For information on how to reduce the extended memory usage of  CMDGODI 
in DOS workstations, see the "Memory Usage" section.

16-bit  ODI drivers, such as MADGEODI.COM, can be used in the Client32 
environment. A 16-bit ODI driver is loaded as normal into conventional 
memory  and  the  Novell   provided   32-bit   virtual   LAN   driver, 
PC32MLID.LAN, is used to allow protocols executing in 32-bit protected 
mode  to communicate with the 16-bit driver. This configuration is not 
recommended  -  32-bit  ODI  drivers  give  greater  performance   and 
conventional memory savings.

IPX protocol support is provided by IPX.NLM.

A  new client requester, CLIENT32.NLM, is provided to replace the NETX 
shell or VLM  DOS  Requester.  The  Client32  requester  is  backwards 
compatible with the NETX and VLM APIs so existing NetWare applications 
should  still  function.  CLIENT32.NLM supports packet burst transfers 
for increased performance, file caching and NetWare Directory Services 
(NDS) functionality.

(5.2) Client32 for Windows 95
-----------------------------
Native  network  drivers  for  Windows  95  are  written to the NDIS-3 
specification. The NDIS-3 Miniport driver for Madge Smart Ringnodes is 
called MDGMPORT.SYS.  The  Client32  architecture  allows  32-bit  ODI 
drivers  to  be  used in the place of NDIS-3 drivers under Windows 95. 
The Client32 for Windows 95 requester can use either an NDIS-3  or  an 
ODI  driver.  As with Client32 for DOS, 16-bit ODI drivers may also be 
used although this configuration is not recommended.

The  Client32  requester  for Window 95 replaces the NetWare requester 
provided by Microsoft. 

An ODI->NDIS3 mapper (ODINSUP) is provided by Novell so that Microsoft 
networking components which use the NDIS-3 interface can be used  with 
an ODI driver.


(6) Loading the Driver
----------------------

(6.1) Loading the Driver (NetWare Server)
-----------------------------------------

(6.1.1) Basic Usage
-------------------
CMDGODI.LAN  may  be  loaded  on  a NetWare 3.12 or 4.x server. At the 
server command line, or in AUTOEXEC.NCF, enter the following:

  LOAD CMDGODI [PORT=<n> | SLOT=<m>] [<options>]

If the TOKENTSM.NLM, MSM.NLM and NBI.NLM modules have not already been 
loaded they will be auto-loaded.

It is only necessary to specify a PORT or SLOT number if more than one 
adapter exists in the machine. If multiple adapters exist and no  PORT 
or  SLOT  parameter  is  given, you will be prompted to choose a value 
from a list. "LOAD  CMDGODI  DISPLAY"  can  be  used  to  display  the 
adapters in the machine at any time.

(6.1.2) Specifying Frame Type
-----------------------------
To  specify  the  frame  type, use the FRAME= parameter on the command 
line. Both TOKEN-RING and TOKEN-RING_SNAP frame types  may  be  loaded 
simultaneously  on  the same adapter. The frame types required depends 
on the protocols you wish to use. For  example,  IPX  uses  TOKEN-RING 
frames but TCP/IP uses TOKEN-RING_SNAP frames. Example:

  LOAD CMDGODI PORT=1000 FRAME=TOKEN-RING
  LOAD CMDGODI PORT=1000 FRAME=TOKEN-RING_SNAP

(6.1.3) Protocol Binding
------------------------
The BIND command is used to bind a logical instance of the driver to a 
protocol  stack.  The  NAME=  parameter  can  be  used to override the 
default name (CMDGODI). Example:

  LOAD CMDGODI PORT=1000 NAME=adapter1
  LOAD CMDGODI PORT=2000 NAME=adapter2
  BIND IPX TO adapter1 NET=10
  BIND IPX TO adapter2 NET=20

(6.1.4) Using Source Routing
----------------------------
If you need to use source routing, Novell's ROUTE.NLM must be  loaded. 
Source routing must be used if NetWare servers are to communicate with 
workstations  across a source routing bridge. In the following example 
CMDGODI.LAN is loaded onto two adapters with two frame types each  and 
source routing is loaded for each logical board:

  LOAD CMDGODI PORT=1000 FRAME=TOKEN-RING NAME=adapter1
  LOAD ROUTE BOARD=1
  LOAD CMDGODI PORT=1000 FRAME=TOKEN-RING_SNAP NAME=adapter1_SNAP
  LOAD ROUTE BOARD=2
  LOAD CMDGODI PORT=2000 FRAME=TOKEN-RING NAME=adapter2
  LOAD ROUTE BOARD=3
  LOAD CMDGODI PORT=2000 FRAME=TOKEN-RING_SNAP NAME=adapter2_SNAP
  LOAD ROUTE BOARD=4

(6.1.5) Enabling Ring Status Warnings
-------------------------------------
If you want abnormal ring status conditions (single station, beaconing 
etc.)  to  be reported to the console, "WARN=YES" must be specified on 
the command line. See the "Driver Parameters" section.


(6.2) Loading the Driver (Client32 for DOS/Windows 3.1)
-------------------------------------------------------
You  will require the Novell Client32 for DOS/Windows 3.1 installation
disks to install CMDGODI.LAN in this environment.

(6.2.1) Installation
--------------------
CMDGODI.LAN may be loaded  on  DOS  client  workstations  with  Novell 
Client32   software   installed.   To   install  CMDGODI.LAN  in  this 
environment,  run  the  Novell  Client32  installation  utility.  When 
prompted  to  choose  an  adapter card to use, select "OTHER DRIVERS". 
When  prompted,  enter  the  path  where  the  files  CMDGODI.LDI  and 
CMDGODI.LAN  can  be  found.  Select "Madge C Hardware Support Module" 
from the driver list to install CMDGODI.LAN.

The Novell installation  utility  will  install  all  required  client 
software  and  will  create  a  STARTNET.BAT  file  which contains the 
commands required to load the  driver,  protocol  and  requester.  The 
STARTNET.BAT file should look similar to the following example:

SET NWLANGUAGE=ENGLISH
NIOS.EXE
LOAD LSLC32.NLM
LOAD CMSM.NLM
LOAD TOKENTSM.NLM
LOAD CMDGODI.LAN
LOAD IPX.NLM
LOAD CLIENT32.NLM

Driver parameters can be specified on the  "LOAD CMDGODI.LAN"  command 
line,  for example "LOAD CMDGODI.LAN PORT=A20 FRAME=TOKEN-RING".  Note 
that driver parameters are not put in the NET.CFG file.

It  is  recommended  that  the "OS=DOS" parameter is specified so that 
CMDGODI allocates less host buffer  memory.  See  the  "Memory  Usage" 
section for more details.

Any file loaded using "LOAD <name>" can be unloaded by typing  "UNLOAD 
<name>"  at  the DOS prompt. Note that files should be unloaded in the 
reverse order to which they were loaded.

(6.2.2) Using Source Routing
----------------------------
If  the  client  needs  to  communicate  with  servers across a source 
routing bridge, the source routing support module, SROUTE.NLM, must be 
loaded  using  "LOAD SROUTE". If required, SROUTE.NLM should be loaded
after loading CMDGODI.LAN and before loading CLIENT32.NLM.


(6.3) Loading the Driver (Windows 95)
-------------------------------------
You will require the Novell Client32 for Windows 95 installation disks
plus the Windows 95 CD-ROM to install CMDGODI.LAN in this environment.

Before  installing CMDGODI.LAN in this environment for the first time, 
ensure that all currently installed networking components are removed. 
To remove networking components, go to the "Network" dialogue box  and 
select and "Remove" each component in turn.

(6.3.1) First Time Installation
-------------------------------
To install CMDGODI.LAN in the Client32 for Windows 95 environment, run 
the  Novell Client32 installation utility from the Novell installation
disks. From the "Select Network adapter" window,  select  "Have Disk".
Enter the path where the files  ODICMDG.INF  and  CMDGODI.LAN  can  be
found. Follow the on-screen instructions to complete the installation.

You should delete the files NETMADGE.INF  and  ODIMADGE.INF  from  the 
\WINDOWS\INF  directory  if they exist.  These files are used to auto- 
install other Madge drivers when new Madge hardware is detected. It is 
recommended that you copy ODICMDG.INF into the \WINDOWS\INF  directory 
after  the  first time installation. This will allow CMDGODI.LAN to be 
automatically installed if Madge adapters are installed in the machine 
at a later time.

(6.3.2) Subsequent installation (Non-Plug'n'Play)
-------------------------------------------------
From  the  "Network" dialogue box, choose "Add" followed by "Adapter".
If   you  have  previously  copied  ODICMDG.INF  to  the  \WINDOWS\INF
directory  (recommended), select Madge from the list of manufacturers.
Otherwise  choose "Have Disk" and insert a disk containing ODICMDG.INF
and  CMDGODI.LAN.  From the list of adapters presented, choose the one
you wish to install and click "OK" to continue installation.

(6.3.3) Subsequent installation (Plug'n'Play)
---------------------------------------------
If  ODICMDG.INF  has  been  copied into the \WINDOWS\INF directory (as 
recommended) prior to installing the  new  adapter,  Windows  95  will 
automatically install CMDGODI.LAN for that adapter next time it boots, 
provided  the  adapter is Plug'n'Play compatible. Plug'n'Play adapters 
include PCI, EISA, MC, PCMCIA, AT PnP, and ISA PnP adapters.

(6.3.4) Non-Plug'n'Play Adapter Resources
-----------------------------------------
The  resources  of  non-Plug'n'Play adapters must be entered using the 
"Network" dialogue box. Highlight the Madge Ringnode and click on  the 
"Properties"  button followed by the tab labelled "Resources".  If the 
interrupt number and DMA channel specified in the "Resources" dialogue 
box  are  different  to  the  settings on the adapter, the driver will 
attempt to override  the  current  card  settings  with  those  values 
specified  if the adapter is software-configurable.  If the adapter is 
programmed to use a transfer mode other than DMA, enter a value  of  0 
for the DMA channel in the "Resources" dialogue box.

(6.3.5) Editing Driver Parameters
---------------------------------
When the driver is installed, driver parameters can be configured from 
the  "Network" dialogue box. Highlight the Madge Ringnode and click on 
the  "Properties" button. Advanced  parameters  can be specified using
the  "Advanced"  dialogue box. See the "Driver Parameters" section for
more details.

(6.3.6) Using Source Routing
----------------------------
If  the  client  needs  to  communicate  with  servers across a source 
routing bridge, source routing  must  be  enabled.  From  the  Network 
dialogue   box,   highlight  the  Madge  Ringnode  and  click  on  the 
"Properties" button. Source routing is configured  using  the  "SRoute 
32"  dialogue  box;  check the "Enabled" box for the frame types which 
require source routing support.


(7) Required Support Modules
----------------------------

CMDGODI.LAN requires the following support modules for  the  different 
environments (all modules are supplied by Novell) :

NetWare 4.x server :
   TOKENTSM.NLM, version 3.01 or later.
   MSM.NLM, version 3.03 or later.
   NBI.NLM, version 1.30 or later

NetWare 3.12 server :
   TOKENTSM.NLM, version 3.01 or later.
   MSM31X.NLM, version 3.03 or later.
   NBI31X.NLM, version 1.30 or later

Client32 for Windows 95 :
   TOKENTSM.NLM, version 1.00 or later
   CMSM.NLM, version 1.00 or later
   LSLC32.NLM, version 1.00 or later

Client32 for DOS / Windows 3.1 :
   TOKENTSM.NLM, version 1.00 or later
   CMSM.NLM, version 1.00 or later
   LSLC32.NLM, version 1.00 or later
   NIOS.EXE, version 2.01 or later

Note  that NLMs which execute on the server and those which execute on 
client  workstations  are  not  generally  interchangeable  (with some 
exceptions). For example, TOKENTSM.NLM v3.01 which is provided for the 
NetWare  server  environment  can't  be used on Client32 workstations. 
Similarly, TOKENTSM.NLM v1.00  which  is  provided  for  the  Client32 
environment can't be used on the NetWare server.


(8) PCMCIA Support
------------------

(8.1) PCMCIA Support (DOS)
--------------------------

(8.1.1) Required Software
-------------------------
To use Madge  Smart  PCMCIA  adapters  in  a  DOS  client  workstation 
requires  Card  and  Socket  Services  plus  a card management utility
(enabler)  which automatically  configures  the  adapter's IO port and
IRQ channel upon adapter detection.

(8.1.2) Using PCMCIA Ringnodes in MMIO Mode
-------------------------------------------
To use a PCMCIA adapter in MMIO mode,  a  4K  memory  window  for  the 
adapter must be configured using the card management utility. The base 
address  of  this window must be passed to the driver using the "MEM=" 
parameter (see the "Driver Parameters" section).

Ensure that Card Services (or MADGECS) has enough memory in its memory 
resource list to support PCMCIA adapters in MMIO mode. 4K is  required 
per  adapter using MMIO, plus an additional 4K for use as workspace to 
map in the card's CIS for adapter identification purposes. For example 
if the machine contains two PCMCIA adapters, both in MMIO  mode,  then 
Card  Services must have at least three 4K contiguous blocks of memory 
available. 

By default MADGECS has an 8K memory range in its  resource  table.  If 
two  PCMCIA  cards are used in MMIO mode then another 4K must be added 
to MADGECS' memory resource list, using  the  MEM=  parameter  in  the 
MADGECS  configuration  file.  Failure  to  do this will result in the 
cards not being located when CMDGODI.LAN is loaded because MADGECS has 
no memory space into which it can map  the  cards'  CIS  in  order  to 
identify the cards.

(8.1.3) Using MADGECS
---------------------
MADGECS.EXE (v1.14 or later) may be used instead of Card (and  Socket) 
Services  if  only  Madge  Smart PCMCIA adapters are to be used in the 
machine (MADGECS does not support non-Madge PCMCIA adapters,  such  as 
modem  cards). MADGECS gives memory savings over other Card and Socket 
Services and is generally simpler to configure. To  use  MADGECS  with 
CMDGODI.LAN  under  DOS,  MADGECS  must be loaded prior to loading any 
Client32 software (typically from  CONFIG.SYS  or  AUTOEXEC.BAT).  The 
"CLIENT_32" parameter must be specified, either on the MADGECS command 
line or in the MADGECS.CFG file. MADGECS must be told to automatically 
configure the IO, IRQ and MMIO memory window (if  required)  resources 
of  any  Madge  Smart PCMCIA adapters which are detected by specifying 
the "AUTOMATIC_CONFIGURATION" parameter. No separate  card  management 
utility is required. A sample MADGECS.CFG is given below:

; --- Sample MADGECS.CFG ---
EMULATE_SOCKET_SERVICES=YES           ; Use MADGECS Socket Services 
                                      ;  emulation.
CLIENT_32=YES                         ; Support Client32.
AUTOMATIC_CONFIGURATION=ONLY_ON_LOAD  ; Auto-configure Madge PCMCIA
                                      ;  adapters which are in the 
                                      ;  machine when MADGECS loads.
; --- End Of File ---

[Note  that  additional  parameters may be required to modify MADGECS' 
internal available IO, IRQ and memory resources list]

When  MADGECS  auto-configures  a  PCMCIA  adapter,   the   configured 
resources  are  displayed on the screen. If the PCMCIA adapter is MMIO 
capable and MADGECS was able to allocate a 4k MMIO memory  window  for 
the  adapter,  this memory range will be displayed. An example MADGECS 
auto-configuration message follows:

  "The Madge Smart 16/4 PCMCIA Ringnode at slot 1 has been configured
   to I/O location 0A20, interrupt 5, memory range CC00-CCFF"

To use this adapter in MMIO transfer mode it  would  be  necessary  to 
load  CMDGODI.LAN with "MEM=CC000" specified on the command line. Note 
that  CMDGODI requires the full 5-digit memory address (e.g. CC000) to 
be specified rather than the abbreviated 4-digit address (e.g. CC00).

See the documentation for MADGECS.EXE for more details.

(8.1.4) Using Memory Managers
-----------------------------
If you are using a memory manager such as EMM386, you must be  careful 
to  exclude the memory ranges which Card Services is configured to use 
to prevent conflict. For example, to prevent EMM386 from using the  4k 
memory  region  from CC000 to CCFFF, load EMM386 from CONFIG.SYS using 
"DEVICE=EMM386.EXE X=CC00-CCFF".

(8.1.5) Removing PCMCIA Ringnodes
---------------------------------
It is recommended that Madge PCMCIA adapters  are  not  removed  while 
CMDGODI.LAN  is loaded under DOS - any server connection will be lost, 
even if the adapter is re-inserted, this may also result in data loss.  
If a Madge PCMCIA adapter needs to be removed, logout of all  servers, 
unload  the  requester, unload the protocols and unload CMDGODI before 
removing the adapter.  The adapter may of course be re-inserted  at  a 
later  time and the driver and protocol software re-loaded to regain a 
network connection. If using MADGECS, the  "AUTOMATIC_CONFIGURATION  = 
ALWAYS"  parameter  must  be specified for Madge PCMCIA adapters to be 
auto-configured upon insertion ("AUTOMATIC_CONFIGURATION=ONLY_ON_LOAD" 
only configures adapters which are in the machine when MADGECS loads).


(8.2) PCMCIA Support (NetWare Server)
-------------------------------------

(8.2.1) Required Software
-------------------------
To use Madge Smart PCMCIA adapters  in  a  NetWare  Server,  Card  and 
Socket Services must be loaded under DOS and the card configured using 
a  configuration  utility BEFORE NetWare is loaded. MADGECS.EXE (v1.14 
or later) may be used. Refer to  the  instructions  for  using  PCMCIA 
adapters under DOS.

(8.2.2) Removing PCMCIA Ringnodes
---------------------------------
It  is  recommended  that  Madge PCMCIA adapters are not removed while 
CMDGODI.LAN is loaded - any client connections will be lost,  even  if 
the adapter is re-inserted, this may also result in data loss.


(8.3) PCMCIA Support (Windows 95)
---------------------------------

(8.3.1) Required Software
-------------------------
Under  Windows 95, Madge Smart PCMCIA adapters may be installed in the 
same way as other  adapters.  Card  and  Socket  Services  support  is 
integrated into Windows 95.

(8.3.2) Removing PCMCIA Ringnodes
---------------------------------
To remove a Madge Smart PCMCIA adapter during a Windows 95 session, it 
is  recommended  that  you  use  the  "PC Card (PCMCIA)" dialogue from 
Control Panel to first "Stop" the adapter. After this  has  been  done 
the   adapter   may  be  safely  removed.  If  the  adapter  is  later 
re-inserted, Windows 95 will re-load the driver  and  restore  network 
connections. 

It is possible to remove a PCMCIA adapter without first asking Windows 
95 to "Stop" the adapter, although this may result in data loss if the 
adapter  is  in  the  process of transferring data when it is removed. 
Windows 95 may also display a warning message.


(9) Using Computers with over 16Mb RAM
-------------------------------------

AT  bus  adapters use 24-bit addressing and are therefore only capable 
of DMAing to and from memory below 16Mb. If  your  computer  has  more 
than 16Mb of memory and you are using an AT bus adapter, whenever data 
must  be  transferred  to buffers above the 16Mb boundary, the data is 
copied  through  buffers  below  16Mb.   This  may  result  in  slight 
performance  degradation. EISA, Microchannel and PCI adapters (plus AT 
bus adapters in non-DMA mode)  don't  have  this  limitation  and  may 
transfer data directly to and from memory above 16Mb.

If  CMDGODI.LAN  detects an AT bus adapter in DMA mode in the computer 
it will default to using buffers  below  16Mb.  Note  that  this  will 
happen  even  if  this  AT  bus  adapter  is  not  going to be used by 
CMDGODI.LAN.


(10) Memory Usage
-----------------

It  may  be  desirable  to restrict CMDGODI.LAN memory usage on client 
workstations with limited  amounts  of  RAM.  By  default  the  driver 
assumes  it  is  running  on a NetWare Server and will allocate buffer 
memory accordingly. On  DOS  workstations  the  driver  plus  all  its 
allocated  memory  reside  in  extended  (XMS) memory. No conventional 
memory is used by the driver.

Extended  memory  usage  can  be reduced by specifying "OS=DOS" on the 
command line if the driver is used on a  DOS  workstation.  This  will 
force  the  driver  to  reduce  host  buffer memory allocation to that 
required by a client workstation. "OS=W95" is specified by default  on 
Windows 95 workstations.  Less  host  buffer memory is required if the 
adapter is using PIO or MMIO transfer mode rather than DMA.


(11) Adapter Mirroring Support
------------------------------

Adapter mirroring is only available on a NetWare server  and  requires 
the  Madge Mirror Support Module (MMIRROR.NLM) to be loaded. Mirroring 
provides protection against network hardware  problems  such  as  lobe 
cable failure. To use mirroring, a second adapter must be installed in 
the computer and attached to the same ring as the first.

When  mirroring is used, if a fault occurs associated with the primary 
adapter  (the  adapter   closes   for   example),   CMDGODI.LAN   will 
automatically switch to using the standby adapter. The primary adapter 
is  removed  from the ring. This switch is transparent to all attached 
clients.

To mirror an adapter, load the adapter in the usual  way  but  specify 
the  keyword  "MIRROR"  on the command line and also provide a locally 
administered node address override using the "NODE=" parameter. A node 
address override must be provided so that the standby adapter  can  be 
opened with the same node address as the primary. Failure to provide a 
node  address override will result in client workstations losing their 
server connection upon a mirror switch.

To register a standby adapter  as  a  mirror  of  the  already  loaded 
primary  adapter, simply load MMIRROR.NLM, specifying the board number 
of the primary adapter and the port or  slot  number  of  the  standby 
adapter.  Note that the standby adapter must not already be registered 
as a standby for another primary adapter.

The length of time certain  error  conditions  (single  station,  lobe 
cable  fault or beaconing) will be tolerated before a mirror switch is 
initiated can be set on the MMIRROR.NLM command line.

The following is an example of loading an adapter (at port  1000)  and 
associating  a mirror standby adapter (at port 2000) with it. A mirror 
switch will occur after 5 seconds of lobe cable failure.

  LOAD CMDGODI PORT=1000 MIRROR NODE=400013648912
  LOAD MMIRROR BOARD=1 MIRRORPORT=2000 LOBE=5

"LOAD CMDGODI DISPLAY" can be used at any time to see  which  adapters 
are  currently  in  use (primary adapters) and which are registered as 
mirror standbys. This information will change on a mirror switch - the 
primary becomes the standby and the standby becomes the primary.

The custom driver statistic "Mirror switch count" records  the  number 
of  times  a  successful  mirror  switch  has  taken  place.   See the 
"Statistics" section for more details.

See the documentation for MMIRROR.NLM for more details of mirroring.


(12) Statistics
---------------

HSM drivers maintain driver  statistics  which  can  be  viewed  using 
MONITOR.NLM on the NetWare server.

Some of the useful standard statistics include :

"No ECB available count" - This is a count of the number of times the 
                           HSM was unable to get a receive ECB. If no 
                           receive ECBs are held by the HSM then it is 
                           unable to receive any frames until an ECB 
                           becomes available. This counter may 
                           increase occasionally  under heavy receive 
                           load. If this counter shows a large  number 
                           of no ECB errors, try increasing the 
                           NetWare parameter values "MINIMUM  PACKET 
                           RECEIVE BUFFERS"  and  "MAXIMUM  PACKET 
                           RECEIVE BUFFERS".

"Send packet miscellaneous errors" 
                         - This is a count of the number of times the
                           HSM failed to transmit a frame. This 
                           counter may increase occasionally under
                           heavy transmit load. If this count shows
                           a large number of errors and you have
                           decreased the number of adapter transmit
                           slots using the command line parameter 
                           "TXSLOTS=", try increasing this number or
                           using the default. Also try increasing 
                           "BIGBUFFS=" if using DMA.

"Receive packet miscellaneous errors"
                         - This is a count of the number of bad
                           frames received not counted by other
                           statistics. This counter will increase
                           occasionally - bad packets are seen for a
                           variety of reasons, for example when a
                           transmitting station is powered off or
                           when abort frames are received. Bad
                           packets are not passed up to protocols and
                           therefore do not cause software problems.

In addition to the standard statistics, CMDGODI.LAN provides the 
following custom statistics :

"MAC frames received"    - This is a count of the number of MAC
                           frames received by the adapter. In normal
                           operation this counter rises steadily -
                           there will be a burst every 7 seconds due
                           to the Ring Poll procedure.

"Transmit restart count" - This is a count of the number of frames
                           aborted during transmission onto the ring.
                           If the percentage of transmitted frames
                           which are aborted is large, try increasing
                           the value of the TXSTART parameter. Note
                           that frames aborted during transmission
                           are re-sent by the adapter and are
                           therefore not lost.
                           Aborted frames on the ring will be counted
                           by the "Receive packet miscellaneous
                           errors" counter of receiving stations.

"Mirror switch count"    - This is a count of the number of times an
                           adapter has successfully switched to its
                           mirror standby adapter. It is only 
                           applicable if the adapter is being
                           mirrored.

(13) Lost Interrupt Alerts
--------------------------

On some NetWare Server  computers  it  has  been  observed  that  lost 
hardware  interrupt  alerts  are  displayed  when running CMDGODI.LAN. 
These alerts can be harmlessly disabled by adding the  following  line 
to your STARTUP.NCF file:

  SET DISPLAY LOST INTERRUPT ALERTS = OFF


(14) Using IBM LAN Client Software
----------------------------------

(14.1) Introduction
-------------------
IBM's  LAN  Client  software   is   based   upon   Novell's   Client32 
architecture. In addition to Novell's Client32 stack, IBM provide NLMs 
to  implement  the  IEEE 802.2 (LLC) protocol and NetBIOS. The IBM LAN 
Client software provides support for many protocols  and  applications 
in   addition  to  those  supported  by  the  Novell  Client32  stack, 
including:

- IEEE 802.2
- NetBIOS
- DOS LAN Services 4.x
- DOS LAN Requester 3.x
- PC3270 4.x

Since  IBM  LAN  Client  is based upon Novell Client32, it can provide 
significant conventional memory savings over existing  configurations, 
such as an NDIS-2 driver based configuration.

To   install   IBM  LAN  Client  on  a  client  workstation,  run  the 
installation utility which comes with  the  software  and  follow  the 
on-screen instructions.

For more information, refer to the appropriate IBM documentation.


(14.2) CMDGODI.LAN and IBM LAN Client
-------------------------------------
By  default,  the  LLC protocol provided with IBM LAN Client will only 
run over an  IBM  32-bit  ODI  driver.  To  use  CMDGODI.LAN  in  this 
environment,  the  N8022.IBM file in the IBM LAN Client directory must 
be replaced by the N8022.IBM file provided by Madge.

The load sequence (from the DOS command line or batch  file)  for  the 
IBM LAN Client 2.0 software is as follows:

NIOS                 ; Novell NIOS implementation
LOAD LSLC32          ; Novell Link Support Layer (LSL)
LOAD CMSM            ; Novell Media Support Module (MSM)
LOAD TOKENTSM        ; Novell Topology Support Module (TSM) for T-R.
LOAD CMDGODI OS=DOS  ; 32-bit ODI driver for Madge Smart Ringnodes
LOAD SROUTE          ; Novell source routing module (if required).
LOAD IPX             ; Novell IPX protocol implemention.
LOAD CLIENT32        ; Novell Client32 requester.
LOAD NLLC8022        ; IBM LLC protocol implementation.
LOAD CCB1API         ; IBM 16-bit CCB1 interface implementation.
LOAD NNETBIOS        ; IBM NetBIOS protocol implementation.
LOAD NCBRMAPI        ; IBM 16-bit NCB interface implementation.

Note  that  if  NetWare  connectivity is not required then the IPX and 
CLIENT32 NLMs need not be loaded.

Parameters for the NetWare Client32 requester (CLIENT32.NLM), the  IBM 
LLC  protocol  (NLLC8022.NLM), and the IBM NetBIOS protocol (NNETBIOS) 
are  entered  into  the  NET.CFG  file.  Note  that  any  ODI   driver 
(CMDGODI.LAN)  parameters  are  entered  on the "LOAD CMDGODI" command 
line.

It  is important that the "NET BIND ..." line is placed in the NET.CFG 
section for NLLC8022. For example:

;Example NET.CFG

NetWare DOS Requester
     FIRST NETWORK DRIVE=F
     AUTO RECONNECT LEVEL=1

protocol NLLC8022
     NET BIND TOKEN-RING CMDGODI 1


14.3) Using DOS LAN Services 4.x with IBM LAN Client
----------------------------------------------------
As an example of how the IBM LAN Client software may be used, consider 
the use of DOS LAN Services to connect to an IBM OS/2 LAN Server  4.x. 
The  following assumes that DOS LAN Services 4.x has been installed on 
the client workstation.

The  usual driver configuration when using an NDIS-2 driver, as loaded 
from CONFIG.SYS, is as follows:

rem Load Protocol Manager
device=c:\net\protman.dos /i:c:\net

rem Load Madge NDIS-2 Driver
device=c:\net\mdgnd.dos

rem Load DOS LAN Services Driver
device=c:\net\dlshelp.sys

If the IBM LAN Client software is used, Protocol Manager does not need 
to be loaded and neither does the NDIS-2 driver, since  a  32-bit  ODI 
driver  will  be  used  instead. The appropriate lines must be removed 
from CONFIG.SYS if  they  were  added  during  the  DOS  LAN  Services 
installation  process. The IBM LAN Client software is loaded using the 
load sequence detailed in Section 14.2.

To  start  DOS  LAN  Services  and setup network connections, type NET 
START at the DOS prompt as usual.

Since  the  drivers and protocols are loaded into extended memory when 
using the IBM LAN Client software, less conventional  memory  is  used 
than if an NDIS-2 driver / Protocol Manager configuration is used.


(15) Driver Parameters
----------------------

The following are driver parameters which  may  be  specified  on  the 
"LOAD  CMDGODI"  command  line  under  DOS/NetWare  server or from the 
"Network" dialogue box under Windows 95.   To  edit  parameters  under 
Windows  95,  highlight  the  Madge Ringnode in the "Network" dialogue 
box and click on the "Properties"  button.  To  edit  advanced  driver 
parameters use the "Advanced" dialogue box.


W95 parameter    : N/A
NW/DOS parameter : "PORT=<n>"
-----------------------------

If the computer contains  multiple  Madge  Smart  Ringnodes, use  this 
parameter to select the Ringnode to use by its IO port.If the computer 
contains  multiple  Madge  Smart  Ringnodes and this parameter (or the 
SLOT parameter) is not specified, the user will be prompted to enter a 
value.  Under Windows 95 the IO port of AT bus adapters  is  specified 
using the Network\Properties\Resources dialogue box.


W95 parameter    : "Adapter Slot Number"
NW/DOS parameter : "SLOT=<n>"
----------------------------------------

If  the  computer  contains multiple  Madge  Smart Ringnodes, use this 
parameter to select the Ringnode to use by its slot number.   This  is 
an  alternative  to  the  PORT  parameter  on buses which support slot 
numbering (e.g. Microchannel or EISA). PCI bus computers require a PCI 
BIOS  Specification  2.1  conforming  BIOS  to  support  physical slot 
numbering.


W95 parameter    : N/A
NW/DOS parameter : "MEM=<n>"
----------------------------

Use this to specify the base address of the memory  window  configured 
by  Card Services for a PCMCIA Ringnode in MMIO mode. The address is a 
5-digit hexadecimal value, for example "MEM=CC000" (some Card Services 
omit the least significant hex digit  which  is  always  zero).  Under 
Windows 95 this parameter is determined automatically.


W95 parameter    : "1. Frame Type" and "2. Frame Type"
NW/DOS parameter : "FRAME=<type>"
------------------------------------------------------

Use this to specify the frame type (TOKEN-RING or TOKEN-RING_SNAP).


W95 parameter    : "Node Address"
NW/DOS parameter : "NODE=<n>"
---------------------------------

Use  this  to specify a locally administered node address override for 
the adapter. A node  address  override  is  specified  as  a  12-digit 
hexadecimal  number  in  the range 400000000000 to 7FFFFFFFFFFF. If no 
override is supplied (the normal case), the adapter's unique burned-in 
address is used.


W95 parameter    : "OS"
NW/DOS parameter : "OS=<DOS|W95|SVR>"
-------------------------------------

Use this to specify the host operating system. This parameter is  used 
to  tune  driver  memory  usage.  If  a  client  operating  system  is 
specified, CMDGODI will allocate less memory for buffers, thus  saving 
memory.


W95 parameter    : "Transmit Start"
NW/DOS parameter : "TXSTART=<n>"
-----------------------------------

Use  this  to  specify  the  adapter  "transmit start" size. The value 
specified should be a small  integer  (typically  0-5),  lower  values 
being  used  for  high  performance adapters (e.g. PCI and EISA). This 
parameter can be used  to  tune  performance  -  the  internal  driver 
default for this parameter will in general give greatest performance.


W95 parameter    : "Transmit Slots"
NW/DOS parameter : "TXSLOTS=<n>"
-----------------------------------

Use this to specify the number of transmit resources.


W95 parameter    : "Receive Slots"
NW/DOS parameter : "RXSLOTS=<n>"
----------------------------------

Use this to specify the number of receive resources.


W95 parameter    : "Large Transmit Buffers"
NW/DOS parameter : "BIGBUFFS=<n>"
-------------------------------------------

Use this to specify the number of maximum frame size buffers allocated 
in  host  memory  for DMA transmits. Try increasing this value to stop 
the "Send packet miscellaneous errors" counter increasing.


W95 parameter    : "Adapter buffer size"
NW/DOS parameter : "BUFFSIZE=<n>"
----------------------------------------

Use this to specify the internal buffer size used on the adapter. This 
parameter can be used  to  tune  performance  -  the  internal  driver 
default for this parameter will in general give greatest performance.


W95 parameter    : "Small Buffer Threshold"
NW/DOS parameter : "THRESHOLD=<n>"
-------------------------------------------

Use  this  to specify the small buffer threshold size. This value must 
be less than the adapter buffer size. This parameter can  be  used  to 
tune performance - the internal driver default for this parameter will 
in general give greatest performance.


W95 parameter    : "Small Buffer Minimum"
NW/DOS parameter : "SMALLBUFFER=<n>"
-----------------------------------------

Use this to specify the small buffer minimum value. This value must be 
less  than  the  small buffer threshold. This parameter can be used to 
tune performance - the internal driver default for this parameter will 
in general give greatest performance.


W95 parameter    : "Copy all data on transmit"
NW/DOS parameter : "COPYALLDATA=<YES|NO>"
----------------------------------------------

Force the driver to copy all data from protocol  buffers  on  transmit 
when  using  DMA  (NO  is  the  default).  "COPYALLDATA=NO"  will give 
greatest performance in most environments.


W95 parameter    : "Transfer Mode Override"
NW/DOS parameter : "XFER=<PIO|PIO16|MMIO>"
-------------------------------------------

Override the default transfer mode (where possible). PIO16 will  force 
16-bit  PIO  (where  possible)  on  adapters which normally default to 
32-bit PIO.

Note that the transfer mode overrides which may be  used  depend  upon 
the  type  of  adapter.  Even  if  an  adapter supports the particular 
transfer mode specified, it  may  not  be  possible  to  override  the 
current  setting.  In  this  case  it is necessary to re-configure the 
adapter,  either  by  changing  switch  settings  or  by  running  the 
appropriate configuration utility, to change the transfer mode.

The  choice  of  transfer  mode  will  affect performance and host CPU 
utilisation.  In PIO and MMIO modes the host CPU is used  to  transfer 
data  between  adapter  and  host, performance being influenced by CPU 
speed. In bus-master DMA mode, the adapter itself  performs  the  data 
transfer  resulting  in lower CPU utilisation.  Bus-master DMA is well 
suited to server environments, especially where  the  server  contains 
multiple network cards, because of the low CPU overhead.


W95 parameter    : "Force Ringspeed"
NW/DOS parameter : "FORCESPEED=<4|16>"
--------------------------------------

Override the current card setting for ring speed (where possible).


W95 parameter    : Use Network\Properties\Resources dialogue box
                   and edit the "Interrupt (IRQ)" field.
NW/DOS parameter : "INT=<n>"
----------------------------

Override the current adapter  interrupt  number  setting  on  software 
configurable  AT  bus adapters. If you wish to use the current setting 
for  the  interrupt  number,  this  parameter  does  not  need  to  be 
specified. 

Windows 95  requires  that  this  field is always filled in for AT bus 
adapters. If you wish to use the current card setting ensure that  the 
value entered is correct.


W95 parameter    : Use Network\Properties\Resources dialogue box
                   and edit the "DMA channel" field.
NW/DOS parameter : "DMA=<n>"
----------------------------

Override   the   current  adapter  DMA  channel  setting  on  software 
configurable AT bus adapters. If you wish to use the  current  setting 
for the DMA channel, this parameter does not need to be specified.

Windows 95  requires  that  this  field is always filled in for AT bus 
adapters. If you wish to use the current card setting ensure that  the 
value  entered  is  correct.  If  the adapter is using a transfer mode 
other than DMA, set this field to zero.


W95 parameter    : "Ring Status Warnings"
NW/DOS parameter : "WARN=<YES|NO>"
-----------------------------------------

Use this to enable or disable abnormal ring status and adapter  closed 
/  re-opened  reporting.  If  reporting  is  enabled,  the driver will 
display messages  alerting  the  user  to  any  abnormal  ring  status 
condition  (single  station, ring beacon etc.) Such warnings are often 
desired when the driver is loaded on a NetWare server but may  not  be 
wanted  when  the  driver  is loaded on a client workstation. Critical 
condition messages (e.g. adapter check) can't be disabled. 


W95 parameter    : N/A
NW/DOS parameter : "DISPLAY"
----------------------------

Display details of adapters in the computer."LOAD CMDGODI DISPLAY" can 
be used before or after  CMDGODI.LAN  is  loaded  onto  any  adapters. 
Adapters  currently  in  use by CMDGODI.LAN and adapters registered as 
mirror standbys are indicated.


W95 parameter    : N/A
NW/DOS parameter : "HELP"
-------------------------

Display help screen.


W95 parameter    : N/A
NW/DOS parameter : "MIRROR"
---------------------------

This parameter must be specified if the  adapter  is  to  be  mirrored 
(that is, the adapter will have a standby adapter associated with it).  
Mirroring   is only available on the NetWare server and  requires  the  
Madge  Mirror  Support   Module   (MMIRROR.NLM)  to be loaded. If this 
parameter is not specified and MMIRROR.NLM is subsequently loaded, the 
adapter will not be recognised as a candidate for mirroring.


W95 parameter    : Adapter Watchdog Timeout
NW/DOS parameter : "WATCHDOG=<n>"
-------------------------------------------

Use this to specify the timeout period, in  seconds,  of  the  adapter 
watchdog   timer.  If  the  watchdog  timer  is  enabled,  CMDGODI.LAN 
periodically pokes the adapter so that the adapter code knows that the 
host driver is still alive. If the adapter isn't poked by  the  driver 
within the specified period of time, the adapter assumes that the host 
has  crashed  or  has  been reset and will halt with an adapter check, 
removing itself from the ring.

If  a computer is soft-reset in a conventional way (using CTRL-ALT-DEL 
under DOS, "Shutdown" under Windows 95 or "Down" under  NetWare)  then 
CMDGODI.LAN  will  reset  the  adapter  and  there  is no need for the 
adapter watchdog timer. If, however, a computer crashes or hangs  then 
the  adapter will probably not be reset by CMDGODI.LAN and the adapter 
will only be halted (and removed from the ring)  if  the  computer  is 
powered-down or if the adapter watchdog timer expires.

The  watchdog  timer can be disabled by specifying a timeout period of 
zero, this is the default. If used, a  timeout  period  of  around  15 
seconds is recommended.

Note that if the watchdog timer is used and interrupts are disabled on 
the  host computer for a period greater than the watchdog timeout then 
the watchdog timer will expire. This may happen on a NetWare server if 
the kernel debugger is entered for a sufficient length of time.


                   ------ End of CMDGODI.TXT ------