Madge Fastmac Plus NDIS MAC Drivers for Madge 16/4 CardBus Adapters -
=====================================================================
                                                Additional Information
                                                ======================

                                              CSS 1.0(0), January 1997
                                              ------------------------

Summary
-------

This  document  provides  details  of  the Madge Fastmac Plus NDIS MAC 
drivers for Madge 16/4 CardBus Adapters, MCBND.DOS and  MCBND.OS2.  It 
supplements  the  information  provided in the on-line CardBus manual.  

The topics covered are:

1) Configuring the driver

2) Multiple adapter support

3) Performance tuning MCBND

4) Hot-swapping support with MCBND

5) Advanced Power Management support with MCBND

6) LAN Distance Connection Server support with MCBND.OS2

7) MCBND configuration parameters

8) Troubleshooting



1) Configuring the Driver
-------------------------

1.1) How to alter the driver configuration
------------------------------------------

MCBND.DOS and MCBND.OS2 need to be configured  from  the  PROTOCOL.INI 
file.  You  can  find this file by examining CONFIG.SYS.  For example, 
the '/I:' argument for the 'DEVICE=' line that  loads  PROTMAN.OS2  or 
PROTMAN.DOS  gives  the  path  to  PROTOCOL.INI.   If  you  are  using 
MCBND.DOS with Windows for WorkGroups, PROTOCOL.INI will  probably  be 
in  the  same  directory as NET.EXE (you can find NET.EXE by examining 
AUTOEXEC.BAT and searching for the line that runs the 'NET'  command).  
If  you  are  using  MCBND.DOS with Windows 95, you will probably find 
PROTOCOL.INI in the C:\WINDOWS directory.

PROTOCOL.INI  is  a  text  file.   It  contains  one  section for each 
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 might be of the form:

    [MCBND_nif]

       DriverName = MCBND$
       IOAddress = 0x0A20
       MaxFrameSize = 17846

For MCBND.DOS or MCBND.OS2, there is one PROTOCOL.INI section for each 
network  adapter  you intend to use.  These sections are characterised 
by the line:

       DriverName = MCBND$

Each  section  describes a single network adapter module.  To find out 
which protocol binds  to  an  adapter  module,  search  the  Protocols 
section of PROTOCOL.INI for the line:

       Bindings = xyz

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

Having located the section in PROTOCOL.INI that describes  the  driver 
for  a  particular  adapter,  you can add or remove driver parameters.  
You can do this by editing PROTOCOL.INI manually or by using a special 
NDIS configuration utility.  Under OS/2, the LAPS or MPTS  utility  is 
generally  available; these allow you to edit the most useful settings 
for the MCBND.OS2 driver.  Under DOS, the appropriate utility  depends 
on  which  environment you are using: 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 the Network Properties dialog.

Note that these different utilities do not permit you to configure all 
the  possible  driver  parameters for MCBND.  For some parameters, you 
must edit PROTOCOL.INI manually. 


1.2) Types of Configuration Parameters
--------------------------------------

PROTOCOL.INI parameters are of the form:

    Keyword[ = Value]

An sample section for loading the MCBND.OS2 driver  might  be  of  the 
form:

    [MCBND_nif]

       DriverName = MCBND$
       Slot = 2
       AutoOpen

MCBND.OS2 and MCBND.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  is:

                            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.   You  can  express  the  value  in 
			decimal format, or - by  prefixing  the  value 
			with '0x' - in hexadecimal format.  An example 
			of a PARM_WORD parameter is:

                            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 is:
			
			     AutoOpen = Yes



2) Multiple Adapter Support
---------------------------
You can use MCBND.DOS or MCBND.OS2 to  drive  more  than  one  network 
adapter  at  a  time.   To  do this, you need to have one PROTOCOL.INI 
module containing the line 'DriverName = MCBND$' for each  adapter  in 
the PC.  You then need to bind a protocol to each adapter by using the 
'Bindings = xyz' line in the Protocols section of PROTOCOL.INI ('xyz' 
is the name of the adapter module).

**********************************************************************
Note: MCBND.DOS  and  MCBND.OS2  only  support  the Madge 16/4 CardBus 
      Adapters.  To support other Madge adapters in the  same  machine 
      you   must   run  other  drivers  (for  example,  MDGND.DOS  and 
      MDGND.OS2) on the other adapters.
**********************************************************************
      
To associate an adapter module with a particular adapter you  need  to 
use   one  of  three  special  MCBND  parameters:  'BIA',  'Slot',  or 
'IOAddress'.  You can specify any number of each of  these  parameters 
in  a  particular module <<Martyn, why would you use more than one?>>.  
However, if the values you specify are not consistent, the driver will 
report an error.  These  three  parameters  are  known  as  the  three 
'primary specifiers'.

To use the 'Slot' parameter, just type 'slot=' followed by the  number 
of  the  physical slot that contains the adapter.  For example, if you 
have a Madge 16/4 CardBus Adapter in socket 1, then you would add  the 
line

    Slot = 1

to the MCBND PROTOCOL.INI module. This indicates that the module is to 
use the adapter in Slot 1.

You  can  use the 'BIA' or 'BurntInAddress' parameter by typing 'BIA=' 
and then typing the burnt-in address of the adapter.  For example,  if 
you  are using an adapter whose burnt-in address is 0000F6123456, then 
you would add the following line to the MCBND PROTOCOL.INI module  for 
that adapter:

    BIA = "0000F6123456"

To use the 'IOAddress' parameter, type 'IOAddress='  followed  by  the 
I/O  address  that the adapter is configured to use. This parameter is 
only useful if the adapter has been Auto-Configured (see  the  MADGECS 
documentation   for   details).  To cause MCBND to load onto an 
adapter at I/O address 0x8000, you would need to type the following 
line in the MCBND module:

    IOAddress = 0x8000

Once  you  have  bound  a  particular  module to a particular adapter, 
you can set other parameters.

**********************************************************************
Note: If you have set none of the above three parameters,  then  there 
      is  no  way  for  you  to control which adapter the driver loads 
      onto.
**********************************************************************


3) Performance Tuning MCBND
---------------------------

The default parameters for MCBND.DOS are set  to  provide  low  memory 
usage.   To  achieve higher performance (at the cost of consuming more 
memory), you can increase the 'MaxFrameSize' parameter.  should be For 
example, to set a maximum frame size  of  4484  bytes  (which  is  the 
maximum value for a 4Mbps Token-Ring), you would specify the following 
in the relevant MCBND module in PROTOCOL.INI:

    MaxFrameSize = 4484


Similarly,  to  achieve  higher performance with MCBND.OS2 on a 16Mbps 
ring, you might want to increase the 'MaxFrameSize' parameter to 17846 
(this is the maximum value for a 16Mbps ring).  
      
**********************************************************************
NOTE: To benefit from faster network  performance  by  increasing  the 
      maximum  frame  size  on  a computer, you must also increase the 
      maximum frame size on the other computers on the network. 
**********************************************************************




4) Hot-Swapping Support with MCBND
----------------------------------
MCBND.DOS and MCBND.OS2 do support Hot Swapping. However, the DOS  and 
OS/2  operating  systems  were not designed with Hot Swapping in mind. 
For  this  reason,  if  you  want  Hot  Swapping,   there   are   some 
configuration issues that you need to be aware of. 
     
**********************************************************************
NOTE: If you configure the driver for Hot Swapping, then the  driver's 
      memory  resident  size  is  substantially  increased.  For  this 
      reason, MCBND.DOS has Hot Swapping disabled by default.    
**********************************************************************


4.1) Recommendations
--------------------

a)   The parameters you need to set if you require Hot  Swapping  are: 
     HotSwap=Yes,  AutoOpen=Yes,  RStatusReport=<memory  address>, and 
     NodeAddress=<MAC address>. By default, the HotSwap= parameter  is 
     set to No for MCBND.DOS, and to Yes for MCBND.OS2. 
     
     The  following  is  a  sample  MCBND_nif  section of PROTOCOL.INI 
     section for MCBND.DOS:

               [MCBND_nif]
                  DriverName = MCBND$
                  HotSwap = Yes
                  AutoOpen = Yes
                  RStatusReport = 0xF7FF
                  NodeAddress = "400012345678"

     The following is  a  sample  MCBND_nif  section  of  PROTOCOL.INI 
     section  for OS/2 (by default, the HotSwap= parameter for OS/2 is 
     set to Yes):

               [MCBND_nif]
                  DriverName = MCBND$
                  AutoOpen = Yes
                  RStatusReport = 0xF7FF
                  NodeAddress = "400012345678"

     For more information about the AutoOpen= and  the  RStatusReport= 
     options,  see  Section  4.1.e  below. For more information about 
     the NodeAddress= parameter, see Section 4.4 below. 

b)   Before  removing  an  adapter,  stop all network activity on that 
     adapter.  To do this, shut down any  networked  applications  you 
     are  using,  un-map  any  networked  drives, and log off from all 
     servers.  Shut down the network redirector itself (for example by 
     using NET STOP) if this is possible.

c)   Only  start  up the network redirector (for example, by using NET 
     START) after inserting the adapter.

d)   If you are using MADGECS to provide the Card and Socket Services, 
     make sure you upgrade to the version supplied with CSS 1.0(0).

e)   If you are using ODI2NDI.OS2 to provide  an  ODI  interface  over 
     MCBND.OS2  (for  example,  for  Netware  Requester  support),  we 
     recommend  you  to  use  the   'RStatusReport'   and   'AutoOpen' 
     parameters  in  PROTOCOL.INI (see Section 4.1.a above). If you do 
     not use these parameters you might experience TRAP D errors  when 
     you remove the adapter. 
      
********************************************************************** 
NOTE: We recommend you to perform steps 4.1.b and 4.1.c,  but  if  you 
      don't  it  is possible in general to Hot Swap adapters while you 
      are still using the network.  If you do not perform steps  4.1.b 
      and  4.1.c,  note  however that: you might lose some frames when 
      you remove the adapter; your network redirector might  beep  and 
      report  network errors while the adapter is absent; and finally, 
      any NetWare connections you  had  before  removing  the  adapter 
      might have timed out by the time you put the adapter back.        
**********************************************************************


4.2) What Hot Swapping support enables you to do
------------------------------------------------

Both  MCBND.DOS  and MCBND.OS2 support Hot Swapping for the Madge 16/4 
CardBus Adapter.  With Hot Swapping enabled you can:

a)    Remove an adapter after that adapter has been initialized.

b)    Insert another adapter after removing an adapter that  has  been 
      initialized.

c)    Insert an adapter after you have loaded the driver for it.

The  default setting of the HotSwap= parameter is 'Yes' for MCBND.OS2, 
and 'No' for MCBND.DOS. The reason it is set to 'No' for MCBND.DOS  is 
that Hot Swapping support substantially increases the driver's size as 
memory-resident software. 



4.2.1) When you remove an adapter that has been initialized 
------------------------------------------------------------
When  you remove an adapter that has been initialized, the response of 
the driver depends on whether the 'HotSwap' parameter is set to  'Yes' 
or 'No'.  

If the parameter is set to 'Yes', the driver acts as if the adapter is 
still  present  but  the cable has been detached: it informs the bound 
protocol(s) of the change  in  ring  status;  it  then  completes  any 
outstanding  transmits  or requests with an error code; and finally it 
responds to any further requests by reporting that the adapter  cannot 
open  onto  the  ring.  The driver also 'frees up' the adapter's MCBND 
section in PROTOCOL.INI.  

If the parameter is set to 'No', the driver still reports  the  change 
in  ring status as if the cable has been detached, but it also reports 
that a fatal hardware error has occured. The  protocol(s)  running  on 
top of the driver then make no further attempt to use that adapter.


4.2.2)  When you insert another adapter after removing an adapter that 
        has already been initialized
----------------------------------------------------------------------
Again, the response of the driver to this event depends on whether you 
have set the 'HotSwap=' parameter to 'Yes' or 'No'.

If the parameter is set to 'No', the driver ignores this event.

If the parameter is set to 'Yes', the driver  attempts  to  initialize 
the  new  adapter.   To  do  this, it needs to use an MCBND section in 
PROTOCOL.INI  which  is  not  currently  assigned  to  an  initialized 
adapter. Because you have removed the original adapter, there is now a 
freed up MCBND-nif section in PROTOCOL.INI.  The driver therefore uses 
this.

The 'IOAddress=', 'Slot=', and  'BurntInAddress='  parameters  in  the 
MCBND_nif section must all match the configuration of the new adapter. 
Otherwise  the  driver  cannot use the adapter. (If there is more than 
one free MCBND_nif section, the driver  checks  through  each  section 
looking for one that matches the configuration of the adapter. 

This means that you can remove one adapter and replace it with another 
adapter in a different slot as long as an MCBND_nif section exists for 
the adapter in that slot.

If the driver successfully initializes the inserted adapter, it starts 
to  accept  incoming requests from the bound protocol(s).  If you have 
set the 'AutoOpen' parameter 'Yes', then the driver opens the  adapter 
immediately. Otherwise, the protocol will attempt to open the adapter.  
Once  the adapter is open, the transmit and receive processes continue 
just as before the original adapter was removed.


4.2.3) When you insert an adapter after loading the driver
----------------------------------------------------------
This  case  is  subtly different from that of Section 4.2.2. This time 
the driver has to cope with there being no  adapter  present  when  it 
first attempts to match MCBND PROTOCOL.INI sections to the adapters in 
the  PC.  Then,  when  you do insert the adapter, the driver has to be 
able to find a free MCBND_nif section to associate with it.

If you have set the 'HotSwap=' parameter to  'Yes',  the  driver  sets 
aside  resources  for  any  MCBND  PROTOCOL.INI  sections that have no 
matching adapter. It then binds  these  sections  to  the  protocol(s) 
running  on top of the driver. When you insert an adapter into the PC, 
the driver attempts to associate an MCBND-nif section with it.   Until 
it  has  associated  an  adapter with an MCBND_nif section, the driver 
responds to any requests from the protocol(s) by indicating  that  the 
adapter is present but unable to open onto the ring.  

If the 'HotSwap' parameter is set to 'No', the driver does not reserve 
set aside resources for any  any  free  MCBND  PROTOCOL.INI  sections. 
Instead,  it  reports  errors  for  these  sections,  and the protocol 
binding process fails.


4.3) Hot Swapping increases the size of the memory-resident driver
------------------------------------------------------------------
To  support  Hot  Swapping,  the driver must retain more code and data 
while resident in memory than it would otherwise retain.  The code and 
data that it retains for Hot Swapping is otherwise  thrown  away  once 
all the adapters have been initialized.  

Under  DOS,  if  the  'HotSwap'  parameter is set to 'Yes', the driver 
attempts to copy this extra code and data  into  extended  memory  (if 
available).   To  do  this,  it  tries first to allocate the necessary 
memory from the HIMEM.SYS if it is loaded.  If this is not successful, 
it attempts to allocate memory for  itself  using  BIOS  INT15  system 
services.  Then, if this is also unsuccessful, the driver is forced to 
use  conventional  memory  for  the  extra code and data.  Even if the 
driver is able to use extended memory, the size  of  the  driver  will 
increase  substantially  to  support  hot-swapping.  This  is  why the 
default setting for MCBND.DOS is 'HotSwap = No'.


4.4) Protocols and Hot Swapping
-------------------------------
If you remove an adapter and then re-insert it, the protocols that are 
bound  to  the  adapter need to be able to cope with the network cable 
being detached and then re-attached. If you are using a protocol  that 
cannot  support  cable detachment and re-attachment, you can configure 
MCBND to handle the re-opening of the adapter. To  do  this,  use  the 
add the 'AutoOpen=Yes' and RStatusReport=0xF7FF' parameters to the 
appropriate MCBND_nif section:

        AutoOpen = Yes
        RStatusReport = 0xF7FF

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

If you remove an adapter and then insert another one, or if you remove 
an adapter and then insert another one  into  a  different  slot,  the 
protocols  need  to  be  able  dynamically  to determine the adapter's 
burnt-in address. If you are using a protocol that cannot do this, you 
can configure MCBND always to export the same current address  to  the 
protocol.  To  do  this,  you  need to use the 'BurntInAddress' and/or 
'NodeAddress' parameters.  

The  'BurntInAddress'  parameter  associates  a  particular  MCBND_nif 
section with a particular adapter. If that adapter is not  present  at 
initialization  or  bind-time,  and  you  have not specified a Locally 
Administered Address (LAA) by using the 'NodeAddress' parameter,  then 
MCBND  will  always  export  the  value  you  have  specified  for the 
'BurntInAddress' as the current address.  If you have specified an LAA 
by using the 'NodeAddress' parameter, then MCBND will export  the  LAA 
as   the   current   address,  even  if  you  have  also  specified  a 
'BurntInAddress'.

As  an  example,  IBM's latest OS/2 NETBIOS stack is able to cope with 
cable  re-attachment  and  it  also  determines   burnt-in   addresses 
dynamically.   In  this  case,  therefore,  you do not need to use any 
parameters to support Hot Swapping.  IBM's latest DOS  NETBIOS  stack, 
however,  cannot  cope  with  cable re-attachment and cannot determine 
burntin addresses dynamically. Therefore, for Hot Swapping  with  this 
protocol,  you  must  add  the  following  to  the  appropriate  MCBND 
PROTOCOL.INI section:

        HotSwap = Yes
        AutoOpen = Yes
        RStatusReport = 0xF7FF
        NodeAddress = ...
        BurntInAddress = ...

For full Hot Swapping support with IBM's DOS NETBIOS stack,  you  must 
use  either  the  'NodeAddress'  or the 'BurntInAddress' parameters or 
both.



5) Advanced Power Management (APM) with MCBND 
---------------------------------------------

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

a)   You might need to set some parameters to support APM.

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

               [MCBND_nif]
                  DriverName = MCBND$
                  APM = Yes
                  AutoOpen = Yes
                  RStatusReport = 0xF7FF
                  NodeAddress = "400012345678"

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

               [MCBND_nif]
                  DriverName = MCBND$
                  AutoOpen = Yes
                  RStatusReport = 0xF7FF
                  NodeAddress = "400012345678"

       
 b)  Before allowing the computer to  enter  suspend  mode,  stop  all 
     network  activity. To do this, shut down any network applications 
     you are using, un-map any network drives, and log  off  from  any 
     servers.  Then  shut  down  the  network  redirector  itself (for 
     example, by using NET STOP), if this is possible.

********************************************************************** 
NOTE: We recommend you to perform step (b), but if you do not you  can 
      enter suspend mode while you are still connected to the network.  
      It  is  just that 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  or  Microsoft  LAN   Manager),   since   these 
      connections  get re-established when you next access the server.  
      However, with  NCP-based  network  connections  (that  is,  with 
      Novell  NetWare), the connection will time out after a number of 
      minutes. You will then have to log into  the  server  again  the 
      next time you want to access it.
**********************************************************************
     
c)   If you are using MADGECS.SYS to provide Card and Socket Services, 
     upgrade to the version supplied with CSS 1.0(0).

d)   If you are using ODI2NDI.OS2 to provide  an  ODI  interface  over 
     MCBND.OS2  (for  example,  for  Netware  Requester  support),  we 
     recommend  you  to  use  the   'RStatusReport'   and   'AutoOpen' 
     parameters  in  PROTOCOL.INI (see Section 5.1.a above). If you do 
     not use these parameters you might experience TRAP D errors  when 
     you remove the adapter. 
     


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

Both  MCBND.DOS  and  MCBND.OS2  support  APM  'Suspend'  and 'Resume' 
events. To enable support APM support you must have the APM= parameter 
set to Yes.  By default, this parameter is set to 'Yes' for MCBND.OS2, 
and to 'No' for MCBND.DOS. The reason that that the default setting is 
'No'  for  the  DOS  driver  is  that  APM   support   increases   the 
memory-resident size of the driver.

5.2.1) Suspend Events
---------------------
When a suspend event occurs, the response of the driver depends on the
whether the 'APM' parameter is set to 'Yes' or 'No".  

If the parameter is set to 'Yes', the driver shuts  down  the  adapter 
(in  the  case  of  Madge  16/4  CardBus adapters, this results in the 
adapter being powered-down); it then inform the bound protocol(s) that 
the cable has been detached; completes any  outstanding  transmits  or 
requests  with  an error code; and responds to any further requests by 
reporting that the adapter cannot re-open onto the ring.   The  driver 
also  frees  up  the MCBND section in PROTOCOL.INI that is assigned to 
the adapter.  

If  the  parameter  is  set  to  'No', the driver still shuts down the 
adapter and reports the change in ring status as if the cable has been 
detached.  But it  also  reports  that  a  fatal  hardware  error  has 
occurred.,  The  protocol(s)  will  then  make  no  further use of the 
adapter.

When  all  the  driver  has  shut  down  all  the adapters that it had 
previously initalized, it reports  to  the  APM  driver  that  it  has 
successfully  handled the suspend event. The APM driver then continues 
putting the computer hardware into Suspend Mode.


5.2.2) Resume Events
--------------------
When a resume event occurs, the driver attempts to find  adapters  for 
each  MCBND  PROTOCOL.INI  section  that  has  'APM=' parameter set to 
'Yes'.  It tries to match adapters to these sections in the  same  way 
as  it  would originally have done at initialization or bind-time.  It 
then initializes matching adapters,  and  starts  to  accept  incoming 
requests  from the bound protocol(s).  

If  you  have  set  the 'AutoOpen' parameter to 'Yes', then the driver 
opens the adapter immediately. Otherwise the protocol will attempt  to 
open  the adapter.  When the adapter is open, the transmit and receive 
processes can continue just as before the suspend event occured.


5.3) Increased Resident Driver Size
-----------------------------------
To support APM the resident driver must  retain  more  code  and  data 
after  initializing the adapter than it would otherwise need.  This is 
why the default setting for the 'APM' parameter is 'No' under DOS.


5.4) Protocol / MCBND Behavioural Requirements
----------------------------------------------

To  support  resume events, a bound protocol must be able to cope with 
the cable being detached and then re-attached.  If  you  are  using  a 
protocol  that  cannot  support  cable  re-attachment,  then  you  can 
configure MCBND to open  the  adapter  itself.   The  issue  of  cable 
re-attachment  in  the context of APM is the same as in the context of 
hot-swapping; for more information see section (4.4).



6) LAN Distance Connection Server Support with MCBND.OS2
--------------------------------------------------------
MCBND.OS2 from CSS  1.0(0)  supports  IBM's  LAN  Distance  Connection 
Server.   To  install and configure the Connections Server, follow the 
information below in conjunction with  the  information  in  the  'LAN 
Distance  Advanced Guide'.  (The information below is for LAN Distance 
v5.0 from OS/2 Warp Server v4.0 Advanced. However, the  procedure  for 
installing  MCBND.OS2  with  other  versions  of  LAN Distance will be 
similar.)

a)   If it is not already installed, install IBM LAPS / MPTS onto  the 
     hard-disk.  Select 'Madge 16/4 CardBus Adapters' as the installed 
     network adapter.

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

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


          MCBND.NIF


     Create the following section at the end of the file:


       [MCBND.NIF]

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

     You can add other MCBND.OS2  parameters  to  PROTOCOL.INI  either 
     manually  or through the LAPS utility.  However, you must include 
     the three parameters listed above.

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  now 
     contains  an  entry  for the 'Madge 16/4 CardBus Adapters' in the 
     'Adapter for bridging'  list-box  under  the  'Address/LAN'  tab.  
     This  entry  should  be  selected.   (Note  that  the  'Settings' 
     notebook might take a few seconds to update this dialog.)

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


The LAN Distance Connection Server is now be able to use the MCBND.OS2 
driver  to  connect to the LAN.  The MCBND PROTOCOL.INI section needs 
to contain the following information:

    [MCBND_nif]

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

and the bridging protocol that binds to MCBND needs to have a  section 
of the form:

    [SR_BRIDGE]

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

If you need further help using the LAN Distance Connection Server with 
MCBND.OS2, contact Madge Technical Support.



7) MCBND Configuration Parameters
---------------------------------

7.1) MCBND.OS2 Configuration Parameters Summary
-----------------------------------------------

 ----------------- -------------- ---------- -------- --------
| Name:           | Parm-Type:   | Default: |   Min: |   Max: |
 ----------------- -------------- ---------- -------- --------
| DriverName      | PARM_STRING  |   <none> |    <1> |    <9> |
| Slot            | PARM_WORD    |   <none> |      0 |    254 |
| BurntInAddress  | PARM_STRING  |   <none> |   <12> |   <12> |
| BIA             | PARM_STRING  |   <none> |   <12> |   <12> |
| IOAddress       | PARM_WORD    |   <none> | 0x0000 | 0xFFFF |
| MaxFrameSize    | PARM_WORD    |     4484 |     14 |  17846 |
| NodeAddress     | PARM_STRING  |   <none> |   <12> |   <12> |
| AutoOpen        | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| BusMaster       | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| PIO             | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| TransferType    | PARM_WORD    |   <none> |      0 |      2 |
| 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 |
| SetIRQNumber    | PARM_WORD    |   <none> |      1 |     15 |
| 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 |
| 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.


7.2) MCBND.DOS Configuration Parameters Summary
-----------------------------------------------

 ----------------- -------------- ---------- -------- --------
| Name:           | Parm-Type:   | Default: |   Min: |   Max: |
 ----------------- -------------- ---------- -------- --------
| DriverName      | PARM_STRING  |   <none> |    <1> |    <9> |
| Slot            | PARM_WORD    |   <none> |      0 |    254 |
| BurntInAddress  | PARM_STRING  |   <none> |   <12> |   <12> |
| BIA             | PARM_STRING  |   <none> |   <12> |   <12> |
| IOAddress       | PARM_WORD    |   <none> | 0x0000 | 0xFFFF |
| MaxFrameSize    | PARM_WORD    |     1550 |     14 |  17846 |
| NodeAddress     | PARM_STRING  |   <none> |   <12> |   <12> |
| AutoOpen        | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| BusMaster       | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| PIO             | PARM_BOOLEAN |    FALSE |  FALSE |   TRUE |
| TransferType    | PARM_WORD    |   <none> |      0 |      2 |
| InitOnLoad      | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| CopyAllData     | PARM_BOOLEAN |   <none> |  FALSE |   TRUE |
| Watchdog        | PARM_BOOLEAN |     TRUE |  FALSE |   TRUE |
| WatchDogPeriod  | PARM_WORD    |        5 |      0 |     60 |
| IRQNumber       | PARM_WORD    |   <none> |      1 |     15 |
| SetIRQNumber    | PARM_WORD    |   <none> |      1 |     15 |
| 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 |
| 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) MCBND Configuration Parameters in Detail
---------------------------------------------

DriverName:      <DOS & OS2>

		  
		  
                 This  parameter  is  required  in  every  section  in
                 PROTOCOL.INI.  For  MCBND  driver, the  value must  be
                 'MCBND$'.   The   PROTOCOL.INI   file  can   contain
                 multiple sections with the

                     'DriverName = MCBND$'

		  entry.   Each  such  section  configures  a separate 
		  adapter.  To associate a particular section with one 
		  particular adapter use one of the  'IOAddress',  the 
		  'Slot',  or  'BurntInAddress'  parameters  described 
		  below.

		  Some   older  PROTOCOL.INI  files  use  a  numbering 
		  convention for multiple sections that apply  to  the 
		  same  driver.  According to this convention you must 
		  put a digit before the '$' character. The entry  for 
		  the second section is therefore:

                     'DriverName = MCBND2$'.


Slot:            <DOS & OS2>

		  Use  this  parameter  to specify the Slot containing 
		  the adapter that this section of PROTOCOL.INI is  to 
		  use.

		  For example, if you have put an adapter in  Slot  1, 
		  then the following entry

                     'Slot = 1'

		  forces  the  driver  to use that particular adapter.  
		  It  also   associates   the   current   section   in 
		  PROTOCOL.INI  with  the adapter in Slot 1. 

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

BurntInAddress:  <DOS & OS2>

		  Use this parameter to specify the  Burnt-In  Address 
		  (Universally  Administered  Address)  of the adapter 
		  that this section of PROTOCOL.INI is to use.

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

                     'BurntInAddress = "0000F6123456"'

		  forces the driver to use  that  particular  adapter.  
		  It   also   associates   the   current   section  in 
		  PROTOCOL.INI  with  that  adapter,  and  the   other 
		  parameters in that section will therefore also refer 
		  to that 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"'.

                                    
IOAddress:       <DOS & OS2>

		  Use this parameter to specify the IO address of  the 
		  adapter that this section of PROTOCOL.INI is to use.  
		  For  example,  if  an adapter has been configured to 
		  use IO location 0x8000, then the entry

                     'IOAddress = 0x8000'

		  will  force  the  driver  to  use  that   particular 
		  adapter.  It will also associate the current section 
		  in  PROTOCOL.INI  with  that  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.


MaxFrameSize:    <DOS & OS2>

                
		  Use this  parameter  to  specify  the  size  of  the 
		  largest  frame  that you want the adapter to be able 
		  to transmit onto or receive from the network.

		  The default  value  for  MCBND.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. For example:

                     'MaxFrameSize = 4484'.

		  The default value for MCBND.OS2 is 4484  bytes.   If 
		  the  adapter is being used on a 16Mbps ring, and the 
		  machine has plenty of memory,  then  increasing  the 
		  maximum frame size will improve performance.

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

		  If  you are using MCBND with an 802.2 protocol stack 
		  for Host connectivity, you must  set  'MaxFrameSize' 
		  to  a  value  that is at least equal to the PIU size 
		  plus the maximum size of the Token-Ring header.  For 
		  example, if the PIU size is set to 1994  bytes,  you 
		  must set 'MaxFrameSize' 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.  
		  Therefore, a sensible minimum value to use  is  256.  
		  (Smaller  values  may  be  appropriate  for  special 
		  frame-logging protocols that only  need  to  receive 
		  very small frames.)


NodeAddress:     <DOS & OS2>

		  Use this parameter 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 you need the adapter 
		  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  MCBND  might  attempt  to  set  the Node Address 
		  itself.  If it does, then the Node  Address  set  by 
		  the Protocol takes precedence over any 'NodeAddress' 
		  that you set PROTOCOL.INI.

		  If no Node Address is specified, the driver will use 
		  the adapter'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 need to be able to 
		  control the opening and closing of the adapter,  and 
		  they  therefore  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 attempt  to use
                 PIO.

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

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

		  This  parameter  can  be  overridden  by  the  'PIO' 
		  parameter.


PIO:             <DOS & OS2>

                 If this parameter  is set  to 'Yes', the  driver will
                 attempt to use the Programmed IO transfer method.

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

                 This parameter overrides the 'BusMaster' parameter.


TransferType:    <DOS & OS2>

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

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


InitOnLoad:      <DOS & OS2>

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

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

		  It is recommended that  this  parameter  be  set  to 
		  'Yes',  unless  there  is  a reason why the hardware 
		  must not be accessed until  NETBIND  has  run.  (The 
		  latter is often the case when remote booting.)

		  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' for 
		  MCBND.OS2  is  that it allows 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 MCBND module;

		  (c) the BIA parameter for the MCBND module.

		  See section (8.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  will  therefore  be  slightly   faster.  
		  Under  DOS,  if no value is set then the driver will 
		  select the best value.

		  The overhead of  copying  the  whole  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 
		  running. The driver will select 'Yes',  by  default, 
		  if  the  adapter  is  set  to use DMA and either the 
		  driver detects the presence of a memory  manager  or 
		  you  are  using  a  machine  that  is  being  booted 
		  remotely.

		  Under  DOS,  the driver can also detect when Windows 
		  starts executing in 386 Enhanced mode.  When Windows 
		  does this it implies that a memory  manager  is  now 
		  loading.  The driver will therefore 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.   However,  the  driver  cannot detect any 
		  memory manager (apart from MS Windows  386  Enhanced 
		  mode)   that   loads  after  the  adapter  has  been 
		  initialized.  In remote booted machines, the  memory 
		  manager often loads after NETBIND has run.

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

		  Under  OS/2, there is normally no need to alter this 
		  parameter to 'Yes': the translation from virtual  to 
		  physical   addresses   is  handled  by  the  driver.  
		  However, you need to set the parameter to 'Yes' when 
		  you are using MCBND.OS2 in  conjunction  with  IBM's 
		  LAN  Distance  Connection  Server,  as  described in 
		  section (8.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. The driver  will  periodically  update  a 
		  timer  on  the adapter.  If the computer hangs or is 
		  rebooted, the timer will not  be  updated,  and  the 
		  adapter will shut itself down.

		  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 after a reboot.

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


WatchDogPeriod:  <DOS & OS2>

		  This  parameter  can  be used to specify the timeout 
		  period that the driver uses for the watchdog feature 
		  (described above). 

		  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.

		  The  following  example  sets  a timeout period of 3 
		  seconds:
		  
		      'WatchDogPeriod = 3'

IRQNumber:       <DOS & OS2>

		  This  parameter  can  be used to verify the IRQ line 
		  that the selected adapter is configured to use.   If 
		  you set the parameter to 15, for example, 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.

		  Example:
		  
	           'IRQNumber = 15'
  

SetIRQNumber:    <DOS & OS2>

		  This  parameter  can be used to force the adapter to 
		  use a particular  IRQ  line.   The  parameter  will, 
		  however,  only  work on CardBus machines that do not 
		  have their IRQ lines fixed by the BIOS (most CardBus 
		  machines do have their IRQ lines fixed by the BIOS).

		  A sample setting which forces the adapter to use IRQ 
		  15 is as follows:

                     'SetIRQNumber = 15'

		  If the IRQ line you specify cannot  be  forced  then 
		  the driver will return an error.


Force16:         <DOS & OS2>

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

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

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


Force4:          <DOS & OS2>

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

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

		  This  parameter  only  need  be used to override the 
		  ring speed configured at the adapter.


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 setting this parameter to 'Yes' under DOS 
		  results in a much larger resident driver.


HotSwap:         <DOS & OS2>

		  This  parameter  determines   whether   the   driver 
		  supports  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  enables  the 
		  driver to cope with protocols that do not conform to 
		  the  NDIS2  specification  by  filling in this field 
		  themselves.  However, setting this  value  to  'Yes' 
		  will cause a small reduction on performance. It will 
		  also  cause  problems  for protocols that attempt to 
		  transmit frames with source addresses other than the 
		  adapter's open address.

		  This  parameter  is  known to be required for Banyan 
		  Vines OS/2 workstations, and LAN  Manager  v2.0  DOS 
		  workstations.  (See section 8.8)


ReturnStatus:    <DOS & OS2>

		  Settings  this  parameter  to  'Yes'  will force the 
		  driver to return to the protocol the 'status' of all 
		  frames passed  for  transmission  by  the  protocol.  
		  (The     'status'    is    the    FrameCopied    and 
		  AddressRecognized bits from the FrameStatus byte  at 
		  the end of the Token-Ring frame.)
		  
		  Setting  this  parameter  to  'Yes'   will   reduces 
		  performance.   However,  you  need to do it for some 
		  applications, including  Eicon  Technology's  Access 
		  for  OS/2 product, and HP's OS/2 Jet Direct utility.  
		  (See section (8.7)
                 

OpenOptions:     <DOS & OS2>

		  You can  use  this  parameter  to  select  different 
		  facilities  that  the  adapter  offers when it opens 
		  onto 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. If the bit is not set 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 for diagnosis of 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.

		  Example of the OpenOptions parameter:

                     'OpenOptions = 0x0006'

		  This example 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 (8.9) for details of  how  this  can  be 
		  achieved.

		  The OpenOptions parameter can be set by the protocol 
		  that is bound to the  driver.   In  this  case,  the 
		  protocol   will   also   need  to  set  the  correct 
		  PacketFilter so that it receives  all  LLC  and  MAC 
		  frames.   Protocol  Analyser  software will normally 
		  set the OpenOptions and PacketFilter  correctly,  by 
		  default.

		  You  do  not  normally  need  to use the OpenOptions 
		  parameter.  However,  you  will  need  to  make  the 
		  adapter  'secure'  in  order  for  Protocol Analyser 
		  software to function correctly.


ForceOpen:       <DOS & OS2>

		  Setting  this  parameter   to   'Yes'   causes   the 
		  FORCE_OPEN  bit  of  the  OpenOptions parameter (see 
		  above) to be set.  This causes the adapter  to  open 
		  in loopback mode, and then forcibly to insert itself 
		  onto  the  main  ring.  The driver 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 for diagnosing 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' option 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 the 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

                 Example of the 'RStatusReport' paramter:

                     'RStatusReport = 0xFFFF'

		  This  example  will  force  all  ring statuses to be 
		  reported to the bound protocol.  This is the default 
		  setting.  If you set the bitmask to '0x0000' then no 
		  status-change events will be reported to  the  bound 
		  protocol.


DTR:             <DOS & OS2>

		  You can use this parameter to force  the  driver  to 
		  open  the  associated adapter in either Classic mode 
		  (if 'DTR = No' is set) or DTR mode (if 'DTR  =  Yes' 
		  is  set).   If the driver cannot open the adapter in 
		  the requested mode, it will report an error, and you 
		  will not be able to use the adapter.

		  In general, you will not need to set this parameter. 
		  By default, the driver will always attempt  to  open 
		  in  DTR  mode,  and  it will only attempt to open in 
		  Classic mode if DTR mode fails.  This is the correct 
		  behaviour  for  most  situations.   However,  it  is 
		  possible  that  you will want to force the driver to 
		  open the adapter in Classic  mode  even  though  DTR 
		  mode is available. In this case, then set the 
		  parameter as follows:
		  
		  	 'DTR=No'.


LoopBack:        <DOS & OS2>

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

		  By default, when MCBND 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. Also, by default, when the  driver  opens 
		  the  adapter  in  DTR mode, no frames will be looped 
		  back.   This  behaviour  is  appropriate  for   most 
		  situations,  but  there  are  some applications, for 
		  example, IBM's LAN Distance Connection  Server  (see 
		  section  6) that require the protocol not to receive 
		  back that it has transmitted.

		  To force frames not to be looped back, set 'LoopBack 
		  = No'. If you set 'LoopBack = Yes' , this will force 
		  the  protocol to expect all appropriate frames to be 
		  looped back (this is not correct when the adapter is 
		  open in DTR mode, and it will cause the protocol  to 
		  function  incorrectly).   


QSPNSY:          <OS2 Only>

		  This  parameter  is  only  required  for  IBM's  LAN 
		  Distance  Connection Server (see Section 6).  If you 
		  set it to 'Yes', all frames will be  copied  to  the 
		  bound  protocol.  If you set it 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  setting  for 
		  this parameter is 'No'.


FMPFile:         <DOS Only>

		  Use  this  parameter  to  specify  the full path and 
		  filename  of  the  driver's  binary  file.  An 
		  example is:
		  
                     'FMPFile = C:\LSP\MCBND30.BIN'
             
		  If  you  do  not set this parameter is not supplied, 
		  the driver  will  assume  that  the  file  is  named 
		  'MCBND30.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'. 
		  This  is  because  some  older protocols require the 
		  driver to transmit every 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,  you  must  set  the  parameter  as 
		  follows:

                     'TXSlots = 32'.

		  For  most situations, we recommend a value of 16 for 
		  OS/2  and  18  for  DOS.   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 increase the value 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, increasing the RX slots it will also  cause 
		  the driver to consume more DOS memory.  To use 16 RX 
		  Slots, set the the parameter as follows:

                     'RXSlots = 16'.

		  The recommended value of 4 should be sufficient  for 
		  most  environments.   If you do not need to save DOS 
		  memory, 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.  To use 2 RX  Buffers,  set 
		  the parameter as follow:

                     '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 gets 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   therefore   better 
		  performance. The minimum value is zero.

		  However, on computers with slow buses, if the  value 
		  is  small,  the  transmission  of the frame onto the 
		  ring may take place faster than the transfer of data 
		  onto the adapter.  In this situation, the  frame  is 
		  aborted on the ring, and re-transmitted immediately.  
		  This entails a heavy reduction in performance.

		  If  no  value  is  specified for this parameter, the 
		  driver will assume a value of 3.


MaxRequests:     <DOS & OS2>

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

		  The recommended value for this parameter is  6  (the 
		  default).   It  is  not  normally necessary to alter 
		  this value.  Note that the driver will not  be  able 
		  to  carry out most General Requests if this value is 
		  set to 0; a sensible minimum for this  parameter  is 
		  1.
	
		  Example:
		  
		  	MaxRequests = 1


8) Troubleshooting
------------------

8.1) Diagnosing Errors
----------------------

MCBND.DOS  and  MCBND.OS2  display and log driver messages.  There are 
three types of messages: information,  warning,  and  error  messages.  
Information  messages  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 MCBND error messages can be 
found in ERRORS.TXT.


8.1.1) Displaying Errors on Screen
----------------------------------

The  driver  can  only  display  messages  on the screen when it first 
loads.  If the 'InitOnLoad' parameter is set to 'Yes', the driver  can 
display  errors  that  occur  while  it  is initializing the adapters. 
Otherwise it only finds these errors at bind-time when  it  no  longer 
has the ability to write to the screen.  

If you think there is a problem with the MCBND driver, it  is  a  good 
idea  to  set 'InitOnLoad = Yes', and then to examine the errors.  You 
will probably be able to fix most of the errors by altering the system 
configuration.  If there are any that you cannot  fix,  contact  Madge 
Technical Support.

Setting 'InitOnLoad = Yes' also displays the  configuration  for  each 
adapter  in  use  by  MCBND.   This information can also be useful for 
finding errors such as ring speed mismatches. It also enables  you  to 
check  that  there  are  no hardware conflicts between the adapter and 
other devices.

Sometimes,  during the system boot, the adapter is unable to open onto 
the ring.  This is because, in general, the open request is issued  by 
the  protocol  in  its  own  time,  and the Madge driver does not have 
control of the screen in order to display  errors.   One  solution  to 
this  problem is to set 'AutoOpen = Yes' as well as 'InitOnLoad = Yes' 
for each adapter.  This forces the driver to initialize and open  each 
adapter  while  it  is  still  in  control of the screen. It therefore 
enables the driver to display any errors that occur when  the  adapter 
opens.

However, setting 'InitOnLoad = Yes' and 'AutoOpen = Yes' is not always 
appropriate.   Some  environments  require  the  adapter  not  to   be 
initialized  until  bind-time. Also, some protocols need to be able to 
control the opening  of  the  adapter  themselves.   In  these  cases, 
setting  'InitOnLoad  =  Yes'  and  'AutoOpen  =  Yes'  is a temporary 
arrangement for investigating a potential MCBND problem.

If  the  driver  does not find an appropriate adapter for a particular 
MCBND PROTOCOL.INI section, and 'HotSwap' is set to 'Yes', the  driver 
will  still register that module with the Protocol Manager; it will do 
this in anticipation of a Madge 16/4 CardBus  Adapter  being  inserted 
later.   However,  this  behaviour  will hide from you any errors that 
occur when the driver is trying to find  adapters  that  are  in  fact 
present.   When  you  are  investigating  problems  that the driver is 
having locating adapters, therefore, it might be  appropriate  to  set 
'HotSwap = No' (especially for MCBND.OS2 where this is not the default 
setting) in all MCBND sections of PROTOCOL.INI.


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

IBM's  OS/2  LAN  Adapter and Protocol Support (LAPS) provides the IBM 
LAN Systems OS/2 Messaging service.  MCBND.OS2 uses  this  service  to 
log  messages  in the LAN message log file. This is generally the file 
C:\IBMCOM\LANTRAN.LOG.   The  messages  to  be  logged  are  held   in 
MCBND.OS2's  message  file  MND.MSG, which is generally located in the 
C:\IBMCOM directory (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 access to the screen.  
Therefore, under OS/2, you can  view  the  adapter  details  /  errors 
without  having  to  set  'InitOnLoad  =  Yes'.   Also, messages about 
adapter-opening errors can be <<HOW>> logged (taking away the need for 
you to set 'AutoOpen = Yes' merely to see these errors),  and  so  can 
messages about 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. This means that it is best not  to  rely 
on all errors appearing in this way.

It  is  possible  for  the versions of MCBND.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, 
or  (b)  the located MND.MSG file is too old, or (c) too new.  In each 
of these cases, the driver will not log any messages to LANTRAN.LOG.


8.2) Upgrading MND.MSG
----------------------

As described in section (8.1.2), the version of MND.MSG should reflect 
the  version  of  MCBND.OS2  in use.  Mismatches of versions can occur 
during MCBND upgrades.

If a previous MDGND / MCBND driver 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.  You can do this by editing the 
       file with E.EXE, but not with TEDIT.EXE.  If you do not do  it, 
       the  IBMLANLK.SYS  device  driver  will  crash 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.   You  can  do this by editing the file 
       with E.EXE, but not with TEDIT.EXE.  If you do not do it,  then 
       the  IBMLANLK.SYS  device  driver  will  crash 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.  


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

A problem has been found with the bridging protocol that is  bound  to 
the MCBND.OS2 driver in a LAN Distance Connection Server.  The problem 
shows  itself  in very slow performance for the copying of large files 
from the LAN to the server or from  the  LAN  to  a  remotely-attached 
workstation.

The problem hass to do  with  the  bridging  protocol  exhausting  LAN 
transmit  resources  while  receiving a large burst of frames from the 
LAN.  When these resources are freed, the bridging protocol  does  not 
transmit  the  frames that it could not transmit earlier. These frames 
therefore  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.

The best workaround for this is to set the 'CopyAllData' parameter  to 
'Yes' in the MCBND PROTOCOL.INI section. This has the effect of making 
MCBND  complete  all transmit requests for small frames synchronously; 
most of the bridging protocol's transmit resources can then be re-used 
immediately.

If you follow the installation procedure in  Section  6  (above),  the 
'CopyAllData = Yes' setting is added to PROTOCOL.INI by default.


8.4) Using MCBND.DOS with Host Connectivity Products
----------------------------------------------------

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

IBM's  PC/3270  requires a DLC interface to enable it to use the 802.2 
protocol. To provide this, you can use a DLC NDIS protocol stack  (for 
example, IBM's DXME0MOD.SYS driver) running over MCBND.DOS.  There are 
a few points to bear in mind when setting up such an environment.

a) 

     The adapter might need  to  use  a  locally-administered  address 
     (LAA).   To set an LAA, use the 'NodeAddress' parameter, or force 
     the 802.2 protocol stack to set the address. If you want to do 
     the latter, load DXME0MOD.SYS by using a CONFIG.SYS line similar 
     to the following:

           DEVICE=C:\LSP\DXME0MOD.SYS 400012345678

     If you are using the 802.2 protocol stack to set  the  LAA,  then 
     the  protocol  that  does it must be the one that first opens the 
     adapter.  You must not set the MCBND parameter 'AutoOpen =  Yes', 
     and  no  other  protocol  bound to MCBND must attempt to open the 
     adapter.  
     
     A  problem  will  occur  if  you  are  using  DXME0MOD.SYS   with 
     DXMJ0MOD.SYS  to provide both an 802.2 and NETBEUI interface over 
     NDIS.  DXMJ0MOD.SYS will  automatically  open  the  adapter  when 
     NETBIND.EXE  runs,  and it will not use the address specified for 
     DXME0MOD.SYS.  The solution is to use DXMT0MOD.SYS (NETBEUI  over 
     802.2)   instead   of   DXMJ0MOD.SYS,   and  to  make  sure  that 
     DXMT0MOD.SYS does not open  the  adapter.  Load  DXMT0MOD.SYS  by 
     using a line in CONFIG.SYS such as:

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

     Also, make sure that the PC/3270 application  starts  before  NET 
     START  runs (in other words, before any thing attempts to use the 
     NETBEUI interface.

b)   Set  the  MCBND  'MaxFrameSize' parameter 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,  set  the 'MaxFrameSize' parameter to at least 
     2042.

c)   If you set the 'MaxFrameSize' parameter to  a  large  value,  you 
     might  need  to  increase the amount of 'work space' available to 
     the 802.2 protocol stack.  For example,  if  you  are  using  the 
     MCBND  driver  with  the  IBM  LAN  Support  Program and you have 
     configured the driver with 'MaxFrameSize = 2560', then  load  the 
     802.2 stack with a line such as:

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

     This increases the amount of work space available to DXME0MOD.SYS 
     from the default of 8KB to 16KB.


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

If you detach the cable from a  Madge  16/4  CardBus  Adapter  running 
MCBND  after  the  adapter  has  opened  onto  the  ring, and you then 
re-attach it, the adapter will not necessarily re-open onto the  ring.  
Whether  it  does  or  not  will depend on the length of time that the 
cable was detached for, the setting of the MCBND parameters,  and  the 
particular protocol that is bound to MCBND.

By default, it is the responsibilty of the bound protocol  to  recover 
from  a  cable disconnection.  If the cable is only disconnected for a 
few seconds, the firmware 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 a 'Lobe Fault'.  The protocol 
will then attempt periodically to re-open the adapter itself until  it 
succeeds.   However,  some protocols (especially DOS protocols) do not 
attempt to re-open the adapter in this situation; instead, they assume 
a fatal error has occured with the MAC driver (MCBND)  and  they  fail 
all  subsequent  requests  from  the  higher  levels (for example, the 
network redirector) in the system.

If 'AutoOpen = Yes' is set in MCBND's PROTOCOL.INI section, MCBND will 
attempt to re-open the adapter itself.  However, by default MCBND will 
still  inform  the protocol of a 'Lobe Fault'. Therefore, although the 
adapter will now re-open  when  the  cable  is  re-attached,  a  bound 
protocol  might  choose not to re-use the adapterd.  The best solution 
is for the driver not to inform the protocol of the 'Lobe  Fault'.  To 
configure  the driver not to inform the protocol of a 'Lobe Fault' set 
the MCBND parameter 'RStatusReport = 0xF7FF'.  Note that  setting  the 
'RStatusReport'  parameter  in  this  way  will  result  in fewer ring 
statuses being reported to any bound management  protocol.

In conclusion, most  OS/2  protocols  (including  IBM's  OS/2  NETBIOS 
protocol  that is supplied with LAPS and MPTS) will recover from cable 
disconnections.  Most  DOS  protocols  (including  IBM's  DOS  NETBIOS 
protocol  that  is supplied with DLS) will not recover if the cable hs 
been disconnected for more than 5 - 10 seconds. If you need to  remove 
the  card for more than 5 - 10 seconds under DOS, add the following to 
the MCBND_nif section in PROTOCOL.INI:

    AutoOpen = Yes
    RStatusReport = 0xF7FF

These parameters are not applied by default to MCBND.DOS because  some 
protocols need to be able to open the adapter themselves.  Microsoft's 
TCP/IP  protocol  stack, supplied with the DOS LAN Manager workstation 
software, is an example).


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

Hot Swapping and APM support are implemented in in the driver software 
in the same way  as  support  for  cable  disconnection  /  insertion. 
Therefore  the  requirement  on  the  protocol  to  recover from cable 
disconnection applies equally in the context of Hot Swapping and  APM.  

Under  OS/2 you do not generally need to set any parameters to support 
Hot Swapping or APM. But with DOS, you will generally need to  include 
the following PROTOCOL.INI parameters:

    AutoOpen = Yes
    RStatusReport = 0xF7FF

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


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

IBM's ODI2NDI.OS2 protocol stack provides an ODI interface over  NDIS. 
It  enables  you  to  run  Netware  Requester running over an NDIS MAC 
driver.

ODI2NDI.OS2 causes the system to Trap D when the 'Lobe  Fault'  status 
is  reported  by  MCBND.  Because of this, we recommend you to add the 
following lines to the MCBND PROTOCOL.INI section if you  require  APM 
or Hot Swapping:

    AutoOpen = Yes
    RStatusReport = 0xF7FF


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

When  ODI2NDI.OS2 loads from CONFIG.SYS, it needs to be able to obtain 
the node  address  that  the  adapter  is  using.   In  general,  this 
information is not available from the adapter because the adapter will 
not  have  been initialized when ODI2NDI needs the address.  There are 
three main ways to solve this problem:

a)   You put the address that the adapter will use  into  the  ODI2NDI 
     section  of  PROTOCOL.INI.   To  do  this,  use  the 'NetAddress' 
     parameter.  If  the  address  is  an  LAA  (Locally  Administered 
     Address),  ODI2NDI  attempts  to  open the adapter with this node 
     address as long as you have  not  set  the  MCBNC  'AutoOpen=Yes' 
     parameter.   
     
     This is the best solution, but it does of course require  you  to 
     establish  the address that the adapter is going to use (normally 
     its BIA), and then to configure ODI2NDI with that value by  using 
     LAPS / MPTS.

     When  you  are  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)   You  can specify the address explicitly in the MCBND PROTOCOL.INI 
     section either by using the 'BIA' parameter or the  'NodeAddress' 
     parameter.   Again,  this  requires  you  to type the appropriate 
     value into PROTOCOL.INI yourself.  This method also requires  you 
     to load MCBND.OS2 earlier than ODI2NDI.OS2. Otherwise, of course, 
     ODI2NDI.OS2 will not be able to find the address.  

c)   You  can  configure  the MCBND.OS2 'InitOnLoad=Yes' parameter and 
     then  load  MCBND.OS2  before  ODI2NDI.OS2.   Note  however  that 
     'InitOnLoad  = Yes' is a parameter that is not strictly compliant 
     with the NDIS specification, and it will will cause  problems  if 
     you are remote booting.

Whichever of the above alternatives you use, make sure that you load:

i)  PROTMAN.OS2 before any network drivers.

ii) LSL.SYS before ODI2NDI.OS2.

ii) ODI2NDI.OS2 before IPX.SYS.

We  recommend you to put the 'NETWARE REQUESTER STATEMENTS' at the end 
of CONFIG.SYS.  Make sure that you use ODI2NDI.OS2 instead of the  ODI 
MAC driver (such as NTR2000.SYS), and that you load ROUTE.SYS.


8.7) Using MCBND.OS2 with Eicon 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 utility  allows  you  to  configure  HP  printers 
across a LAN.

Both of these products use a special part of  the  NDIS  specification 
for communicating over a source-routing bridge.  They both require the 
MAC  driver  to  return the 'AddressRecognized' and 'FrameCopied' bits 
correctly from the Token-Ring frame when the driver receives the frame 
after transmitting it.  This requirement reduces performance,  and  is 
not implemented by default in MCBND. Instead, a special parameter must 
be  set  to  allow  these protocols to communicate with their intended 
hosts on the other side of a source-routing bridge.

Setting  'ReturnStatus  = Yes' will forces the 'AddressRecognized' and 
'FrameCopied'  bits  to  be  returned  to  the  bound  protocol.   The 
parameter  replaces  the 'HostAddress' and 'PrinterAddress' parameters 
that are available in the earlier Madge NDIS MAC drivers,  SMARTND.DOS 
and  SMARTND.OS2.   MCBND.DOS  and  MCBND.OS2  recognize these two old 
parameters, and they replace them  by  setting  'ReturnStatus  =  Yes' 
automatically.


8.8) Using MCBND.DOS with LAN Manager v2.0 and MCBND.OS2 with Banyan
--------------------------------------------------------------------
Vines Workstation
-----------------

The protocols supplied with Microsoft LAN Manager v2.0 DOS workstation 
and Banyan Vines OS/2 workstation depart from the  NDIS  specification 
by  not  putting the source address into the Token-Ring header of each 
frame they pass to the NDIS MAC driver.

You can force MCBND to fill in these addresses itself. To do  so,  set 
the  'ForceAddress'  parameter  to 'Yes'.  Note, however, that setting 
this parameter to 'Yes' will stop certain protocols  from  working  if 
they need to transmit frames that have a source address other than the 
open   address.    (For   example,  protocols  acting  as  part  of  a 
source-routing bridge.)

SMARTND.DOS and SMARTND.OS2 both used to fill in  the  source  address 
for  every  frame  they transmitted. MCBND.DOS and MCBND.OS2 do not do 
this.


8.9) Making the Adapter Secure for Use by MCBND.DOS
---------------------------------------------------

<<Note: Although the MCBND.OS2 driver would support promisuous receive 
mode, the CardBus Adapter does not.>>


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 MCBND.DOS,
it must first be made 'secure'.

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


8.10) Hot-Swapping and APM support with MADGECS
-----------------------------------------------

You can use MADGECS.EXE (for DOS) or MADGECS.SYS (for OS/2) to provide 
Card and Socket Services for the Madge 16/4 CardBus Adapter.

Versions of MADGECS prior to that supplied  with  CSS  1.0(0)  do  not 
support CardBus controllers.

                    ****** End of MCBND.TXT ******                    
