Conference azur::mcc

I cannot address the Bridge & concentrator partial registration problems,
but I'll try to help with the Terminal server registration problem.

If the terminal servers you are trying to register are reachable
using TSM from the *same* node as you are running DECmcc/TSAM, then that
points to your needing to include the maintenance password in the
registration command.  It sounds like you are not using the default
maint password on these terminal servers. (If the key is not specified
during registration, TSAM uses the default key.)

Register them again (no need to deregister) as follows:

MCC> MCC> reg term .ts.tsm200 addr=08-00-2B-06-B8-73, -
_MCC> type=ds200, -
_MCC> MAINTENANCE KEY=%X0000000000000001

If you are also using non-default login passwords, you must also include
that in the registration command as LOGIN KEY.

-Dave

| In trying
| to register a DECbridge 620 and a DECconcentrator, I get
| only partial registration due to "Management protocol
| error".

    Can you try these commands and post the results:

    MCC> test bridge <bridge-address>
    MCC> test conc <concentrator-address>
    MCC> show mcc 0 bridge_am all attributes

    Thanks.

    /* Ed */

    The problem was that there was a XQA0: and an ESA0: on the VAX 3300
    DECmcc system.  The line for the XQA0: was off and purged from the
    network database but TSAM was trying to use it to comm with the
    DECserver.   And it appears that TSAM does not support the via port
    qaulifier as we were getting something like "qualifier not supported"
    when we set up the default qualifier.  We physically disconnected the 
    XQA0 and the problem was solved.
    
    Via port worked for the bridges and concentrators but there is still
    the problem of alarm polling not supporting the via port qualifier.
    
    What do we do with a muti-Ethernet adapter DECmcc station that needs to
    communicate with DECservers over one adapter and other devices over
    another?  You need to use via port to get the full functionality but 
    some of the functions don't support the via port qualifier.
    
    This will be a potential problem with the VAXc Multi-Datacenter
    Facility (MDF) as we integrate DECmcc into the management station for
    management of the DECconcentrators/bridges and DECservers.  
    
    Bill

RE: .3

>    ...XQA0: and an ESA0: on the VAX 3300
>
>    Via port worked for the bridges and concentrators but there is still
>    the problem of alarm polling not supporting the via port qualifier.
>    
>    What do we do with a muti-Ethernet adapter DECmcc station...

Something's wrong here...

The MCC_EA (Ethernet Access) Routines, used by Bridge|Conc|Ethernet AMs,
do automatic retry and will "walk through" available ethernet ports.
We have a VAX 8250 (with both a UNIBUS and BI ethernet controller)
which does this "just fine".

Did anyone try the SHOW MCC 0 BRIDGE_AM AVALABLE PORTS command to see
whether xqa0 and eta0 were found on startup?

Did a bridge command using VIA PORT XQA0: result in some sort of hard
error (other than a simple timeout) ?

Did a TEST STATION xxx command work to the bridge or conc without the
VIA PORT qualifier?  If not, what message was returned? (If yes, then
the Bridge AM and Conc AM might have a problem).

						Chris

re: .4
    
   >  Did anyone try the SHOW MCC 0 BRIDGE_AM AVALABLE PORTS command to see
   > whether xqa0 and eta0 were found on startup?
   >      
	Both ports were displayed when only one of them was configured in the
	network database.

   > Did a bridge command using VIA PORT XQA0: result in some sort of hard
   > error (other than a simple timeout) ?
   >      
	I didn't try specifying the XQA0: but that's the one that appeared
	first in a SHOW MCC 0 BRIDGE_AM AVALABLE PORTS command and a
        SHOW BRIDGE address  returned a "Management protocol error".
 
   > Did a TEST STATION xxx command work to the bridge or conc without the
   > VIA PORT qualifier?  If not, what message was returned? (If yes, then
   > the Bridge AM and Conc AM might have a problem).
   >      
	Didn't try it.

   	Bill
                                                                    
    

RE: .5

>   >  Did anyone try the SHOW MCC 0 BRIDGE_AM AVALABLE PORTS command to see
>   > whether xqa0 and eta0 were found on startup?
>   >      
>	Both ports were displayed when only one of them was configured in the
>	network database.

  The MCC_EA routines DON'T CARE whether the network database knows about
a device, it uses other means to determine the available ethernet devices...


>   > Did a bridge command using VIA PORT XQA0: result in some sort of hard
>   > error (other than a simple timeout) ?
>   >      
>	I didn't try specifying the XQA0: but that's the one that appeared
>	first in a SHOW MCC 0 BRIDGE_AM AVALABLE PORTS command and a
>        SHOW BRIDGE address  returned a "Management protocol error".

  The ethernet ports are tried by default in the order they're listed by
the AVAILABLE PORTS attribute.

  My guess is that the BRIDGE_AM is mapping a channel or $QIO failure returned
by the Device->Driver->MCC_EA routines as a "Management Protocol Error".
Can you try the ETHERNET_AM (Station) to see if the same error occurs?

 The MCC_EA stops when it hits an error that it considers "fatal". If the XQA 
is attached to a real LAN (not even running DECnet) and functioning this
problem shouldn't occur.

 Is the QNA attached to a LAN / operating correctly?

 Is it a requirement of VAXc MDF to have unused ethernet ports on the
host system?

						Chris

   

  

   >      
   > Can you try the ETHERNET_AM (Station) to see if the same error occurs?
   >      
	I disconnected the adapter so I'll have to try and give this a shot 
	later in the week.
 
   >  The MCC_EA stops when it hits an error that it considers "fatal". If the XQA 
   > is attached to a real LAN (not even running DECnet) and functioning this
   > problem shouldn't occur.
   >      
   >  Is the QNA attached to a LAN / operating correctly?

	The QNA was not attached.

   >      
   >  Is it a requirement of VAXc MDF to have unused ethernet ports on the
   > host system?
   >      
	No.  My main concern is what does one do if the management station has
	multiple adapters, the managed entities are not accessable through
	all the adapters and some of the mcc functionality doesn't support the
	via port qualifier.  

	Bill