[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

3897.0. "Alarm on fddi-station entity" by PRSSOS::BONNAFE (Guy BONNAFE - CSC France) Tue Oct 13 1992 14:55

DECmcc/Ultrix V1.2 
ELM package

The MCC command :
	MCC>show fddi-station test_fddi SIF CONFIGURATION phy port conf , -
	_MCC>in domain = fddi_ring_map
displays the following result :

FDDI-Station KBANON_NS:.test_fddi SIF CONFIGURATION
AT 13-OCT-1992 18:44:01 Characteristics

                 Phy Port Configuration = ( (
                        Port Resource Index = 1,
                  Connection Resource Index = 2,
                                  Port Type = Slave,
                           Remote Port Type = Master,
                                 Port State = Active,
                                 Remote MAC = False ) )

Is there a way to display only one of the individual characteristics, say
'Port State' ?? I can't find the right syntax.
By checking the DECmcc dictionary, I've found that 'Phy Port Configuration' is
the attribute of a specific type ( CONSTRUCTOR_DATA_TYPE ) : 'Port State' is
only a definition of this type, a kind of field in a record. 

The goal is of course to define an alarm on one of the characteristics,
tipically the 'Port State'.

Regards,
Guy.

T.R	Title	User	Personal Name	Date	Lines
3897.1		SLINK::CHILDS	Ed Childs	`Wed Oct 14 1992 11:53`	18
	\| Is there a way to display only one of the individual characteristics, say \| 'Port State' ?? No, there isn't. \| The goal is of course to define an alarm on one of the characteristics, \| tipically the 'Port State'. With the bridge and concentrator Device Configuration attribute, which is also a record, we added an attribute called Device Configuration Error Condition. An alarm can be set on that new attribute, and then the alarm message can instruct the network manager to check Device Configuration for the actual error. Is Port State the only thing you would like to set an alarm on? If you can make a list of all the alarm conditions you would like to see for the FDDI record structures, we might be able to add some new synthesized attributes to set alarms on.
3897.2		SLINK::CHILDS	Ed Childs	`Fri Oct 16 1992 10:44`	15
	\| With the bridge and concentrator Device Configuration attribute, which \| is also a record, we added an attribute called Device Configuration \| Error Condition. An alarm can be set on that new attribute, and then \| the alarm message can instruct the network manager to check Device \| Configuration for the actual error. This is clearly a wicked bad kludge we had to do in order to get around an obvious shortcoming of MCC. The Alarms FM should find a way to address fields within a record. That might mean that the PMs need attention to fix this problem, so you can Show a specific field within a record. It's gross that the AMs need to be hacked like this to get around the problem.
3897.3	Alarm on fddi-station entity	PRSSOS::BONNAFE	Guy BONNAFE - CSC France	`Fri Oct 16 1992 15:55`	23
	Ed, Let me try to summarize my thoughs : Concerning DEC equipments, the following command : MCC>show bridge <bridge_name> phy port 1a Phy Port State allows me to test the attribute 'Phy Port State' which can be used to set an alarm. For non-DEC equipments, if we don't have the same level of information via the fddi-station AM, we are forced to use the SNMP AM and test an attribute named 'snmpFddiPortConnectState' which can also be used for the alarm. With the next version of firmware for both bridges and concentrators, the SNMP attribute 'snmpFddiPortConnectState' will be implemented because the standard FDDI MIB will be used, replacing the experimental one. Allowing me to manage all my fddi equipments in the same way : snmp instead of elm. That's why I think that we need a way to set alarms on attributes from the fddi-station entity. And I agree with you : we have to do this through an access to individual fields in the records, not by defining 'glogal' attributes. Guy.