[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

453.0. "DECmcc BMS V1.0 SSB Feedback - Comments?" by TAZBOY::ZIGLER (Tom Zigler, DTN 432-7541) Fri Nov 02 1990 20:26

Here are some personal observations regarding the use of the DECmcc BMS
V1.0 software:

1) DECelms V1.0 and DECmcc BMS V1.0 do NOT interoperate well.  For example, if I
enable background alarm polling from both DECelms V1.0 and DECmcc BMS V1.0 from
the same VAXstation, then we receive spurious "cannot communicate with target"
BMS alarm messages.  Also, if I disable DECelms background alarm
polling but happen to access a DEC LAN Bridge with DECelms at the same time as
DECmcc BMS, then I get another DECmcc BMS spurious alarm message - ugh!

2) The SHOW/SET command syntax lacks consistency across the various global
entity classes after registration.  For example:

	MCC> REGISTER NODE4 .DNA_NODE.FOOBAR SYN FOOBAR
	MCC> REGISTER BRIDGE .MCC_BRIDGE.FOOBAR1 ADDRESS=...
	MCC> REGISTER SNMP FOOBAR2
	MCC> REGISTER STATION .MCC_STATION.FOOBAR3 ADDRESS=...

	MCC> SHOW NODE4 FOOBAR ALL CHAR
	MCC> SHOW SNMP FOOBAR2 INTERFACE 1 ALL CHAR

	MCC> SHOW BRIDGE .MCC_BRIDGE.FOOBAR1 ALL CHAR
	MCC> SHOW STATION .MCC_STATION.FOOBAR3 FUNCTIONS SUPPORTED...

Note that we are able to mask the DECdns directory specifics for the DECnet
Phase IV and SNMP entities, but NOT for either the BRIDGE or STATION entities.

3) The DECmcc BMS documentation falls short in providing guidance in HOW to
structure the DECdns namespace for DECmcc BMS AFTER the automated
DEC_DNS_BASIC_SETUP and DEC_DNS_SETUP command procedures are applied.  For
example, since for SNMP, the documentation requires that one create a .MCC_IP
DECdns directory, then is the reader to INFER(?) that one should create both
.MCC_STATION and .MCC_BRIDGE DECdns directories as well?  These points are not
clear. 

4) The on-line HELP function seems to be modeled after the entity model - a
valid approach but NOT very user friendly.  For example, I would prefer
something along this line:

	MCC> help show bridge ...

5) How much pain will it be to later modify the IDP default when needing to
communicate with other OSI nets?  The documentation is silent on this point.

The purpose of the above observations are to raise these issues to DECmcc
Product Management and the field for feedback and comments.
    
Any takers?  Anyone agree or disagree?

    			\Thanks in Advance
T.RTitleUserPersonal
Name
DateLines
453.1NSSG::R_SPENCENets don't fail me now...Fri Nov 02 1990 20:594
    Is there supposed to be a backtranslation directory for the SNMP stuff
    as well?
    
    s/rob
453.2The bulb lights!CLAUDI::PETERSMon Nov 05 1990 12:392
I agreed absolutely with .0!   If these and other interface problems
aren't fixed DECmcc will fail to be used.  /Claudia
453.3DECelms V1.0/DECmcc BMS V1.0 Alarm EvidenceTAZBOY::ZIGLERTom Zigler, DTN 432-7541Mon Nov 05 1990 15:1439
    Here are the MCC alarm exceptions written to the alarm log file at the
    customer site, seemingly pointing to a DECelms V1.0/DECmcc BMS V1.0
    (SSB) interoperability problem (referenced in (1) in .0).  DECelms
    never failed whenever any of the below MCC alarms fired:
    
****  Exception occurred in rule MCC 0 ALARMS RULE plantfacbroken  at  1-NOV-1990 13:35:08.67  ****

    Rule name:     MCC 0 ALARMS RULE plantfacbroken
  Occurred at:     1-NOV-1990 13:35:08.67
     Category:     Device State Changing
  Description:     Bridge Plantfac Device State Changed
 
   Expression:     (change_of (BRIDGE .MCC_BRIDGE.PLANTFAC device state,*,*), at every = 00:05:00)
    Exception:     Cannot communicate with target
 
 
****  Exception occurred in rule MCC 0 ALARMS RULE 800TOPRMbroken  at  1-NOV-1990 13:55:22.35  ****

    Rule name:     MCC 0 ALARMS RULE 800TOPRMbroken
  Occurred at:     1-NOV-1990 13:55:22.35
     Category:     Device State Changing
  Description:     Bridge 800TOPRM Device State Changed
 
   Expression:     (change_of (BRIDGE .MCC_BRIDGE.800TOPRM device state,*,*), at every = 00:05:00)
    Exception:     The requested operation cannot be completed
                   %MCC-E-PROTOCOLINUSE,  protocol is in use and not available.
 
****  Exception occurred in rule MCC 0 ALARMS RULE EC1TOTCPbroken  at  2-NOV-1990 14:00:28.04  ****

    Rule name:     MCC 0 ALARMS RULE EC1TOTCPbroken
  Occurred at:     2-NOV-1990 14:00:28.04
     Category:     Device State Changing
  Description:     Bridge EC1TOTCP Device State Changed
 
   Expression:     (change_of (BRIDGE .MCC_BRIDGE.EC1TOTCP device state,*,*), at every = 00:05:00)
    Exception:     The requested operation cannot be completed
                   %MCC-E-TRANSMITERROR, error trying to transmit a packet
                   %SYSTEM-F-DEVINACT, device inactive
 
453.4Bridge Errors explained...WLYWLD::BRIENENDECmcc Bridge|Station Management.Mon Nov 05 1990 20:4253
RE: DECelms V1.0 and DECmcc BMS interoperability
------------------------------------------------
We've been in contact with Tom, and here's a summary of what's
been determined thus far:

1. The test that resulted in these errors was run for 26 consecutive
   hours, with 40 bridge rules firing once every five minutes.
   In addition, DECelms was running its POLLER. At this point we
   believe (not totally sure) that default Polling values were taken
   for the test (i.e. DECelms was polling every bridge as fast as
   the system allowed...).

2. A total of 17 DECmcc bridge alarm exceptions were logged during
   this period, distributed as follows:

   A) 10 Protocol-in-Use errors. Eight occurred to the SAME BRIDGE
      consecutively (every 5 minutes) for a 35 minute period starting
      at around 2pm. Note: the customer determined that DECelms
      also generates this type of error running by itself, apparently
      when the BML and POLLER are competing for the same bridge.

   B) 4 Device Inactive errors. Two back-to-back, with all four in a
      15 minute period. We typically see this error when a port device
      is being reset by the driver while being driven hard. We don't
      consider this a big problem.

   C) 3 Cannot Communicate errors. Many possible reasons, one of which
      is a management request dropped by the bridge while trying to
      service another management request at the same time. Since we are
      already doing retries here, there's not much else we can do.


So about the Protocol-in-Use errors
-----------------------------------
 DECmcc's Ethernet Access (MCC_EA) routines return immediately in the
case of external protocol-in-use (or protocol/address-pair in use)
conflicts. Note that the MCC_EA routines coordinate access to the
driver by protocol/address/port-id using locks (i.e. Protocol-in-Use
errors don't occur between parts of DECmcc using MCC_EA routines).

 The DECmcc V1.0 Bridge AM simply returns this MCC_EA error to the caller.


Change for DECmcc V1.1 EFT
--------------------------
 For DECmcc V1.1 EFT, we have modified the Bridge AM to do retries when
receiving a protocol-in-use error from the MCC_EA routines. This should
increase the possibility of actually acquiring the protocol/address-pair
(thus dramatically reducing this problem RE: DECelms).

 We will investigate adding this retry capability to the MCC_EA routines
later (if necessary, by DECmcc V1.1 FCS).

453.5More Test ResultsTAZBOY::ZIGLERTom Zigler, DTN 432-7541Thu Nov 08 1990 14:4829
Here are the results of another recent test at the customer site:

1) Stopped DECelms V1.0 completely

2) Enabled DECmcc BMS V1.0 (SSB) 5 minute polling to 40 DEC LAN Bridges 
which resulted in no bogus DECmcc BMS alarms the entire day.

3) Invoked DECelms, enabled the background poller, and received bogus 
DECmcc BMS alarm exception messages "protocol in use".  Attempted to 
talk to the bridge with DECelms and could not because of "protocol in 
use" conflict.  We then turned off the DECelms background poller.  
(Note: Listener was never running).

4) Disabled the DECmcc BMS alarm rule for that bridge and again 
    attempted to talk to the bridge with DECelms, but could not because of
    "protocol in use" conflict again.

5) Exited DECmcc BMS completely.  Only then could we successfully 
talk to the bridge again with DECelms using SHOW commands.

Therefore, even with DECelms background poller and listener turned OFF,
we seem to have an interoperability problem still with DECelms with just 
    SHOW commands.  My customer is performing a comparison between DECelms
    V1.0 and DECmcc BMS V1.0 to evaluate the possibility of NOT using
    DECelms to talk to the DEC LAN Bridge 100, 150, and 200s.

    Comments?  Please advise.
    
    			\Thanks in Advance