Madge Fastmac Plus NDIS MAC Drivers - Additional Information
============================================================
                                               LSS 5.0(0), August 1996
                                               -----------------------

Summary
-------

This document provides details of the  Madge  Fastmac  Plus  NDIS  MAC 
drivers,  MDGND.DOS  and  MDGND.OS2,  and  supplements the information 
provided in the LAN Support Software manual.  The topics covered are:

1) Upgrading from SMARTND to MDGND;

2) Configuring the driver;

3) Multiple adapter support;

4) Performance tuning MDGND;

5) Hot-swapping support with MDGND;

6) Advanced Power Management support with MDGND;

7) LAN Distance Connection Server support with MDGND.OS2;

8) MDGND configuration parameters;

9) Troubleshooting.



1) Updgrading from SMARTND to MDGND
-----------------------------------

The Madge Fastmac NDIS MAC drivers SMARTND.DOS  and  SMARTND.OS2  have 
been  fully  replaced  in  LSS  5.0(0)  by  the  Fastmac  Plus drivers 
MDGND.DOS and MDGND.OS2.  The new drivers give significant performance 
improvements over their predecessors, as well as  supporting  all  the 
functionality available in SMARTND.


1.1) New Features
-----------------

MDGND.OS2 v2.x has been available from LSS 4.2(0) onwards.  LSS 5.0(0)
contains MDGND.OS2 v3.x.   Features added to  the new version  of this
driver include:
    - support for OS/2 v1.x,  including support for IBM  OS/2 v1.3x EE
      through the Madge DLC driver MDGDLC.OS2;
    - support for OS/2 SMP;
    - support for Advanced Power Management;
    - support for hot-swapping of Smart 16/4 PCMCIA Ringnodes;
    - support for using shared interrupts;
    - improved performance for adapters using PIO;
    - support for the OS/2 Warp Resource Manager;
    - support for IBM LAN Distance Connection Server;
    - improved  support  for  displaying   information,  warning,  and
      error messages,  including  support  for these  messages  to  be
      logged with the IBM LAN Systems OS/2 Messaging service;
    - support for Banyan Vines OS/2 workstation;
    - support for reporting DMI statistics;
    - support for closing adapters when the OS/2 Presentation Manager
      shell is shut down.

MDGND.DOS v2.x has been available as a special release from LSS 4.3(0)
onwards.  LSS 5.0(0) contains  MDGND.DOS v3.x.  Features  added to the
new version of this driver include:
    - support for Advanced Power Management;
    - support for hot-swapping of Smart 16/4 PCMCIA Ringnodes;
    - support for using shared interrupts;
    - improved performance for adapters using PIO;
    - improved  support  for  displaying   information,  warning,  and
      error messages;
    - improved support  for remote  booting  from LAN  Server and  LAN
      Manager, with  more conventional  memory  being available  after
      RIPL.


1.2) Upgrading from SMARTND.DOS
-------------------------------

The  best  way  to upgrade from SMARTND.DOS to MDGND.DOS is to use the 
network configuration utility supplied with network software installed 
on the system.  The process will often involve selecting to remove the 
SMARTND.DOS driver, and then specifying that the new driver is  to  be 
installed  from  a  vendor-supplied  diskette or CD-ROM.  This process 
will copy across the new driver and alter  the  network  configuration 
accordingly.    It   will  also  often  copy  across  one  of  several 
driver-specific installation files  that  can  be  used  to  configure 
driver   parameters.    See   the  LAN  Support  Software  manual  for 
installation information specific to each particular environment.

A more simple approach to upgrading the DOS driver is described below. 
This process has the advantage of being quick and seamless,  but  will 
not  copy  across  any  special driver-specific installation file, and 
hence the network configuration utility will not  allow  the  user  to 
alter driver parameters subsequently.  This procedure will not work if 
SMARTND.DOS was installed with Windows for WorkGroups or Windows 95.

   a) Examine the CONFIG.SYS file  in the root of  the boot drive.  If
      this does  not  contain  lines  that  load  the  device  drivers
      PROTMAN.DOS and SMARTND.DOS then this procedure cannot be used.

   b) The  'DEVICE='  line  that  loads  PROTMAN.DOS  will  contain  a
      command-line switch of the  form '/I:xxx', where xxx  is a path-
      name.  This  is  the path  to  the  PROTOCOL.INI file  that  the
      Protocol Manager (PROTMAN.DOS) uses to configure the NDIS stack.
      Edit  PROTOCOL.INI,   replacing  all   instances  of   the  line
      'DriverName = smartnd$' with the line 'DriverName = mdgnd$'.

   c) Edit CONFIG.SYS, and  replace the  name SMARTND.DOS by  the name
      MDGND.DOS.  Copy the  files MDGND.DOS  and MDGND30.BIN  from the
      release disks / CD-ROM to the  location indicated as the path in
      the 'DEVICE=' line that now loads MDGND.DOS.


1.2) Upgrading from SMARTND.OS2
-------------------------------

Similarly, the best way to upgrade from SMARTND.OS2 to MDGND.OS2 is to 
use  the  network  configuration  utility  supplied  with  the network 
software installed on the system.  In the vast majority of cases, this 
will turn out to be IBM's LAPS / MPTS  utility.   Again,  the  process 
will  often  involve  selecting  to remove the SMARTND.OS2 driver, and 
then specifying that  the  new  driver  is  to  be  installed  from  a 
vendor-supplied diskette or CD-ROM.  This process will copy across the 
new  driver  and alter the network configuration accordingly.  It will 
also often copy across one  of  several  driver-specific  installation 
files  that  can  be used to configure driver parameters.  See the LAN 
Support Software manual for installation information specific to  each 
particular environment.

A  more  simple  approach  to  upgrading  the OS/2 driver is described 
below.  This process has the advantage of being  quick  and  seamless, 
but  will  not  copy  across  any special driver-specific installation 
file, and hence the network configuration utility will not  allow  the 
user to alter driver parameters subsequently.

   a) Examine the CONFIG.SYS file  in the root of  the boot drive.  If
      this does  not  contain  lines  that loads  the  device  drivers
      PROTMAN.OS2 and SMARTND.OS2 then this procedure cannot be used.

   b) The  'DEVICE='  line  that  loads  PROTMAN.OS2  will  contain  a
      command-line switch of the  form '/I:xxx', where xxx  is a path-
      name.  This  is  the path  to  the  PROTOCOL.INI file  that  the
      Protocol Manager (PROTMAN.OS2) uses to configure the NDIS stack.
      Edit  PROTOCOL.INI,   replacing  all   instances  of   the  line
      'DriverName = smartnd$' with the line 'DriverName = mdgnd$'.

   c) Edit CONFIG.SYS, and  replace the  name SMARTND.OS2 by  the name
      MDGND.OS2.  Copy  the MDGND.OS2  file from  the release  disks /
      CD-ROM to the  location indicated as  the path in  the 'DEVICE='
      line that now loads MDGND.OS2.



2) Configuring The Driver
-------------------------

2.1) How to Manually Alter the Driver Configuration
---------------------------------------------------

MDGND.DOS  and MDGND.OS2 are configured through the PROTOCOL.INI file. 
The location  of  this  file  can  generally  be  found  by  examining 
CONFIG.SYS:  the  '/I:'  argument  for  the  'DEVICE=' line that loads 
PROTMAN.OS2  or  PROTMAN.DOS  gives  the  path  to  PROTOCOL.INI.   If 
MDGND.DOS  is  being  used  with  Windows for WorkGroups, PROTOCOL.INI 
generally resides in the same directory as NET.EXE,  the  location  of 
which  can  be  found  by examining AUTOEXEC.BAT and searching for the 
line that runs the 'NET' command.  If MDGND.DOS  is  being  used  with 
Windows  95,  the  PROTOCOL.INI  file  can  generally  be found in the 
C:\WINDOWS directory.

PROTOCOL.INI is a text file.  It consists of  a  number  of  sections, 
each  of  which  pertains  to  a single instance of an NDIS driver.  A 
section consists of a bracketed module name, followed  by  a  list  of 
keywords  and  parameters  that  are specific to the module.  A sample 
section may be of the form

    [MDGND_nif]

       DriverName = MDGND$
       IOAddress = 0x0A20
       MaxFrameSize = 17846

For MDGND.DOS  and MDGND.OS2,  there is  one PROTOCOL.INI  section for
each  network  adapter  that  is  to  be  used.   These  sections  are
characterised by the line

       DriverName = MDGND$

This section  then describes  a  single network  adapter module.   The
protocol that binds to this module  can be determined by searching the
file for the section that contains the line

       Bindings = xyz

where xyz is the module name for the network adapter module.

Having located the appropriate section in PROTOCOL.INI that  describes 
the  module for a network adapter, optional parameters can be added to 
or removed from that section in order to alter the  configuration  for 
MDGND.DOS  or  MDGND.OS2 running on that adapter.  This editing can be 
done either manually with a text editor  or  through  a  special  NDIS 
configuration  utility.   Under  OS/2,  the  LAPS  or  MPTS utility is 
generally available,  allowing  the  user  to  edit  the  most  useful 
settings for the MDGND.OS2 driver.  Under DOS, the appropriate utility 
depends  on  the type of environment in which MDGND.DOS was installed: 
the LAN Support Program provides the DXMAID utility; DOS LAN  Services 
provides  the  INSTALL  utility;  Windows  for WorkGroups provides the 
Network Setup utility; and  Windows  95  provides  Network  Properties 
dialog.

Note  that  not  all  the  possible  driver  parameters can be changed 
through these special utilities.  The most effective way to change the 
configuration  for  MDGND.OS2  or  MDGND.DOS  is  to   manually   edit 
PROTOCOL.INI.


2.2) Types of Configuration Parameters
--------------------------------------

PROTOCOL.INI parameters are of the form

    Keyword[ = Value]

An example section for loading the MDGND.OS2 driver may be of the form

    [MDGND_nif]

       DriverName = MDGND$
       Slot = 2
       AutoOpen

MDGND.OS2 and MDGND.DOS parameters fall into three categories:

    i) 'PARM_STRING':   These parameters  take one  value.  The  value
                        takes the form of a  string, whose length must
                        lie  within  the  limits  specified  for  that
                        parameter.  If  the  first  character  of  the
                        string is  a digit,  then the  string must  be
                        enclosed in inverted comments.   An example of
                        a PARM_STRING parameter might be

                            NodeAddress = "400012345678"

   ii) 'PARM_WORD':     These parameters  take one  value.  The  value
                        takes  the  form  of  an  integer  which  lies
                        between the  two  limits  specified  for  that
                        parameter.  The  integer can  be expressed  in
                        decimal, or  in hexadecimal  by prefixing  the
                        value with  '0x'.  An  example of  a PARM_WORD
                        parameter might be

                            IOAddress = 0x0A20

  iii) 'PARM_BOOLEAN':  These parameters take zero  or one values.  If
                        a value is specified,  it takes the  form of a
                        boolean argument, and is expressed either as a
                        string ('Yes' or 'No'), or  as an integer ('1'
                        or  '0').   If  no  value  is  specified,  the
                        parameter  is  interpreted  as  being  set  to
                        'Yes'.  An example of a PARM_BOOLEAN might be

                            AutoOpen = Yes



3) Multiple Adapter Support
---------------------------

As  discussed  in  section  (2), MDGND.DOS or MDGND.OS2 can be used to 
drive multiple network adapters concurrently.   This  is  achieved  by 
having  one  PROTOCOL.INI  module  containing  the  line 'DriverName = 
MDGND$' for each installed adapter.  The  association  of  a  protocol 
with  an adapter is then achieved through the 'Bindings = xyz' line in 
the protocol's PROTOCOL.INI section, where 'xyz' is  the  name  of  an 
adapter module.

The  association  of  adapter  module  with  a  particular  adapter is 
achieved  through  the  use  of  three   special   MDGND   parameters: 
'IOAddress',  'Slot',  and  'BIA'.   Any  number of these three can be 
specified in a particular module, although if the values specified are 
not consistent an error will be reported.  These three parameters  are 
known as the three 'primary specifiers'.

The  'IOAddress' parameter can be used to specify which adapter to use 
by setting the argument to be the base IO address that the adapter  is 
configured  to use.  For example, if a Smart 16/4 AT Plus Ringnode has 
been configured to use an IO range with base address 0x3A20, then  the 
line

    IOAddress = 0x3A20

can be added  to the MDGND  PROTOCOL.INI module to  indicate that this
module is to use that adapter.

The 'Slot' parameter can  be used to  specify which adapter  to use by
setting the argument to  the number allocated to  the physical slot in
which the adapter  sits.  For  example, a  Smart 16/4  PCMCIA Ringnode
inserted in socket 1 would be  selected by a MDGND PROTOCOL.INI module
that included the line

    Slot = 1

The 'BIA' or 'BurntInAddress'  parameter can be used  to specify which
adapter to use by setting the argument  to the burnt-in address of the
adapter.  A Smart 16/4  ISA Client PnP Ringnode  with burnt-in address
0000F6382946 would be  selected by  a MDGND PROTOCOL.INI  module which
includes the line

    BIA = "0000F6382946"

Having tied  a  particular  module  to  a  specific  adapter,  further
parameters for that adapter can then be set.

Note that if none of  the above three parameters is  set in a multiple
adapter environment,  then  it is  undefined  as  to which  adapter  a
particular module will use.  The exception  to this is that MDGND will
always attempt to find Smart  16/4 PCMCIA Ringnodes after establishing
that there  are  no  other  adapters  that match  the  settings  in  a
particular MDGND  PROTOCOL.INI  module.  This  feature  is useful  for
Notebook machines  that  sometimes use  a  PC  Card, and  sometimes  a
permanent adapter in their docking station.



4) Performance Tuning MDGND
---------------------------

The default parameters  for MDGND.DOS  are set  to provide  low memory
usage.  To achieve higher  performance (at the cost  of consuming more
memory),  the  'MaxFrameSize'  parameter  should  be  increased.   For
example, the maximum  frame size can  be increased to  4484 bytes (the
maximum value for 4Mbps Token-Ring) by specifying

    MaxFrameSize = 4484

in the relevant MDGND module in PROTOCOL.INI.

Similarly, higher performance  with MDGND.OS2  on 16Mbps rings  may be
achieved  by  increasing   the  'MaxFrameSize'  parameter   to  17846.
However, the benefits of this increased  frame size cannot be utilised
unless the maximum frame  size on the machines  with which the adapter
is communicating is similarly set to a large value.



5) Hot-Swapping Support with MDGND
----------------------------------

5.1) Recommendations
--------------------

If the user is to hot-swap  Smart 16/4 PCMCIA Ringnodes, the following
are recommended.

    a) Some additional parameters may be  required in order to support
       hot-swapping.  The rest of  this section will  explain when and
       why they are required.

       The following is an example of a MDGND.DOS PROTOCOL.INI section
       that supports hot-swapping of Smart 16/4 PCMCIA Ringnodes:

               [MDGND_nif]
                  DriverName = mdgnd$
                  HotSwap = Yes
           (*)    AutoOpen = Yes
           (*)    RStatusReport = 0xF7FF
           (*)    NodeAddress = "400012345678"

       The following is an example of a MDGND.OS2 PROTOCOL.INI section
       that supports hot-swapping of Smart 16/4 PCMCIA Ringnodes:

               [MDGND_nif]
                  DriverName = mdgnd$
           (*)    AutoOpen = Yes
           (*)    RStatusReport = 0xF7FF
           (*)    NodeAddress = "400012345678"

       (*) indicates that these lines are not necessarily required for
       hot-swapping support: see below for details.

    b) Before ejecting an initialized card,  stop all network activity
       through  that   card,   by   shutting   down   open   networked
       applications, un-mapping networked drives, and logging off from
       servers.  Shut down  the network redirector  itself (e.g. using
       NET STOP), if this is possible.

    c) Only start  up the  network redirector  (e.g. using  NET START)
       once the network adapter  that is intended to  be used has been
       inserted.

    d) If MADGECS  is  being  used  to provide  the  card  and  socket
       services functions, upgrade  to the  version supplied  with LSS
       5.0(0).  Older  versions of  MADGECS.SYS (e.g.  v1.08 from  LSS
       4.3(2)) provide  sufficient support  for the  driver to  locate
       adapters that are  present when the  machine is booted,  but do
       not correctly  support  adapters  that  are  inserted  sometime
       later.

    e) If ODI2NDI.OS2 is being  used to provide an  ODI interface over
       MDGND.OS2 (for example, to  provide Netware Requester support),
       it is  recommended  that  the  'RStatusReport'  and  'AutoOpen'
       parameters appear in PROTOCOL.INI as  shown in (a) above.  This
       solves the problem  with ODI2NDI.OS2 where  the protocol causes
       the system to  TRAP D  when the cable  is detached  for several
       seconds.

Although steps (b) and (c) are recommended, it is possible in general 
to hot-swap adapters whilst currently using the network.  However:

    i) some frames may be lost during ejection, which may lead to some
       data  loss  if   the  protocol's  recovery   algorithm  is  not
       sufficently robust;

   ii) the network redirector  may report  network errors to  the user
       whilst the adapter is absent, which may include rather annoying
       beeps at regular intervals;

  iii) the network connections may no longer  be valid when an adapter
       is re-inserted.   This  is  not  so  much  of  a  problem  with
       SMB-based network connections  (such as  those provided  by IBM
       LAN Server and Microsoft LAN  Manager), since these connections
       will be re-established when the user attempts to use a resource
       from  the  respective   server;  but  with   NCP-based  network
       connections  (Novell  NetWare),  the  connection  will  timeout
       after a number of minutes, and it will be necessary to re-login
       to the server manually in order to use the server's resources.


5.2) Event Support Details
--------------------------

Both MDGND.DOS and  MDGND.OS2 support  the hot-swapping of  Smart 16/4
PCMCIA Ringnodes.  More specifically, they support:

    a) the  ejection  of  an  adapter   after  the  adapter  has  been
       initialized;

    b) the  insertion  of  an  adapter  after  an  adapter  which  had
       previously been initialized has been ejected;

    c) the insertion of  an adapter after  the driver has  been loaded
       and no adapter ejected.

The support  of  these  three  events  can  be  adjusted  through  the
'HotSwap' parameter.  By default, the value  for this parameter is set
to 'Yes' for MDGND.OS2, and to 'No' for MDGND.DOS.


5.2.1) Ejection Events
----------------------

When event  (a) occurs,  the response  of  the driver  depends on  the
setting of the 'HotSwap' parameter.  If the parameter is set to 'Yes',
the driver will act as  if the adapter is still  present but the cable
has been detached; it will inform  the bound protocol(s) of the change
in ring status, complete any outstanding transmits or requests with an
error code, and respond to any  further requests by reporting that the
adapter cannot open onto the ring.  The driver will also 'free-up' the
MDGND section in PROTOCOL.INI  that had been assigned  to the adapter.
If the parameter  is set  to 'No',  the driver  will still  report the
change in ring status as if the cable had been detached, but will also
report  that  a  fatal  error  has  occured  with  the  hardware;  the
protocol(s) will then make no further attempt to use that adapter.


5.2.2) Re-Insertion Events
--------------------------

Event (b) will be ignored by the  driver unless 'HotSwap' has been set
to 'Yes'.  If this  event is not  ignored, the driver  will attempt to
initialize the adapter in the same way as  it would had done if it had
found that adapter  when first  attempting to initialize  adapters for
each MDGND PROTOCOL.INI section (at init- or bind-time).  Hence, there
must be a MDGND section in  PROTOCOL.INI, not currently assigned to an
initialized adapter, that the driver can use for the new adapter; this
is obviously the case here,  since the definition of  case (b) is such
that event  (a) has  occured previously,  the  result of  which is  to
'free-up' a MDGND PROTOCOL.INI section.

Note that the same rules  apply when attempting to  match a free MDGND
PROTOCOL.INI section to the new  adapter: any 'IOAddress', 'Slot', and
'BurntInAddress'  parameters  must  all  match  the  settings  on  the
adapter.  In fact, the  driver goes through each  currently free MDGND
PROTOCOL.INI section,  attempting to  match each  in turn  to the  new
adapter until one  fits; if none  does, then the  adapter is unusable.
The potential  result  of this  process  is that  one  adapter can  be
ejected and  replaced by  another adapter  subsequently inserted  in a
different  slot,  if  the  MDGND   PROTOCOL.INI  section  is  not  too
restrictive on the settings of the three primary specifiers.

If the driver successfully  initializes the inserted  adapter, it will
no  longer  continue  to   fail  incoming  requests   from  the  bound
protocol(s).  If the 'AutoOpen' parameter has  been set to 'Yes', then
the driver will  open the  adapter immediately;  otherwise, it  is the
responsibilty of the protocol to attempt to re-open the adapter.  Once
the adapter is open,  the transmit and receive  processes can continue
as they were before the previous adapter was ejected.


5.2.3) Late-Insertion Events
----------------------------

Similarly to event (b), event (c) will be ignored by the driver unless
'HotSwap' has been  set to  'Yes'.  Event (c)  is subtly  different to
event (b): the  driver has to  be able to  cope with no  adapter being
present when first attempting to  match MDGND PROTOCOL.INI sections to
inserted adapters  at init-  or  bind-time, and  when  the adapter  is
inserted there must  still be a  free MDGND PROTOCOL.INI  section that
can be associated with that adapter.

The driver will deal with the first of these problems dependent on the
setting of the 'HotSwap'  parameter: if set to  'Yes', the driver will
set aside resources for  any MDGND PROTOCOL.INI sections  for which it
cannot find a  matching adapter,  successfully bind these  sections to
the  protocol(s),  and  then  attempt   to  associate  them  with  any
adapter inserted subsequently.   Before an adapter  is associated, the
driver  will  respond  to  any  requests  from  the  protocol(s)  with
indications to the  effect that the  adapter is currently  present but
unable to open onto  the ring.  If  the 'HotSwap' parameter  is set to
'No', then the  driver will  not reserve  any free  MDGND PROTOCOL.INI
sections  to  which  it  cannot  associate  an  adapter  at  init-  or
bind-time; instead, errors  are reported  for these sections,  and the
protocol binding is failed.


5.3) Increased Resident Driver Size
-----------------------------------

In order to support hot-swapping, the driver must retain more code and
data when remaining resident than is necessary when the feature is not
supported.  The  extra  code  and  data  is  necessary  to  initialize
adapters when they are inserted; normally this code and data is thrown
away  at  init-  or   bind-time  once  all  the   adapters  have  been
initialized.  A major part of the extra data is the Fastmac Plus image
that is downloaded to the adapter during adapter initialisation.

Under DOS, if the 'HotSwap' parameter is set to 'Yes', the driver will
attempt to copy the Fastmac Plus  image read from the MDGND30.BIN file
into extended memory, if such memory  is available.  It will first try
to allocate  memory  for  this  image  from  the  XMS  memory  manager
(HIMEM.SYS), if  it  is loaded.   If  this  procedure fails,  it  will
attempt  to  allocate  memory  for  itself  using  BIOS  INT15  system
services.  If  this second  process  fails, then  the  driver will  be
forced to  allocate conventional  memory for  the Fastmac  Plus image.
Even if  the  driver is  able  to use  extended  memory to  store  the
download  image,  the   size  of   the  driver  will   increase  quite
significantly when supporting hot-swapping, and  it is for this reason
that the default setting for MDGND.DOS is 'HotSwap = No'.


5.4) Protocol / MDGND Behavioural Requirements
----------------------------------------------

In order to support event (b) (described  above) in the case where the
same adapter is  re-inserted, a  bound protocol must  be able  to cope
with the cable being  detached and re-attached by  the user.  In order
to cope  with event  (b)  in the  case where  a  different adapter  is
inserted, or case  (c), the  protocol must also  be able  to determine
the burnt-in address of the adapter dynamically.  If a protocol cannot
support cable re-attachment,  then MDGND  can be configured  to handle
the re-opening of  the adapter; if  a protocol cannot  support dynamic
burnt-in address determination, then MDGND can be configured to always
export the same 'CurrentAddress' to the protocol.

In order to force MDGND to  handle cable re-attachment internally, the
following lines should be added  to the appropriate MDGND PROTOCOL.INI
section:

        AutoOpen = Yes
        RStatusReport = 0xF7FF

See section (9.5) for more information on re-opening an adapter.

MDGND can  be forced  to always  export the  same 'CurrentAddress'  by
using the 'BurntInAddress' and/or 'NodeAddress' parameters.  Specifying
the 'BurntInAddress' parameter  in a  MDGND PROTOCOL.INI  section will
force that section to only use one particular adapter.  If the adapter
was not present  at init-  or bind-time  (as with  event (c)),  and no
'NodeAddress' parameter specified, MDGND will  always export the value
specified  for  'BurntInAddress'  as  the  'CurrentAddress'.   If  the
'NodeAddress' paramter is present, the  value specified will always be
exported as the 'CurrentAddress', whether  or not the 'BurntInAddress'
parameter is present.

As an example, IBM's  latest OS/2 NETBIOS  stack is able  to cope with
cable re-attachment and dynamic burnt-in  address determination; so no
additional parameters  are  required for  hot-swapping  in this  case.
IBM's latest DOS NETBIOS stack, however, cannot cope with either cable
re-attachment or dynamic  burnt-in address determination;  so for hot-
swapping support with this protocol, the  following need adding to the
appropriate MDGND PROTOCOL.INI section:

        HotSwap = Yes
        AutoOpen = Yes
        RStatusReport = 0xF7FF
    (*) NodeAddress = ...
    (*) BurntInAddress = ...

where at least one of 'NodeAddress' or 'BurntInAddress' is required if
support for event (c), or  for event (b) with  a different adapter, is
required.


6) Advanced Power Management Support with MDGND
-----------------------------------------------

6.1) Recommendations
--------------------

If the user requires Advanced Power Management support with Smart 16/4
Ringnodes, the following are recommended.

    a) Some additional parameters may be  required in order to support
       APM.  The rest of  this section will explain  when and why they
       are required.

       The following is an example of a MDGND.DOS PROTOCOL.INI section
       that supports APM:

               [MDGND_nif]
                  DriverName = mdgnd$
                  APM = Yes
           (*)    AutoOpen = Yes
           (*)    RStatusReport = 0xF7FF
           (*)    NodeAddress = "400012345678"

       The following is an example of a MDGND.OS2 PROTOCOL.INI section
       that supports APM:

               [MDGND_nif]
                  DriverName = mdgnd$
           (*)    AutoOpen = Yes
           (*)    RStatusReport = 0xF7FF
           (*)    NodeAddress = "400012345678"

       (*) indicates that these lines are not necessarily required for
       APM support: see below for details.

    b) Before  electing  to  enter  suspend  mode,  stop  all  network
       activity  by   shutting  down   open  networked   applications,
       un-mapping networked  drives,  and  logging off  from  servers.
       Shut down the network redirector  itself (e.g. using NET STOP),
       if this is possible.

    c) If MADGECS.SYS  is  being  used  to  provide  card  and  socket
       services functions, upgrade  to the  version supplied  with LSS
       5.0(0).  Older  versions of  MADGECS.SYS (e.g.  v1.08 from  LSS
       4.3(2)) provide  sufficient support  for the  driver to  locate
       adapters that are  present when the  machine is booted,  but do
       not correctly locate adapters after a resume event has occured.

    d) If ODI2NDI.OS2 is being  used to provide an  ODI interface over
       MDGND.OS2 (for example, to  provide Netware Requester support),
       it is  recommended  that  the  'RStatusReport'  and  'AutoOpen'
       parameters appear in PROTOCOL.INI as  shown in (a) above.  This
       solves the problem  with ODI2NDI.OS2 where  the protocol causes
       the system to  TRAP D  when the cable  is detached  for several
       seconds.

    e) If IBM's PCMCIA.SYS is being used  to provide card services, it
       is recommended that  v1.33 or later  is used.  This  solves the
       problem with  PCMCIA.SYS  where  card services  will  hang  the
       system when a  suspend event is  processed for the  first time.
       See section (9.13) for further details.

Although step (b) is  recommended, it is possible  in general to enter
suspend mode whilst currently using the network.  However:

    i) the network connections may no longer  be valid when the resume
       event occurs.  This is not so  much of a problem with SMB-based
       network connections (such as  those provided by  IBM LAN Server
       and Microsoft  LAN Manager),  since these  connections will  be
       re-established when the  user attempts  to use a  resource from
       the respective server;  but with NCP-based  network connections
       (Novell NetWare), the connection  will time out  after a number
       of minutes, and it will be  necessary to re-login to the server
       manually in order to use the server's resources.


6.2) Event Support Details
--------------------------

MDGND supports Advanced Power  Management (APM) in similar  way to the
support it gives for  hot-swapping.  The main enhancement  is that APM
can be supported on all  types of adapter, not  just Smart 16/4 PCMCIA
Ringnodes.

Both MDGND.DOS  and  MDGND.OS2  support  APM  'Suspend'  and  'Resume'
events, subject to  the setting of  the 'APM' parameter.   By default,
this parameter  is  set  to  'Yes'  for MDGND.OS2,  and  to  'No'  for
MDGND.DOS.


6.2.1) Suspend Events
---------------------

When a suspend event occurs, the response of the driver depends on the
setting of the 'APM' parameter.  If the parameter is set to 'Yes', the
driver will shut down  the adapter (in  the case of  Smart 16/4 PCMCIA
Ringnodes, this  will result  in the  adapter being  powered-down); it
will inform the  bound protocol(s) that  the cable has  been detached,
complete any outstanding transmits or requests with an error code, and
respond to any further  requests by reporting that  the adapter cannot
re-open onto  the ring.   The  driver will  also  'free-up' the  MDGND
section in PROTOCOL.INI that had been assigned to the adapter.  If the
parameter is  set  to  'No',  the  driver will  still  shut  down  the
corresponding adapter and report  the change in ring  status as if the
cable had been detached; but  will also report that  a fatal error has
occured with  the hardware,  and  the protocol(s)  will  then make  no
further use of the adapter.

Once all the adapters that MDGND  had previously initialized have been
shut  down,  the  MDGND  reports  to   the  APM  driver  that  it  has
successfully handled  the  suspend  event,  and the  APM  driver  will
continue with  the  process  of  putting the  computer  hardware  into
Suspend Mode.


6.2.2) Resume Events
--------------------

When a resume event  occurs, the driver will  attempt to find adapters
for each MDGND PROTOCOL.INI  section that has 'APM'  set to 'Yes'.  It
will attempt to match adapters to these sections in the same way as it
would originally have done  at init- or  bind-time.  Matching adapters
are then  each  initialized,  and  incoming requests  from  the  bound
protocol(s) are  no longer  failed.  If  the 'AutoOpen'  parameter has
been set to 'Yes', then the  driver will open the adapter immediately;
otherwise, it  is the  responsibilty  of the  protocol  to attempt  to
re-open the  adapter.  Once  the  adapter is  open,  the transmit  and
receive processes can continue  as they were before  the suspend event
occured.


6.3) Increased Resident Driver Size
-----------------------------------

As with hot-swapping  support, the  driver must  retain more  code and
date when  remaining resident  in order  to support  APM.  Hence,  the
'APM' parameter defaults to 'No' under DOS.


6.4) Protocol / MDGND Behavioural Requirements
----------------------------------------------

In order to support  resume events, a  bound protocol must  be able to
cope with the cable being detached and  re-attached by the user.  If a
protocol  cannot  support  cable  re-attachment,  then  MDGND  can  be
configured to handle the re-opening of the adapter.

The  issue  of  handling  cable  re-attachment  is  the  same  as  for
hot-swapping, as discussed in section (5.4).



7) LAN Distance Connection Server Support with MDGND.OS2
--------------------------------------------------------

MDGND.OS2 from  LSS  5.0(0)  can  be  used  with  IBM's  LAN  Distance
Connection  Server.   The  following  procedure   should  be  used  to
install and configure the Connection  Server.  Use this information in
conjunction with that contained in  the 'LAN Distance Advanced Guide'.
(The information below was obtained when installing MDGND.OS2 with LAN
Distance  v5.0  from  OS/2  Warp  Server   v4.0  Advanced  -  but  the
procedure for installing with  other versions of LAN  Distance will be
mostly the same.)

    a) Install IBM  LAPS /  MPTS on  the  hard-disk, if  this has  not
       already been done.   Ensure that  the 'Madge Fastmac  Plus OS/2
       NDIS driver  for  Smart  16/4  Ringnodes' is  selected  as  the
       installed network adapter.

    b) Install the LAN  Distance Connection Server  onto the hard-disk
       and re-boot.  The 'IBM Remote Access' icon should appear on the
       OS/2 desktop.

    c) Edit the WCLLOCAL.INI file.   This will normally  be located in
       the C:\WAL  directory,  where  the  LAN  Distance  software  is
       installed.  Add  the following  line  to the  '[TOKENRINGMACS]'
       section:


          MDGND.NIF


       Create the following section at the end of the file:


       [MDGND.NIF]

          QSPNSY = "Yes"
          LoopBack = "No"
          CopyAllData = "Yes"


    d) Start the  'LAN  Distance product'  (double-click  on the  'IBM
       Remote Access' icon).   Configure the settings  as described in
       the 'LAN Distance  Advanced Guide'.   Note that  the 'Settings'
       notebook will now contain an entry  for the 'Madge Fastmac Plus
       OS/2 NDIS MAC driver for Smart  16/4 Ringnodes' in the 'Adapter
       for bridging'  list-box  under  the  'Address/LAN'  tab.   This
       entry should be  selected.  (Note that  the 'Settings' notebook
       may take a  few seconds  to update this  dialog, which  will be
       greyed-out while unavailable.)

    e) Finish configuring  the LAN  Distance product,  and re-boot  as
       directed.

The LAN  Distance Connection  Server should  now  be able  to use  the
MDGND.OS2 driver  to  connect  to  the LAN.   The  MDGND  PROTOCOL.INI
section should be of the form:

    [MDGND_nif]

       DriverName = MDGND$
       QSPNSY = "Yes"
       LoopBack = "No"
       CopyAllData = "Yes"

and the bridging  protocol that binds  to MDGND should  have a section
of the form:

    [SR_BRIDGE]

       DriverName = BRIDGE$
       BRIDGENUM = 1
       MAXFRAME = 2052
       Bindings = MDGND_nif, BRIDGEFH
       Ringnum = 0x1,0x2
       Maxhopcount = 3,3

Other MDGND.OS2 parameters can  still be added  to PROTOCOL.INI either
manually or through  the LAPS utility:  but it is  important to ensure
that the three parameters  listed above are always  present whilst the
LAN Distance Connection Server product is installed.

If further help  is required  with using  the LAN  Distance Connection
Server with MDGND.OS2, contact Madge Technical Support.



8) MDGND Configuration Parameters
---------------------------------

8.1) MDGND.OS2 Configuration Parameters Summary
-----------------------------------------------

 ----------------- -------------- ---------- -------- --------
| Name:           | Parm-Type:   | Default: |   Min: |   Max: |
 ----------------- -------------- ---------- -------- --------
| DriverName      | PARM_STRING  |   <none> |    <1> |    <9> |
| IOAddress       | PARM_WORD    |   <none> | 0x0000 | 0xFFFF |
| Slot            | PARM_WORD    |   <none> |      0 |    254 |
| BurntInAddress  | PARM_STRING  |   <none> |   <12> |   <12> |
| BIA             | PARM_STRING  |   <none> |   <12> |   <12> |
| MaxFrameSize    | PARM_WORD    |     4484 |     14 |  17846 |
| NodeAddress     | PARM_STRING  |   <none> |   <12> |   <12> |
| AutoOpen        | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| BusMaster       | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| MMIO            | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| PIO             | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| TransferType    | PARM_WORD    |   <none> |      0 |      2 |
| Alternate       | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| AltIO           | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| PIO2            | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| MMIO2           | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| InitOnLoad      | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| ODI2NDI         | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| CopyAllData     | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| Watchdog        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| WatchDogPeriod  | PARM_WORD    |        5 |      1 |     60 |
| IRQNumber       | PARM_WORD    |   <none> |      1 |     15 |
| DMAChannel      | PARM_WORD    |   <none> |      0 |     14 |
| SetIRQNumber    | PARM_WORD    |   <none> |      1 |     15 |
| SetDMAChannel   | PARM_WORD    |   <none> |      0 |     14 |
| Force16         | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| Force4          | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| APM             | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| HotSwap         | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| ForceAddress    | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| ReturnStatus    | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| NotPCI          | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| OpenOptions     | PARM_WORD    |        0 | 0x0000 | 0xFFFF |
| ForceOpen       | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| RStatusReport   | PARM_WORD    |   0xFFFF | 0x0000 | 0xFFFF |
| DTR             | PARM_BOOLEAN |   <none> |  FALSE |   TRUE |
| LoopBack        | PARM_BOOLEAN |   <none> |  FALSE |   TRUE |
| QSPNSY          | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| TXAlways        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| TXSlots         | PARM_WORD    |       16 |      2 |     32 |
| RXSlots         | PARM_WORD    |        4 |      2 |     16 |
| TXAhead         | PARM_WORD    |   <none> |      0 |     16 |
| MaxRequests     | PARM_WORD    |        6 |      0 |     10 |
 ----------------- -------------- ---------- -------- --------

Notes:   i) the 'Max' &  'Min' values for  PARM_STRING parameter types
            refer to the limits for the length of the string.

        ii) PARM_BOOLEAN values  are expressed  as 'TRUE'  or 'FALSE',
            but the parameter  argument must  be expressed as  'Yes' /
            '1' or 'No' / '0'.  If no argument is supplied, a value of
            TRUE is assumed.

       iii) if a  parameter  defaults  to '<none>',  then  the  driver
            will  select   the  most   appropriate   value  for   this
            parameter.


8.2) MDGND.DOS Configuration Parameters Summary
-----------------------------------------------

 ----------------- -------------- ---------- -------- --------
| Name:           | Parm-Type:   | Default: |   Min: |   Max: |
 ----------------- -------------- ---------- -------- --------
| DriverName      | PARM_STRING  |   <none> |    <1> |    <9> |
| IOAddress       | PARM_WORD    |   <none> | 0x0000 | 0xFFFF |
| Slot            | PARM_WORD    |   <none> |      0 |    254 |
| BurntInAddress  | PARM_STRING  |   <none> |   <12> |   <12> |
| BIA             | PARM_STRING  |   <none> |   <12> |   <12> |
| MaxFrameSize    | PARM_WORD    |     1550 |     14 |  17846 |
| NodeAddress     | PARM_STRING  |   <none> |   <12> |   <12> |
| AutoOpen        | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| BusMaster       | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| MMIO            | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| PIO             | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| TransferType    | PARM_WORD    |   <none> |      0 |      2 |
| Alternate       | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| AltIO           | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| PIO2            | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| MMIO2           | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| InitOnLoad      | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| CopyAllData     | PARM_BOOLEAN |   <none> |  FALSE |   TRUE |
| Watchdog        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| WatchDogPeriod  | PARM_WORD    |        5 |      0 |     60 |
| RemoteBoot      | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| IRQNumber       | PARM_WORD    |   <none> |      1 |     15 |
| DMAChannel      | PARM_WORD    |   <none> |      0 |     14 |
| SetIRQNumber    | PARM_WORD    |   <none> |      1 |     15 |
| SetDMAChannel   | PARM_WORD    |   <none> |      0 |     14 |
| Force16         | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| Force4          | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| APM             | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| HotSwap         | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| ForceAddress    | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| ReturnStatus    | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| NotPCI          | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| OpenOptions     | PARM_WORD    |        0 | 0x0000 | 0xFFFF |
| ForceOpen       | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| UseStacks       | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| RStatusReport   | PARM_WORD    |   0xFFFF | 0x0000 | 0xFFFF |
| LoopBack        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| FMPFile         | PARM_STRING  |   <none> |    <1> |  <128> |
| TXAlways        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| TXSlots         | PARM_WORD    |        8 |      4 |     32 |
| RXSlots         | PARM_WORD    |        4 |      4 |     16 |
| NumRXBuffers    | PARM_WORD    |        2 |      1 |      2 |
| TXAhead         | PARM_WORD    |   <none> |      0 |     16 |
| MaxRequests     | PARM_WORD    |        6 |      0 |    100 |
 ----------------- -------------- ---------- -------- --------

Notes:   i) the 'Max' &  'Min' values for  PARM_STRING parameter types
            refer to the limits for the length of the string.

        ii) PARM_BOOLEAN values  are expressed  as 'TRUE'  or 'FALSE',
            but the parameter  argument must  be expressed as  'Yes' /
            '1' or 'No' / '0'.  If no argument is supplied, a value of
            TRUE is assumed.

       iii) if a  parameter  defaults  to '<none>',  then  the  driver
            will  select   the  most   appropriate   value  for   this
            parameter.
            

8.3) MDGND Configuration Parameters in Detail
---------------------------------------------

DriverName:      <DOS & OS2>

                 This  parameter  is  required  in  every  section  in
                 PROTOCOL.INI.  For  those sections  belonging to  the
                 Madge Fastmac  Plus NDIS  driver, the  value must  be
                 'MDGND$'.   The   PROTOCOL.INI   file   may   contain
                 multiple sections with the

                     'DriverName = MDGND$'

                 entry,  in  which  case  each   section  is  used  to
                 configure a  separate  adapter.  The  association  of
                 any section with  one particular adapter  is achieved
                 through the  use  of  one  of  the  'IOAddress',  the
                 'Slot',   or    the   'BurntInAddress'    parameters,
                 which are described below.

                 Some older  PROTOCOL.INI  files  may use  a  slightly
                 different convention for  multiple sections  with one
                 individual driver: a  digit may be  placed before the
                 '$', so the entry may become

                     'DriverName = MDGND2$'.


IOAddress:       <DOS & OS2>

                 This parameter can be used  to specify the IO address
                 of the  adapter  that  this section  of  PROTOCOL.INI
                 should use.   For  example, if  an  adapter has  been
                 configured to use IO location 0x0A20, then the entry

                     'IOAddress = 0x0A20'

                 will  force  the   driver  to  use   that  particular
                 adapter.   This  will  also   associate  the  current
                 section in  PROTOCOL.INI with  that adapter,  and the
                 other parameters in  that section will  also refer to
                 the same adapter.

                 If no IO address  is specified, then  the driver will
                 use  the  first  available  adapter.   If  there  are
                 multiple  sections   in   PROTOCOL.INI,  then   those
                 sections containing an 'IOAddress'  parameter must be
                 placed before those sections without such an entry.


Slot:            <DOS & OS2>

                 This parameter  can  be  used  to  specify  the  Slot
                 number  for   the  adapter   that  this   section  of
                 PROTOCOL.INI  should   use.    This  parameter   only
                 affects Smart  16/4 EISA,  MC, MC32,  PCMCIA and  PCI
                 Ringnodes.

                 For example, if  an adapter  has been placed  in Slot
                 1, then the entry

                     'Slot = 1'

                 will  force  the   driver  to  use   that  particular
                 adapter.   This  will  also   associate  the  current
                 section in  PROTOCOL.INI with  that adapter,  and the
                 other parameters in  that section will  also refer to
                 the same adapter.

                 If no Slot number is  specified, then the driver will
                 use the  first  available  adapter.   If  there  are 
                 multiple  sections   in   PROTOCOL.INI,  then   those
                 sections containing a 'Slot' parameter must be placed
                 before those sections without such an entry.
                    

BurntInAddress:  <DOS & OS2>

                 This parameter can  be used  to specify  the Burnt-In
                 Address (Universally  Administered  Address)  of  the
                 adapter that  this  section  of  PROTOCOL.INI  should
                 use.

                 For example,  if  an  adapter has  been  manufactured
                 with a Burnt-In  Address of '0000F6123456',  then the
                 entry

                     'BurntInAddress = "0000F6123456"'

                 will  force  the   driver  to  use   that  particular
                 adapter.   This  will  also   associate  the  current
                 section in  PROTOCOL.INI with  that adapter,  and the
                 other parameters in  that section will  also refer to
                 the same adapter.

                 If no Burnt-In Address is  specified, then the driver
                 will use the first available  adapter.  If there are 
                 multiple  sections   in   PROTOCOL.INI,  then   those
                 sections containing a 'BurntInAddress' parameter must
                 be placed before those sections without such an
                 entry.
                    

BIA:             <DOS & OS2>

                 This parameter is equivalent  to the 'BurntInAddress'
                 parameter described above; for example:

                     'BIA = "0000F6123456"'.

                                    
MaxFrameSize:    <DOS & OS2>

                 This parameter can be used to specify the size of the
                 largest frame that  the adapter can  transmit onto or
                 receive from the network.

                 The  default  value  for  MDGND.DOS  is  1550  bytes.
                 Increasing this value  will improve  performance, but
                 will reduce available  DOS memory.  If  available DOS
                 memory is not restricted, then  a value of 4484 bytes
                 is recommended, viz:

                     'MaxFrameSize = 4484'.

                 The default value  for MDGND.OS2  is 4484  bytes.  If
                 the Ringnode  is being  used  on a  16Mbps ring,  and
                 the machine has plenty  of memory, this  value can be
                 increased to improve performance.

                 The maximum value on a 4Mbps ring is 4484 bytes.  The
                 maximum value on a 16Mbps ring is 17846 bytes.

                 If MDGND is  being used  with a 802.2  protocol stack
                 for Host connectivity, 'MaxFrameSize'  must be set to
                 a value at least as large  as the configured PIU size
                 plus the maximum size of  the Token-Ring header.  For
                 example, if  the  PIU  size  is set  to  1994  bytes,
                 'MaxFrameSize' should be set to at least 2042.

                 Note that most network  protocols need to  be able to
                 send and  receive  frames  larger  than  the  minimum
                 possible  value   for  MaxFrameSize.    Consequently,
                 although 14  is a  perfectly  valid frame  size on  a
                 Token-Ring  network,  setting  MaxFrameSize  to  this
                 value will probably  result in bound  protocols being
                 unable to communicate  across the network.   Hence, a
                 sensible minimum value  to use for  this parameter is
                 probably no less  than 256.   (Smaller values  may be
                 appropriate for special  frame-logging protocols that
                 only want to receive very small frames.)


NodeAddress:     <DOS & OS2>

                 This parameter  can  be  used to  specify  a  Locally
                 Administered Address  for  the adapter.   This  value
                 will override the  Burnt-In Address that  the adapter
                 would otherwise  use.  For  example,  if the  adapter
                 was required to use  the address '400012345678', then
                 the PROTOCOL.INI entry would read

                     'NodeAddress = "400012345678"'.

                 Note that,  if the  'AutoOpen' parameter  (see below)
                 is set to 'No',  then the Protocol  Module that binds
                 to the  Madge  driver may  attempt  to set  the  Node
                 Address itself.  If this  is the case,  then the Node
                 Address set by the Protocol will take precedence over
                 any 'NodeAddress' set in the  Madge driver section of
                 PROTOCOL.INI.

                 If no Node Address is  specified, the driver will use
                 the Ringnode's Burnt-In Address.

                            
AutoOpen:        <DOS & OS2>

                 Setting  this  parameter  to  'Yes'  will  force  the
                 adapter  to  open  automatically  onto  the  ring  at
                 bind-time.  The adapter  will then remain  open until
                 the PC  is  powered-off or  re-booted,  or until  the
                 Token-Ring cable  is  disconnected.   In  the  latter
                 case, the adapter  will automatically re-open  if the
                 cable is re-attached.

                 Setting this  parameter  to  'No'  allows  the  bound
                 protocol to control  the opening  and closing  of the
                 adapter.

                 It is  recommended  that  this parameter  be  set  to
                 'Yes'.  However, some  protocols require  the ability
                 to control the  opening and  closing of  the adapter,
                 and hence require this parameter to be set to 'No'.


BusMaster:       <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 attempt to use  the DMA  transfer method.  If  DMA is
                 not available, then  the driver will  use the default
                 transfer method  configured for  that adapter.   Note
                 that if an adapter has  been previously configured to
                 use PIO or MMIO (either  through hardware switches or
                 by using a software configuration utility), then this
                 parameter will not  be able  to force the  adapter to
                 use DMA.

                 Setting this  parameter to  'No' will  result in  the
                 adapter's default transfer  method being  used, which
                 may indeed be DMA.

                 It is  recommended  that  this parameter  is  set  to
                 'Yes',  since  DMA  is   the  generally  the  fastest
                 transfer method  for  this  driver.   If  performance
                 does appear  to  be slow,  especially  with a  memory
                 manager running (such as MS Windows 3.1), PIO or MMIO
                 may give better results.

                 This parameter can be overridden by the 'PIO2', 'PIO'
                 and 'MMIO' parameters.


MMIO:            <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 attempt to use the Memory  Mapped IO transfer method.
                 If MMIO is  not available,  then the driver  will use
                 the  default  transfer  method  configured  for  that
                 adapter.  Note that if an adapter has been previously
                 configured to use DMA or PIO (either through hardware
                 switches  or  by   using  a   software  configuration
                 utility), then  this parameter  will not  be able  to
                 force the adapter to use MMIO.

                 Setting this  parameter to  'No' will  result in  the
                 adapter's default transfer  method being  used, which
                 may indeed be MMIO.

                 This parameter  overrides the  'BusMaster' parameter,
                 and can in turn be overridden by the 'PIO2' and 'PIO'
                 parameters.


PIO:             <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 attempt to use the Programmed IO transfer method.  If
                 PIO is not  available, then  the driver will  use the
                 default transfer method for that adapter.

                 Setting this  parameter to  'No' will  result in  the
                 adapter's default transfer  method being  used, which
                 may indeed be PIO.

                 This parameter overrides  the 'BusMaster'  and 'MMIO'
                 parameters, and  can  in turn  be  overridden by  the
                 'PIO2' parameter.


PIO2:            <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 use an 'Alternative'  Programmed IO  transfer method.
                 If this method is not available, then the driver will
                 attempt to use  the PIO  transfer method.  If  PIO is
                 not available, then  the driver will  use the default
                 transfer method for that adapter.

                 Setting this  parameter to  'No' will  result in  the
                 adapter's default transfer method being used.

                 This parameter overrides the  'BusMaster', 'MMIO' and
                 'PIO' parameters.


TransferType:    <DOS & OS2>

                 This parameter can be used to force the transfer mode
                 for  the  adapter.    It  has  the   same  effect  as
                 specifying one of  the 'BusMaster', 'MMIO',  or 'PIO'
                 parameters.  It  is  provided  mainly  for  use  with
                 Windows 95, where it  can be set  through the Network
                 Properties /  Advanced  /  Property listbox,  and  is
                 compatible with the NDIS3 driver MDGMPORT.SYS.

                 A value of '0' is equivalent  to setting 'PIO = Yes',
                 a value of  '1' to setting  'BusMaster = Yes',  and a
                 value of '2'  to 'MMIO =  Yes'.  If no  value is set,
                 then the  driver  will use  the  values set  for  the
                 'BusMaster', 'MMIO' and 'PIO' parameters.


Alternate:       <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 use 'alternate'  bus  timings on  Smart  16/4 AT,  AT
                 Plus, AT PnP, ISA Client, ISA Client Plus, ISA Client
                 PnP and Smart 16 Ringnodes.

                 Setting this parameter to  'No' has no  effect on the
                 driver.

                 This parameter is  recommended on machines  where the
                 Madge Ringnode  Diagnostic  program (DIAG.EXE)  fails
                 in its  default  mode.   If  setting  this  parameter
                 still causes  the  driver to  fail,  the 'AltIO'  and
                 'PIO2' parameters should be tried.


AltIO:           <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 use slightly different  timings for its  IO cycles on
                 Smart 16/4 AT, AT  Plus, AT PnP, ISA  Client, and ISA
                 Client Plus Ringnodes.  This parameter should be used
                 in  conjunction  with   selecting  'Asynchronous  Bus
                 Timing'  when   configuring  the   adapter,  and   in
                 conjunction with selecting PIO as the transfer method,
                 either through a switch on the adapter or through the
                 'PIO' parameter (see above).

                 Setting this parameter to  'No' has no  effect on the
                 driver.

                 This parameter is  only required  for a  small number
                 of machines where  there is a  slight incompatibility
                 between the  speed of  the Host  Bus and  one of  the
                 adapters mentioned above.


MMIO2:           <DOS & OS2>

                 Setting this parameter to 'Yes' overcomes problems on
                 some machines where large bursts of MMIO over the PCI
                 bridge causes an  NMI to be  generated.  This setting
                 will force the driver to split up MMIO transfers into
                 smaller chunks,  and  consequently  could  marginally
                 impact performance.


InitOnLoad:      <DOS & OS2>

                 If this parameter is  set to 'Yes',  the Madge driver
                 will  initialize  the  hardware  at  init-time  (i.e.
                 while the  driver is  being  loaded from  CONFIG.SYS)
                 and not  at bind-time  (i.e. while  NETBIND is  being
                 executed).  This results in the driver taking up less
                 memory when remaining resident.

                 Setting this parameter  to 'No' causes  the driver to
                 initialize the hardware at bind-time.

                 It is  recommended  that  this parameter  is  set  to
                 'Yes', unless  the  hardware  must  not  be  accessed
                 until NETBIND is run.   The latter is  often the case
                 when remote booting; however,  under DOS, setting the
                 'RemoteBoot' parameter (see below)  will override the
                 'InitOnLoad' parameter.

                 If this parameter  is set  to 'Yes' for  any adapter,
                 then the  driver  will  initialize  all  adapters  at
                 init-time.

                 One advantage  of  setting  this parameter  to  'Yes'
                 when used with OS/2 is that  it will allow the driver
                 to discover  the  BIA of  the  adapter at  init-time.
                 This information  is  then available  to  ODI2NDI.OS2
                 when  it  loads;   if  the  information   isn't  made
                 available, then  it is  necessary to  set one  of the
                 following when using ODI2NDI.OS2:

                 (a) the NETADDRESS parameter for the ODI2NDI module;

                 (b) the NodeAddress parameter for the MDGND module;

                 (c) the BIA parameter for the MDGND module.

                 See section (9.6) for further information.


ODI2NDI:         <OS2 only>

                 This parameter  has exactly  the same  effect as  the
                 'InitOnLoad' parameter described above.


CopyAllData:     <DOS & OS2>

                 If this parameter  is set  to 'Yes', then  the driver
                 will copy  all frames  into a  special buffer  before
                 transmitting them.  If this parameter is set to 'No',
                 then no extra-copy  will be made,  and performance is
                 optimal.  Under  DOS, if  no  value is  set then  the
                 driver will select the best value.

                 The overhead of copying  the whole of  the frame into
                 a special buffer  before transmitting it  will have a
                 small  effect   on  performance.    However,  it   is
                 necessary under DOS when a memory manager is present.
                 If no value  is selected  under DOS, then  the driver
                 will select 'Yes' automatically if the adapter is set
                 to use DMA and either the driver detects the presence
                 of a memory manager  or the driver is  being run on a
                 machine that is being booted remotely.

                 Under DOS, the  driver can  also detect  when Windows
                 starts executing in 386  Enhanced mode.  This implies
                 that a memory manager is  now loading, and the driver
                 will start  to use  the extra-copy  approach for  any
                 adapter that  is currently  using DMA.   When Windows
                 is shut-down,  the driver  will return  to using  the
                 faster-transmit approach  for  those  same  adapters.
                 However, the driver cannot  detect any memory manager
                 (apart from MS Windows 386  Enhanced mode) that loads
                 after  the  adapter  has  been  initialized.   It  is
                 often the case  when remote  booting that  the memory
                 manager loads after NETBIND  has been run,  and it is
                 for this reason  that 'RemoteBoot  = Yes'  will force
                 'CopyAllData = Yes' on any adapter that is using DMA.

                 Under DOS, this parameter  need only be  set to 'Yes'
                 when an  undetected memory  manager  loads after  the
                 adapter has been  initialized, and is  running in DMA
                 mode.  The parameter can be set  to 'No' if it can be
                 guaranteed that  the memory  manager  will not  remap
                 any memory that the bound  protocol uses to hold data
                 for transmission.

                 Under OS/2,  there should  be no  need to  alter this
                 parameter to 'Yes'  in general: the  translation from
                 virtual to physical addresses is taken care of by the
                 driver.  However,  the  parameter  should be  set  to
                 'Yes' when  MDGND.OS2  is  used in  conjunction  with
                 IBM's LAN Distance Connection Server, as described in
                 section (9.3).


WatchDog:        <DOS & OS2>

                 If this parameter is  set to 'Yes',  the adapter will
                 shut-down  safely  if   the  computer  hangs   or  is
                 re-booted.

                 This is achieved  by activating a  timeout feature on
                 the  adapter.    The   driver   on  the   host   will
                 periodically update a timer on  the Ringnode.  If the
                 host hangs,  the  timer is  no  longer updated.   The
                 adapter's timer will then  timeout, and shut-down the
                 adapter safely.

                 Setting this  parameter  to  'No'  will  disable  the
                 timeout feature,  and  the  adapter  will  remain  in
                 operation until  the host  is  powered-off, or  until
                 the driver is re-loaded when the host is re-booted.

                 It is  recommended  that  this parameter  is  set  to
                 'Yes'.


WatchDogPeriod:  <DOS & OS2>

                 This parameter  can be  used to  specify the  timeout
                 period  to   be  used   for   the  watchdog   feature
                 (described above).   For  example, a  timeout  period
                 of 3 seconds can be configured with the entry

                     'WatchDogPeriod = 3'

                 Note that this parameter will  only have an effect if
                 'WatchDog' is set to 'Yes'.

                 The recommended value  for the 'WatchDogPeriod'  is 5
                 seconds.  This  value may  need to  be decreased  if,
                 for  example,  the  host  fails  to  re-boot  cleanly
                 (possibly reporting a error  during the Memory Test).
                 A value of 3 seconds may  be sufficient in this case.
                 The value  may  also need  to  be increased  if,  for
                 example, the driver  fails when the  host is entering
                 MS Windows.  A value of 10 seconds may then suffice.


RemoteBoot:      <DOS Only>

                 This parameter must be set to  'Yes' if the driver is
                 being remote-booted  from either  LAN  Server or  LAN
                 Manager.  The driver  will then  use the copy  of the
                 Fastmac Plus download image that  is cached in memory
                 rather than trying to read  it from the virtual disk.
                 It will also force all  adapters to be initialized at
                 bind-time, overriding any 'InitOnLoad = Yes' setting.

                 If the host is  not being booted  remotely, then this
                 parameter must be set to 'No', since the Fastmac Plus
                 will not reside in memory.

                 If this parameter  is set  to 'Yes' for  any adapter,
                 then the  driver  will  initialize  all  adapters  at
                 bind-time,  and   take   the   Fastmac   Plus   image  
                 directly  from memory.


IRQNumber:       <DOS & OS2>

                 This parameter  can be  used to  verify the  IRQ line
                 that the selected  adapter is configured  to use.  If
                 the parameter reads

                     'IRQNumber = 15'

                 the driver will  check that  the adapter  is actually
                 configured to use  IRQ 15.   If it  is not,  then the
                 driver will return an error.

                 If this parameter  is not  supplied, then  the driver
                 will not make any such check.


DMAChannel:      <DOS & OS2>

                 If this  parameter is  set  to a  non-zero value,  it
                 will  verify  the  DMA   channel  that  the  selected
                 adapter  is   configured  to   use  for   Bus  Master
                 transfers.  If the parameter reads

                     'DMAChannel = 5'

                 the driver will  check that  the adapter  is actually
                 configured to use DMA channel 5.   If it is not, then
                 the driver will return an error.

                 Specifying a zero value, 

                     'DMAChannel = 0',

                 has the  same effect  as specifying  'PIO =  Yes' for
                 this Ringnode.  See the 'PIO' parameter for details.

                 If this parameter  is not  supplied, then  the driver
                 will not make any checks on the DMA channel.


SetIRQNumber:    <DOS & OS2>

                 This parameter  can be  used  to force  the IRQ  line
                 that the  adapter  will  use to  signal  the  driver.
                 The IRQ  line can  only be  forced on  Smart 16/4  AT
                 Plus,  ISA   Client  Plus,   PCMCIA,  and   Smart  16
                 Ringnodes.   For  example,  to  select  IRQ  15,  the
                 parameter should read

                     'SetIRQNumber = 15'

                 If the selected IRQ  line cannot be forced  on one of
                 the above adapters,  then the  driver will  return an
                 error.   If  this  parameter   is  specified  for  an
                 adapter other  than those  listed  above, the  driver
                 will display a warning and ignore the parameter.

                 If the  parameter is  not supplied,  then the  driver
                 will use  the  IRQ  line  that  had  previously  been
                 configured for that adapter.


SetDMAChannel:   <DOS & OS2>

                 If this parameter is set to a non-zero value, it will 
                 force the  adapter to use that particular DMA channel 
                 for Bus Master transfers. The DMA channel can only be 
                 forced on Smart 16/4 AT Plus Ringnodes.  For example, 
                 to select DMA channel 5, the parameter should read

                     'SetDMAChannel = 5'

                 If the selected DMA  channel cannot be  forced on one
                 of the above  Ringnodes, then the  driver will return
                 an error.  If the adapter has  been forced to use the
                 PIO transfer method, a warning  will be displayed and
                 the parameter will  be ignored.  If  a non-zero value
                 is specified for  an adapter other  than those listed
                 above, a warning will be  displayed and the parameter
                 ignored.

                 Specifying a zero value, viz

                      'SetDMAChannel = 0',

                 has the  same effect  as specifying  'PIO =  Yes' for
                 this Ringnode.  See the 'PIO' parameter for details.

                 If the  parameter is  not supplied,  then the  driver
                 will use  the DMA  channel that  had previously  been
                 configured for that adapter.

                            
Force16:         <DOS & OS2>

                 If this parameter is set  to 'Yes', the Ringnode will
                 open onto the ring at 16Mbps.

                 If this parameter is  set to 'No',  the Ringnode will
                 open onto  the  ring  at  its  previously  configured
                 ringspeed.

                 This parameter  only  need be  used  to override  the
                 configured ringspeed of the Ringnode.


Force4:          <DOS & OS2>

                 This parameter  only  has any  effect  on Smart  16/4
                 AT Plus,  AT PnP,  ISA Client  Plus, ISA  Client PnP,
                 EISA, MC, MC32, PCMCIA and PCI Ringnodes.

                 If the parameter is  set to 'Yes',  the Ringnode will
                 open onto the ring at 4Mbps.

                 If the parameter  is set  to 'No', the  Ringnode will
                 open onto  the  ring  at  its  previously  configured
                 ringspeed.

                 This parameter  only  need be  used  to override  the
                 configured ringspeed of the Ringnode.


APM:             <DOS & OS2>

                 This parameter determines whether the driver supports
                 Advanced  Power  Management  for  this  module.   The
                 driver will  always  respond  to  suspend  events  by
                 shutting-down the  adapter;  however,  it  will  only
                 respond to  resume  events by  bringing  back up  the
                 adapter if the APM parameter is set to 'Yes'.

                 Note that settings this parameter  to 'Yes' under DOS
                 results in a much larger resident driver.


HotSwap:         <DOS & OS2>

                 This parameter  is  only  applicable  to  Smart  16/4
                 PCMCIA Ringnodes.  It  determines whether  the driver
                 should support  hot-swapping  for this  module.   The
                 driver will  always  respond  to ejection  events  by
                 releasing  resources  back   to  card   services  and
                 informing the bound protocol of  a change in hardware
                 status; however,  it will  only respond  to insertion
                 events by  re-starting  the  adapter if  the  HotSwap
                 parameter is set to 'Yes'.

                 Note that settings this parameter  to 'Yes' under DOS
                 results in  a  much  larger  portion  of  the  driver
                 remaining resident.


ForceAddress:    <DOS & OS2>

                 Setting  this  parameter  to  'Yes'  will  force  the
                 adapter's open  address  to  be  written  into  every
                 frame transmitted  by the  driver.   This copes  with
                 protocols  which  do  not   fully  follow  the  NDIS2
                 specification, in that they do not fill in this field
                 themselves.  Setting this value to  'Yes' will have a
                 small impact on performance,  and will cause problems
                 for those protocols  that attempt to  transmit frames
                 with source addresses  other than the  adapter's open
                 address.

                 Situations  where  this  parameter  is  known  to  be
                 required include  Banyan Vines  OS/2 workstation  and
                 LAN Manager v2.0 DOS workstation.  See section (9.8).


ReturnStatus:    <DOS & OS2>

                 Settings this  parameter  to  'Yes'  will  force  the
                 driver to return  to the  protocol the  'status' (the
                 FrameCopied  and  AddressRecognized   bits  from  the
                 FrameStatus byte at the end  of the Token-Ring frame)
                 of  all  frames   passed  for  transmission   by  the
                 protocol.  This  mechanism has  a detrimental  effect
                 on performance, but  is required by  a small minority
                 of  applications  in  order   for  them  to  function
                 correctly.  Examples  of  such  applications  include
                 Eicon Technology's Access  for OS/2 product  and HP's
                 OS/2 Jet Direct utility.  See section (9.7).
                 

NotPCI:          <DOS & OS2>

                 Setting this parameter to 'Yes' will force the driver
                 not to search for PCI  adapters in the machine.  This
                 is sometimes necessary for certain machines where the
                 BIOS doesn't properly support PCI.


OpenOptions:     <DOS & OS2>

                 This parameter  can be  used  to select  a number  of
                 features that the adapter  will exhibit while opening
                 onto and when open on  the ring.  The value specified
                 represents a bitmask of the features required.  Valid
                 fields are:

                     0x8000 - WRAP_INTERFACE
                                  This   opens    the    adapter    in
                                  'loopback mode':  the adapter  never
                                  asserts the phantom  drive, and only
                                  opens the  lobe  cable.   Hence,  no
                                  traffic is  generated  on the  ring.
                                  Do not use  this bit  in conjunction
                                  with FORCE_OPEN.

                     0x4000 - DISABLE_HARD_ERROR_RING_STATUS
                                  This disables those  interrupts from
                                  the adapter  that  indicate  a  Hard
                                  Error on the ring.

                     0x2000 - DISABLE_SOFT_ERROR_RING_STATUS
                                  This disables those  interrupts from
                                  the adapter  that  indicate  a  Soft
                                  Error on the ring.

                     0x1000 - PASS_ADAPTER_MAC_FRAMES
                                  If this bit is  set, all unsupported
                                  adapter MAC  frames  will be  passed
                                  to the  protocol as  normal received
                                  data; otherwise, they are purged and
                                  a negative response transmitted.

                     0x0800 - PASS_ATTENTION_MAC_FRAMES
                                  If this  bit is  set, all  attention
                                  MAC frames  will  be passed  to  the
                                  protocol as  normal  received  data,
                                  after  normal   processing  by   the
                                  adapter.

                     0x0400 - FORCE_OPEN
                                  This opens  the adapter  in loopback
                                  mode, and then  forcibly inserts the
                                  adapter onto  the  ring.  With  this
                                  bit set, the  Open command  can only
                                  fail if the adapter fails to open in
                                  loopback mode.   This option  should
                                  only be  used  in  conjunction  with
                                  a protocol  analyser, to  diagnose a
                                  beaconing ring.

                     0x0100 - CONTENDER
                                  Setting  this  bit  will  allow  the
                                  adapter to participate in the Active
                                  Monitor  Contention   process   when
                                  the process is  initiated by another
                                  adapter.  This bit has  no effect if
                                  the process  is  initiated  by  this
                                  adapter.

                     0x0080 - PASS_BEACON_MAC_FRAMES
                                  If this bit  is set, all  beacon MAC
                                  frames  will   be   passed  to   the
                                  protocol as  normal  received  data,
                                  after  normal   processing  by   the
                                  adapter.

                     0x0006 - COPY_ALL_FRAMES
                                  If these bits  are set, all  MAC and
                                  LLC  frames  on  the  ring  will  be
                                  passed to  the  protocol  as  normal
                                  received data.   This option  should
                                  only be used  in conjunction  with a
                                  protocol analyser.

                 For example,

                     'OpenOptions = 0x0006'

                 will  force  the  driver  to   attempt  to  open  the
                 adapter in COPY_ALL_FRAMES mode.

                 Note that  the COPY_ALL_FRAMES  bits will  be ignored
                 unless the  adapter  has previously  been  configured
                 as 'secure'.  See  section (9.9)  for details  of how
                 this can be achieved.

                 The OpenOptions  can  also  be set  by  the  protocol
                 bound to the driver.  The  protocol will also need to
                 set the correct PacketFilter in  order to receive all
                 LLC and MAC frames.   Protocol Analyser software will
                 normally  set   the   OpenOptions  and   PacketFilter
                 correctly by default.

                 It is normally  not necessary to  use the OpenOptions
                 parameter.  However, it will be necessary to make the
                 adapter  'secure'  in  order  for  Protocol  Analyser
                 software to function correctly.


ForceOpen:       <DOS & OS2>

                 Setting  this  parameter  to  'Yes'  will  force  the
                 FORCE_OPEN bit in  the OpenOptions (see  above) to be
                 set.  It will open the  adapter in loopback mode, and
                 then forcibly insert the adapter  onto the main ring.
                 It will only fail to open  the adapter if the adapter
                 failed to open in loopback mode.

                 Setting this parameter to  'No' has no  effect on the
                 driver.

                 This option should  only be used  in conjunction with
                 a protocol analyser to diagnose a beaconing ring.


UseStacks:       <DOS Only>

                 Setting  this  parameter  to  'Yes'  will  force  the
                 driver to  use the  DOS STACKS  Interrupt Handler  to
                 intercept  all  interrupts  from  the  adapter.   The
                 number and  size  of the  DOS  STACKS are  configured
                 through the 'Stacks = n, s' in CONFIG.SYS.

                 Setting this parameter to 'No'  will allow the driver
                 to  receive  the  adapter  interrupts  directly,  and
                 hence improve performance.

                 It is  recommended  that  this parameter  be  set  to
                 'No' by default.


RStatusReport:   <DOS & OS2>

                 This parameter  represents a  bitmask of  Ring Status
                 that will  be reported  to the  bound protocol.   The
                 valid bits are as follows:

                     0x8000 - Signal Loss
                     0x4000 - Hard Error
                     0x2000 - Soft Error
                     0x1000 - Transmit Beacon
                     0x0800 - Lobe Wire Fault
                     0x0400 - Auto-Removal Error 1
                     0x0100 - Remove Received
                     0x0080 - Counter Overflow
                     0x0040 - Single Station
                     0x0020 - Ring Recovery

                 So,

                     'RStatusReport = 0xFFFF'

                 will force  all ring  status  to be  reported to  the
                 bound  protocol.    This  is   the  default   option.
                 Setting the bitmask to '0x0000' will cause no status-
                 change events to be reported.


DTR:             <OS2 Only>

                 This parameter  can be  used to  force the  driver to
                 open the  associated adapter  in either  Classic mode
                 (if 'DTR = No' is set) or in DTR mode (if 'DTR = Yes'
                 is set).  If the parameter is not present, the driver
                 will open the  adapter in the  more appropriate mode.
                 If the  adapter  cannot be  opened  in the  requested
                 mode, an  error  will  be reported  and  the  adapter
                 cannot be used.

                 In general, there will never be  any need to set this
                 parameter: by default, the driver will always attempt
                 to open  in DTR  mode, and  only attempt  to open  in
                 Classic mode if DTR mode fails.  This is the required
                 behaviour  in  most  environments:   however,  it  is
                 conceivable that  the  user  may want  to  force  the
                 driver to  open  the  adapter in  Classic  mode  even
                 though DTR mode is available.

                 Note that only DTR  Fastmac Plus drivers  can open an
                 adapter in DTR mode.


LoopBack:        <DOS & OS2>

                 This parameter can be used to force the driver not to
                 'loop back' frames.   A frame is  described as having
                 been looped back  when it  is received by  a protocol
                 bound to the MAC driver  after having been previously
                 transmitted through that MAC by that same protocol.

                 By default, when  MDGND opens  an adapter  in Classic
                 mode the MAC driver will  loop back those frames that
                 are directed  at the  adapter's  open address,  group
                 address,  or   one   of  the   adapter's   functional
                 addresses; when open in  DTR mode, no  frames will be
                 looped back.  This  behaviour is appropriate  in most
                 environments, but  there  are  some (e.g.  IBM's  LAN
                 Distance Connection Server  - see section  (7)) where
                 the  protocol  must   not  receive  frames   that  it
                 previously transmitted.

                 To force frames not to  be looped back, set 'LoopBack
                 = No';  setting  'LoopBack  =  Yes'  will  force  the
                 protocol to believe that  all appropriate frames will
                 be looped  back (this  is  not correct  when open  in
                 DTR mode, and  hence the  protocol will  not function
                 correctly in  this case).   If the  parameter is  not
                 specified, the driver  will loop back  frames subject
                 to the default mechanism described above.


QSPNSY:          <OS2 Only>

                 This parameter  is  only  required when  opening  the
                 adapter for  use  in  IBM's LAN  Distance  Connection
                 Server (see section (7)).  All  frames will be copied
                 to the bound  protocol if 'QSPNSY  = Yes' is  set; if
                 the parameter is set to 'No', only frames directed at
                 the adapter's open address, its group address, or one
                 of its  functional addresses  will be  copied to  the
                 protocol.  The default for this parameter is 'No'.


FMPFile:         <DOS Only>

                 This parameter can be  used to specify  the full path
                 and filename  of the  Fastmac Plus  binary file.   If
                 the parameter reads

                     'FMPFile = C:\LSP\MDGND30.BIN'

                 then the driver would use the file as specified.

                 If this parameter  is not  supplied, the  driver will
                 assume that  the  file  is  named  'MDGND30.BIN'  and
                 resides in the same directory as the driver.


TXAlways:        <DOS & OS2>

                 Setting  this  parameter  to  'Yes'  will  force  the
                 driver  to  transmit   any  frame  passed   from  the
                 protocol, even  when  the  adapter  is  in  a  closed
                 state.    This   parameter   has   no   effect   when
                 'AutoOpen = Yes' is specified.

                 If this  parameter is  set to  'No', the  driver will
                 not transmit frames when  the adapter is  in a closed
                 state, and  will  instead  return  an  error  to  the
                 protocol.

                 The recommended setting  of this parameter  is 'Yes',
                 because it has  been found that  some older protocols
                 objected to  the driver  not always  transmitting the
                 frame.


TXSlots:         <DOS & OS2>

                 This parameter can  be used  to configure  the number
                 of Transmit Slots that  the driver will  use to queue
                 frames for  transmission  on  the  Host.   Increasing
                 this value will  allow more  frames to be  queued for
                 transmission, but  will also  increase the  amount of
                 DOS memory that the driver uses.  For example, to use
                 32 TX Slots, the parameter should read

                     'TXSlots = 32'.

                 The recommended  value of  16 (8  for DOS)  should be
                 sufficient for most environments.  If more DOS memory
                 is required, the  value can  be decreased down  to 4.
                 If the  protocol is  making  a very  large number  of
                 transmits, the value can be increased to 32.


RXSlots:         <DOS & OS2>

                 This parameter can  be used  to configure  the number
                 of Receive Slots  that the  driver will use  to queue
                 received frames  on  the  adapter.   Increasing  this
                 value will allow  more received frames  to be queued,
                 and possibly increase  performance under  heavy load;
                 however, it will  also consume more  DOS memory.  For
                 example, to use  16 RX  Slots,  the  parameter should
                 read

                     'RXSlots = 16'.

                 The recommended value  of 4 should  be sufficient for
                 most environments.  If DOS  memory is not restricted,
                 then increasing  the value  to  16 may  give a  small
                 performance improvement.


NumRXBuffers:    <DOS Only>

                 This parameter can  be used  to configure  the number
                 of Receive Buffers that the  driver will use to queue
                 received frames on  the Host.  Increasing  this value
                 will allow  more received  frames to  be queued,  and
                 probably increase performance; however,  it will also
                 consume more DOS  memory.  For  example, to use  2 RX
                 Buffers, the parameter should read

                     'NumRXBuffers = 2'.

                 The recommended  value  of  2  is  designed  to  give
                 optimal performance.  However, if  DOS memory savings
                 are required, the value should be decreased to 1.


TXAhead:         <DOS & OS2>

                 This parameter can  be used  to configure  the amount
                 of frame  data  that  is transfered  to  the  adapter
                 before the adapter begins to  transmit the frame onto
                 the ring.   If the  value is  small, there  is better
                 pipelining of data, and hence better performance.

                     'TXAhead = 0'

                 will force the driver to  transmit the minimum amount
                 of data to  the adapter  before the  transmission can
                 begin.

                 However, on computers  with slow buses,  if the value
                 is too small, the transmission  of the frame onto the
                 ring may  overtake  the transfer  of  data onto  the 
                 adapter.  In this situation, the  frame is aborted on
                 the ring, and re-transmitted  immediately.  This will
                 result in a large performance degredation.

                 If no  value  is specified  for  this parameter,  the
                 driver will assume a  value of 0 for  Smart 16/4 EISA
                 Ringnodes, 1  for Smart  16/4 MC32  Ringnodes, 5  for
                 Smart 16  Ringnodes, and  3 for  all other  adapters.
                 If many  abort  frames  are being  generated  by  the
                 adapter, try increasing this value.


MaxRequests:     <DOS & OS2>

                 This parameter can  be used to  configure the maximum
                 number  of  outstanding  General  Requests  that  the
                 driver can handle.  Increasing  this value will allow
                 the driver  to  queue more  requests  from the  bound
                 protocol(s), but will also  consume more memory.  For
                 example,

                     'MaxRequests = 6' 

                 will allow the driver  to queue upto  6 requests from
                 the protocol.

                 The recommended value  for this  parameter is  6.  It
                 should never be  necessary to alter  this value under
                 normal conditions.  Note that the  driver will not be
                 able to carry out most General Requests if this value
                 is set  to  0;  hence  a sensible  minimum  for  this
                 parameter in real working environments is 1.



9) Troubleshooting
------------------

9.1) Diagnosing Errors
----------------------

One new enhancement to  MDGND.DOS and MDGND.OS2 in  version 3.x is the
display and  logging of  driver messages.   There are  three types  of
messages:  information,  warning  and   error.   Information  messages
examples include  the  driver's  sign-on  banner and  details  of  the
adapters in use.  Warning messages are  used for non-fatal errors that
the driver can work around.  Error  messages are used for fatal errors
resulting  either  from   an  unusable   adapter  or  from   a  driver
initialisation problem.  A list  of MDGND error messages  can be found
in ERRORS.TXT.


9.1.1) Displaying Errors on Screen
----------------------------------

The driver can only display messages on  the screen when the driver is
originally loaded.  If the 'InitOnLoad' parameter is set to 'Yes', the
driver can display any  errors found while  initializing the adapters;
otherwise, these errors are  only found at bind-time,  when the driver
no longer has  the ability to  write to  the screen.  Hence,  if there
appears  to  be   a  problem   with  the   MDGND  driver,   the  first
recommendation is to set  'InitOnLoad = Yes', and  examine the errors.
Most of the errors can be  fixed by altering the system configuration.
Others may require the assistance of Madge Technical Support.

Another use for 'InitOnLoad = Yes' is to display the configuration for
each adapter in  use by MDGND.   This information can  prove useful in
debugging errors  such as  ringspeed mismatch,  and for  ensuring that
there are no hardware conflicts with other devices.

Another common problem during  the system boot is  that the adapter is
unable to open onto the ring.  In  general, the open request is issued
by the protocol  in its own  time, and we  do not have  control of the
screen in order  to display errors.   One solution  to this is  to set
'AutoOpen = Yes' as well as 'InitOnLoad = Yes' for each adapter.  This
will force the driver to initialize and open each adapter whilst still
in control of the screen, and hence any open errors can be displayed.

Note that  setting 'InitOnLoad  = Yes'  and  'AutoOpen =  Yes' is  not
always appropriate: some  environments require  the adapter to  not be
initialized until bind-time,  and some  protocols require  the ability
to control when the adapter is  open.  Hence, setting these parameters
can be considered as  a temporary arrangement in  order to investigate
a potential MDGND problem.

If the driver  fails to find  an appropriate adapter  for a particular
MDGND PROTOCOL.INI, and  'HotSwap' is  set to  'Yes', the  driver will
still register that module  with the Protocol  Manager in anticipation
of a Smart 16/4 PCMCIA Ringnode  being inserted later.  This behaviour
will obviously mask  real errors  with failing  to find  adapters that
should be present.  Hence, it may be appropriate to set 'HotSwap = No'
(especially with MDGND.OS2 where  this is not the  default setting) in
all MDGND PROTOCOL.INI sections when investigating problems related to
locating adapters.


9.1.2) Logging Errors in LANTRAN.LOG
------------------------------------

In addition to the above, IBM's  OS/2 LAN Adapter and Protocol Support
(LAPS) provides the IBM LAN Systems OS/2 Messaging service.  MDGND.OS2
uses this service to log  messages in the LAN  message log file, which
is generally  the  file  C:\IBMCOM\LANTRAN.LOG.  The  messages  to  be
logged  are  held  in  MDGND.OS2's  message  file  MND.MSG,  which  is
generally located in  the C:\IBMCOM  directory whereas the  driver and
NIF files are generally located in the C:\IBMCOM\MACS directory.

The messages logged in  LANTRAN.LOG are designed to  mirror those that
would appear on the screen if  the driver had control.  Hence, adapter
details / errors  can be  viewed without having  to set  'InitOnLoad =
Yes' in this case.   Additionally, messages about  errors when opening
adapters can be logged  (taking away the need  for setting 'AutoOpen =
Yes' to see these errors), as  well as messages regarding hot-swapping
events and adapter re-initialisations.

Fatal errors  that occur  after the  driver has  initially loaded  are
logged with the  OS/2 Messaging service  in such  a way that  they are
displayed in a  special full-screen  text box,  requiring the  user to
press a key before  continuing.  However, the screen  display of these
messages can 'get lost' if the user  is required to press a key during
the processing of CONFIG.SYS, so it is best not to rely too heavily on
all errors appearing in this way.

It is possible  for the  versions of MDGND.OS2  and MND.MSG  to become
out-of-step.  MND.MSG  does provide  a  small amount  of forward-  and
backward- compatiblity, but  it is  always advisable for  the versions
of the two files to  be matched.  This compatibilty  can be checked by
running the Madge  utility MVER.EXE  on each  file: both  files should
give the same string for the 'Product ID' field.  Note that the driver
will display a warning  at init-time if (a)  it cannot locate MND.MSG,
(b) the located MND.MSG file is too old,  or (c) if it is too new.  In
each of  these  cases,  the  driver  will  not  log  any  messages  to
LANTRAN.LOG.


9.2) Upgrading MND.MSG
----------------------

As described in section (9.1.2), the version of MND.MSG should reflect
the version of MDGND.OS2 in use.   This mismatch of versions can occur
during MDGND upgrades.

If a previous version of MDGND.OS2 is using an associated MND.MSG file
at the time of the upgrade, then  it will not be possible to overwrite
the MND.MSG file with a newer version because the message file will be
locked  open  by  LANMSGEX.EXE  (the   ring-3  LAN  Systems  messaging
process).  If the upgrade is made  through the 'Install' button on the
front panel of the MPTS tool (or the LAPS tool with older OS/2 network
applications),  OS/2 will  use its locked  file device driver  to copy
across the new version of MND.MSG at the next boot.

If the upgrade is done through the 'Other adapters' button on the LAPS
panel inside  MPTS, through  the OS/2  DDINSTAL program,  or by  hand,
MND.MSG will  not  be updated.   Indeed,  using the  'Other  adapters'
button will  lead to  LAPS displaying  an error  dialog regarding  the
unsuccessful attempt to copy over MND.MSG, and the only way of exiting
this dialog without crashing LAPS is to use the 'Retry' button.

Use the following  steps to  manually upgrade a  MND.MSG file  that is
locked open.

    a) Check  to  see  whether  the  IBM  locked  file  device  driver
       (IBMLANLK.SYS) is  installed -  it is  normally located  in the
       C:\OS2\INSTALL directory.  If  this file  does not  exist, then
       this process for upgrading MND.MSG cannot be used.

    b) Check to see whether  the list file for  the locked file device
       driver (IBMLANLK.LST) currently exists -  it will be located in
       the same directory  as the  device driver IBMLANLK.SYS.   If it
       does exist, go to step (f).

    c) Create a  file  named IBMLANLK.LST  in  the same  directory  as
       IBMLANLK.SYS.  The new file should contain the single line

       MOVE C:\IBMCOM\MND.~SG C:\IBMCOM\MND.MSG

       where 'C:\IBMCOM' should be replaced by the path to the current
       MND.MSG file.

       IMPORTANT: Make sure that the  newly-created file is terminated
       with an end-of-file character.  This can be achieved by editing
       the file with E.EXE, but not  with TEDIT.EXE.  Failure to do so
       will lead to  the IBMLANLK.SYS  device driver crashing  OS/2 on
       the next re-boot.

    d) Add the following  line to  CONFIG.SYS, placing  it immediately
       after  the  line  that  loads  the  \IBMCOM\PROTOCOL\LANVDD.OS2
       device driver:

       DEVICE=C:\OS2\INSTALL\IBMLANLK.SYS C:\OS2\INSTALL\IBMLANLK.LST

       where 'C:\OS2\INSTALL' is the path to the IBMLANLK.SYS driver.

    e) Add the following  line to  CONFIG.SYS, placing  it immediately
       before the first 'RUN=' or 'CALL=' line:

       RUN=C:\OS2\INSTALL\IBMLANLK.EXE C:\OS2\INSTALL\IBMLANLK.LST

       where 'C:\OS2\INSTALL' is the path  to the IBMLANLK.SYS driver.
       Go to step (g).

    f) Add the single line

       MOVE C:\IBMCOM\MND.~SG C:\IBMCOM\MND.MSG

       to the end of  the IBMLANLK.LST file,  where 'C:\IBMCOM' should
       be replaced by the path to the current MND.MSG file.

       IMPORTANT: Make sure  that the new  file is terminated  with an
       end-of-file character.   This can  be achieved  by editing  the
       file with E.EXE, but not with TEDIT.EXE.  Failure to do so will
       lead to  the IBMLANLK.SYS  device driver  crashing OS/2  on the
       next re-boot.

    g) Copy the new MND.MSG as MND.~SG  into the same directory as the
       old MND.MSG (probably C:\IBMCOM).

    h) Re-start OS/2.  MND.MSG should now be upgraded.


9.3) Poor Performance with LAN Distance Connection Server
---------------------------------------------------------

A problem  has been  found with  the  bridging protocol  bound to  the
MDGND.OS2 driver in  a LAN  Distance Connection Server.   The symptons
of the problem are very slow performance when copying large files from
the LAN to the server or to a remotely-attached workstation.

The problem is  to do with  the bridging  protocol running out  of LAN
transmit resources whilst receiving  a large burst of  frames from the
LAN.  When these resources  are freed, the  bridging protocol neglects
to transmit the frames that couldn't be transmitted earlier, and these
frames become 'lost'.  The protocol is  able to recover the connection
after several seconds, but the same problem occurs as soon as the next
burst of frames arrives at the Connection Server.

This problem may be  fixed in a  future release of  IBM's LAN Distance
product.   In  the  meantime,  the  best  workaround  is  to  set  the
'CopyAllData' parameter to  'Yes' in  the MDGND  PROTOCOL.INI section.
This has the  effect of  MDGND completing  all transmit  requests for 
small frames synchronously, and hence  most of the bridging protocol's
transmit resources are able to be re-used immediately.

The 'CopyAllData = Yes' setting is added to PROTOCOL.INI by default if
the LAN Distance  installation procedure  described in section  (7) is
followed.


9.4) Using MDGND.DOS with Host Connectivity Products
----------------------------------------------------

The following information  takes the  example of using  MDGND.DOS with
IBM's Personal Communications /  3270 product, but  the information is
relevant to using the driver with most Host connectivity products.

IBM's PC/3270  requires a  DLC interface  in  order to  use the  802.2
protocol to  communicate with  the Host  over the  Token-Ring network.
This can be  provide by using  a DLC  NDIS protocol stack  (e.g. IBM's
DXME0MOD.SYS driver) running over  MDGND.DOS.  There are  a few points
to bear in mind when setting up such an environment.

    a) The adapter  may  need to  use  a locally-administered  address
       when open onto  the network.   This can  be achieved  either by
       using the  MDGND  'NodeAddress' parameter,  or  by forcing  the
       802.2 protocol stack  to set  the address.   The latter  can be
       achieved with DXME0MOD.SYS by loading  the driver in CONFIG.SYS
       with a line such as

           DEVICE=C:\LSP\DXME0MOD.SYS 400012345678

       If the 802.2 protocol stack is being  used to set the LAA, then
       it must be  that protocol that  first opens the  adapter.  Thus
       the MDGND parameter  'AutoOpen' must not  be set to  'Yes', and
       no other  protocol bound  to  MDGND must  attempt  to open  the
       adapter.  An example  of where  this may be  a problem  is when
       using DXME0MOD.SYS with  IBM's DXMJ0MOD.SYS driver,  to provide
       both an  802.2 and  NETBEUI interface  over NDIS:  DXMJ0MOD.SYS
       will automatically open  the adapter  when NETBIND.EXE  is run,
       and will not use  the address specified  for DXME0MOD.SYS.  The
       solution to this  is to  use DXMT0MOD.SYS (NETBEUI  over 802.2)
       instead of DXMJ0MOD.SYS, and ensure  that DXMT0MOD.SYS does not
       open the adapter by using a line in CONFIG.SYS such as

           DEVICE=C:\LSP\DXMT0MOD.SYS O=N

       It  would  also  be  necessary   to  ensure  that  the  PC/3270
       application was started before any attempt  was made to use the
       NETBEUI interface (e.g. before NET START was run).

    b) The MDGND  'MaxFrameSize'  parameter must  be  set to  a  value
       greater than  the  sum  of  the configured  PIU  size  and  the
       maximum length of the Token-Ring  frame header (48 bytes).  For
       example, if the  PIU size  is set  to 1994,  the 'MaxFrameSize'
       parameter should be set to at least 2042.

    c) If the 'MaxFrameSize' parameter is  set to a particularly large
       value, it  may be  necessary to  increase the  amount of  'work
       space' available to the 802.2  protocol stack.  For example, if
       the MDGND driver is being used with the IBM LAN Support Program
       and is configured with  'MaxFrameSize = 2560',  the 802.2 stack
       should be loaded with a line such as

           DEVICE=C:\LSP\DXME0MOD.SYS 400012345678,16

       so that the amount  of work space available  to DXME0MOD.SYS is
       increased from the default 8KB to 16KB.


9.5) Re-opening Adapter after Cable Disconnection
-------------------------------------------------

If the  cable is  detached from  a Smart  16/4 Ringnode  running MDGND
after the adapter has  opened onto the ring,  and then re-attached, it
does not necessarily  follow that  the adapter  will re-open  onto the
ring.  This 're-open' feature depends on  the length of time for which
the cable  was detached,  the  setting of  MDGND  parameters, and  the
particular protocol bound to MDGND.

By default, it is  the responsibilty of the  bound protocol to recover
from a cable disconnection.  If the  cable is is only disconnected for
a few  seconds, the  Fastmac Plus  code  running on  the adapter  will
handle the re-opening  of the adapter.   If the cable  is detached for
more than 5 - 10 seconds, the  adapter will inform the protocol of the
'Lobe Fault'.   It  is then  the  responsibility  of the  protocol  to
attempt to  re-open the  adapter itself  at intervals  until one  such
attempt succeeds.  However, some  protocols (especially DOS protocols)
will not attempt to  re-open the adapter; instead,  they will assume a
fatal error  has occured  with the  MAC  driver (MDGND)  and fail  all
subsequent  requests  from   the  higher  levels   (e.g.  the  network
redirector) in the system.

If 'AutoOpen = Yes' is set in MDGND's PROTOCOL.INI section, MDGND will
attempt to re-open the adapter itself.  However, by default MDGND will
still inform the  protocol of the  'Lobe Fault', so  that although the
adapter will  now  re-open when  the  cable  is re-attached,  a  bound
protocol may choose to  not re-use the  adapter if it  believes that a
fatal error  has  occured.   The best  answer  is  not to  inform  the
protocol of the  'Lobe Fault'  by masking out  this error  bit through
the MDGND ring-status report parameter,  viz 'RStatusReport = 0xF7FF'.
Note that  setting  the 'RStatusReport'  parameter  in this  way  will
result in fewer  ring status  being reported  to any  bound management
protocol, which may not be desired behaviour.

In conclusion, most OS/2  protocols (e.g. IBM's  OS/2 NETBIOS protocol
supplied with  LAPS /  MPTS) will  recover from  cable disconnections.
Most DOS protocols (e.g. IBM's DOS NETBIOS protocol supplied with DLS)
will not recover from a cable being  disconnected for more than 5 - 10
seconds, and if this feature is required  it is recommended to add the
following to the MDGND PROTOCOL.INI section:

    AutoOpen = Yes
    RStatusReport = 0xF7FF

However, these  parameters are  not  applied in  general to  MDGND.DOS
since  some  protocols  require  the   ability  to  open  the  adapter
themselves (e.g. Microsoft's  TCP/IP protocol stack  supplied with the
DOS LAN Manager workstation software).


9.5.1) Application to Hot-Swapping and APM
------------------------------------------

Since hot-swapping and APM support are  implemented in the same way as
cable disconnection /  insertion, the  requirement on the  protocol to
recover  from  cable  disconnection  applies  equally  well  to  these
environments.  Hence, with  OS/2 no parameters  are generally required
to support hot-swapping /  APM; with DOS, it  is generally recommended
to include the PROTOCOL.INI parameters:

    AutoOpen = Yes
    RStatusReport = 0xF7FF

See sections (5) and (6) for more details.


9.5.2) Application to IBM's ODI2NDI.OS2
---------------------------------------

IBM's ODI2NDI.OS2 protocol stack provides  an ODI interface over NDIS.
It is used to  provide support for the  Netware Requester running over
an NDIS MAC driver.

There is  a  problem with  this  driver which  results  in the  driver
causing the system to Trap D when  the 'Lobe Fault' status is reported
by MDGND.  Until this problem is fixed,  it is recommended that if the
cable is  likely to  be detached,  or  APM /  hot-swapping support  is
required in  an  environment  where  ODI2NDI.OS2 is  being  used,  the
following lines are added to the MDGND PROTOCOL.INI section:

    AutoOpen = Yes
    RStatusReport = 0xF7FF


9.6) Configuring for Use with IBM's ODI2NDI.OS2
-----------------------------------------------

IBM's ODI2NDI.OS2 protocol stack provides  an ODI interface over NDIS.
It is used to  provide support for the  Netware Requester running over
an NDIS MAC driver.

When ODI2NDI.OS2 is  loaded from  CONFIG.SYS, it needs  to be  able to
obtain the node address that  will be used by the  adapter to which it
is binding.  In  general, this information  is not available  from the
adapter at this  time because  the adapter  has not  been initialized.
However, there  are  three main  ways  in which  this  address can  be
found.

    a) The address  that the  adapter will  use can  be configured  in
       the ODI2NDI  section of  PROTOCOL.INI,  using the  'NetAddress'
       parameter.  If this is  a locally-administered address, ODI2NDI
       will then attempt  to open the  adapter with this  node address
       if 'AutoOpen'  is not  set.  This  is the  best mechanism,  but
       it does  require the  user to  establish the  address that  the
       adapter will  use (normally  its  BIA), and  then to  configure
       ODI2NDI with that value using LAPS / MPTS.

       When installing OS/2 Warp Connect or  OS/2 Warp Server, the IBM
       installation program will automatically pick out the address of
       the  adapter   and  add   this  to   the  ODI2NDI   section  of
       PROTOCOL.INI.   However,  for  this  process   to  work  it  is
       necessary for the adapter  to be present and  able to open onto
       the ring during  the installation  of the operating  system: if
       the process  fails,  an  undefined  error  is  reported  during
       installation of the Netware Client software.

    b) The  address  can   be  explicitly   specified  in   the  MDGND
       PROTOCOL.INI section, through either the 'BIA' parameter or the
       'NodeAddress' parameter.   Again,  this  requires the  user  to
       enter the appropriate value in  PROTOCOL.INI.  This method also
       puts an  extra  requirement  on  the  ordering  of  CONFIG.SYS:
       MDGND.OS2 must now  be loaded  before ODI2NDI.OS2, so  that the
       open address can be obtained.

    c) The burnt-in address of the adapter can be dynamically obtained
       from the  adapter  before  ODI2NDI.OS2 is  loaded  by  ordering
       CONFIG.SYS as  in (b),  and by  setting the  MDGND 'InitOnLoad'
       parameter to 'Yes'.   Again, this  requires the  user to  set a
       PROTOCOL.INI parameter,  but  is  more simple  than  the  above
       choices.  However, 'InitOnLoad = Yes' is not strictly compliant
       with the  NDIS  specification,  and will  cause  problems  when
       remote booting.

In addition to the  above, there is an  important ordering requirement
for CONFIG.SYS.

    i) PROTMAN.OS2 must be loaded before any network drivers.

   ii) MDGND.OS2 must be  loaded before  ODI2NDI.OS2 in order  for (b)
       and (c) to be used.

  iii) LSL.SYS must be loaded before ODI2NDI.OS2.

   iv) ODI2NDI.OS2 must be loaded before IPX.SYS.

The best approach is to have the 'NETWARE REQUESTER STATEMENTS' at the
end of CONFIG.SYS.  Ensure  that ODI2NDI.OS2 is being  used instead of
the ODI MAC driver (such as  NTR2000.SYS), and that ROUTE.SYS is being
loaded.


9.7) Using MDGND.OS2 with Access for OS/2 and OS/2 Jet Direct
-------------------------------------------------------------

Eicon Technology's  Access for  OS/2 is  a Host  connectivity product.
HP's OS/2 Jet Direct  utilty allows the user  to configure HP printers
across a LAN.

Both of these  products use a  special part of  the NDIS specification
in order to  communicate with  their intended  systems over  a source-
routing bridge.  They both require the  MAC driver to correctly return
the 'AddressRecognized'  and 'FrameCopied'  bits  from the  Token-Ring
frame when  it is  received back  by the  transmitting adapter.   This
requirement slows performance, and is  not implimented by default with
MDGND.  So, a special  parameter must be set  to allow these protocols
to communicate  with  their intended  hosts  is the  other  side of  a
source-routing bridge.

Setting 'ReturnStatus = Yes'  will force these bits  to be returned to
the bound  protocol.  This  parameter replaces  the 'HostAddress'  and
'PrinterAddress' parameters available  in the  Madge Fastmac  NDIS MAC
drivers SMARTND.DOS  and SMARTND.OS2.   MDGND.DOS  and MDGND.OS2  will
recognize these  two  old  parameters,  and replace  them  by  setting
'ReturnStatus = Yes' internally when parsing PROTOCOL.INI.


9.8) Using MDGND.DOS with LAN Manager v2.0 and MDGND.OS2 with Banyan
--------------------------------------------------------------------
                                                     Vines Workstation
                                                     -----------------

The protocols supplied with Microsoft LAN Manager v2.0 DOS workstation
and Banyan Vines OS/2 workstation  both disobey the NDIS specification
by not filling in the  source address in the  Token-Ring header of the
frames they pass to the NDIS MAC driver for transmission.

The driver can be forced to fill  in these addresses itself by setting
the  'ForceAddress'  parameter   to  'Yes'.   However,   setting  this
parameter will stop from  working any protocol that  wants to transmit
a frame with  a source  address other  than the  open address  (e.g. a
protocol that is acting as part of a source-routing bridge).

Note that  SMARTND.DOS  and  SMARTND.OS2  both filled  in  the  source
address for every transmitted frame themselves - this is no longer the
case with MDGND.DOS and MDGND.OS2.


9.9) Making the Adapter Secure for Use by MDGND.DOS
---------------------------------------------------

In order for  an adapter  to be opened  in 'promiscuous  receive' mode
(i.e. to be able  to receive all  frames on the  ring) with MDGND.DOS,
it must first be made 'secure'.

Adapters that  do not  have the  capability of  supporting a  SmartROM
(e.g. Smart 16/4  PCMCIA Ringnodes)  are secure by  default.  Adapters
that support a SmartROM  must have a SmartROM  attached.  The SmartROM
must then be programmed with the '/PROMRX' option, e.g.

    SMARTROM /IO=0A20 /PROMRX /WRITE

For details  on enabling  promiscuous receive  with MDGND.OS2,  please
contact Madge Technical Support.


9.10) Support for IBM OS/2 v1.3x EE
-----------------------------------

MDGND.OS2 from LSS 5.0(0) supports IBM OS/2 v1.3x EE through the Madge
DLC driver  MDGDLC.OS2.  This  DLC  driver is  not  supplied with  LSS
5.0(0): it is assumed that  the user already has a  copy of the driver
from an older version  of the Madge LSS.   If this is not  the case, a
copy of MDGDLC.OS2 and its associated files may be obtained from Madge
Technical Support.

MDGND.OS2 is offered as  an upgrade for an  existing installation with
SMARTND.OS2  and  MDGDLC.OS2:  no   explicit  first-time  installation
utility / guide is supplied.  However, the only changes that should be
required to  update  an  existing  installation  from  SMARTND.OS2  to
MDGND.OS2 are to:

    a) copy  MDGND.OS2  into  the  C:\MDGDLC  directory  (or  wherever
       SMARTND.OS2 was originally installed);

    b) edit CONFIG.SYS to load MDGND.OS2 and not SMARTND.OS2;

    c) edit C:\MDGDLC\PROTOCOL.INI (where  C:\MDGDLC is  the directory
       where  MDGDLC.OS2   is  installed),   and   replace  the   line
       'DriverName = SMARTND$' with the line 'DriverName = MDGND$';

    d) re-boot OS/2.

Note that not  all of the  SMARTND parameters present  in PROTOCOL.INI
are supported  by MDGND;  these will  be ignored  with an  appropriate
warning.  One particular  example is  the 'InitBind'  parameter.  This
has been replaced  in MDGND.OS2  by the 'InitOnLoad'  parameter, which
initializes the adapter immediately but  does not initiate the binding
process.  This  parameter  can then  be  used  in order  for  adapter-
initialisation messages to be  displayed at init-time.   Note that, as
with 'InitBind', 'InitOnLoad' should not be used with RIPL.


9.11) DOS RIPL with MDGND.DOS
-----------------------------

If MDGND.DOS is being used  on a DOS system that  is being booted from
a  LAN  Server  /  LAN  Manager  server,  it  is  important  that  the
'RemoteBoot' parameter is set in the MDGND PROTOCOL.INI section.  This
is necessary in order to ensure that:

    a) the driver  does not  attempt to  initialize the  adapter until
       bind-time;

    b) the driver attempts to  locate the Fastmac  Plus download image
       in conventional memory rather than  using the cut-down DOS file
       system;

    c) the  driver  assumes   that  the   machine  may  be   put  into
       virtual-8086 mode (e.g. by  loading EMM386.EXE) after MDGND.DOS
       is loaded.

Failure to set this  parameter may result in  RIPL failing, or network
data errors after RIPL appears to have completed successfully.


9.12) Hot-Swapping and APM support When Using MADGECS
-----------------------------------------------------

MADGECS.EXE or MADGECS.SYS can be used  to provide the card and socket
services  functions  when  using  Smart  16/4  PCMCIA  Ringnodes  with
MDGND.DOS and MDGND.OS2 respectively.

It is  important to  note that,  while  versions of  MADGECS prior  to
LSS 5.0(0) (such  as v1.08 from  LSS 4.3(2)) work  perfectly well with
MDGND in most  environments, the updated  version of MADGECS  from LSS
5.0(0) is required  in order  to support  hot-swapping and  APM.  This
later driver  solves  the  problem where  MDGND  is  not able  to  use
adapters inserted  after  bind-time  or  to re-use  adapters  after  a
suspend event has occured.


9.13) MDGND.OS2 APM support When Using PCMCIA.SYS
-------------------------------------------------

IBM's PCMCIA.SYS driver provides Card Services support for OS/2.

If this  driver is  being used  to  provide card  services support  to
MDGND.OS2 when using Smart  16/4 PCMCIA Ringnodes, it  is important to
ensure PCMCIA.SYS v1.33 or later is installed in order for APM support
to work  correctly.  This  solves  the problem  where PCMCIA.SYS  will
hang the system when a suspend event is processed for the first time.

It is possible to recover  from this hung state,  by ejecting and then
re-inserting the  adapter,  and  then ejecting  and  re-inserting  the
adapter once resume has occured: this requires hot-swapping support to
also be enabled.  This  procedure is only required  for the first time
the system is put into suspend mode.

If it is not possible to upgrade the version of PCMCIA.SYS, then it is
recommended that  the  user eject  and  re-insert the  adapter  before
entering suspend mode; this  requires hot-swapping support  as well as
APM support to be enabled.

Version 1.33  of PCMCIA.SYS  is  supplied by  default  with OS/2  Warp
Server v4  Advanced.   The version  of  the file  is  contained in  an
embedded string, and can be found by running a utility such as DEBUG.


                    ****** End of MDGND.TXT ******                    
