You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(19) |
Sep
(29) |
Oct
(32) |
Nov
(8) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(24) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(2) |
Jul
(2) |
Aug
(38) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2006-07-04 13:41:26
|
HPI SNMP item #1516970, was opened at 2006-07-04 13:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=680471&aid=1516970&group_id=71730 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: latha_nb (latha_nb) Assigned to: Nobody/Anonymous (nobody) Summary: problem with snmp subagent Initial Comment: Hi, I have three queries regarding the openHPI-subagent operation 1.My snmp agent is unable to find the object identifer for hpiD 2.HPI.mib refers to another MIB file SAF-TC-MIB which is not available handy with openhpi-snmp package 3.MY snmp sub agent gets killed after some time it is been started successfully. It would be great if somebody can give some pointers on these issues. Regards, Latha. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=680471&aid=1516970&group_id=71730 |
From: Swortwood Bill-G. <bil...@mo...> - 2005-12-16 23:13:07
|
For those looking for the latest toys .... _____ From: Steve Jerman (stjerman) [mailto:stj...@ci...] Sent: Friday, December 16, 2005 4:09 PM To: Scott Baker; Nathan Sowatskey (nsowatsk); cg...@ec...; Todd Guay; nek...@bt...; tec...@dm...; Malhotra, Sumeet S; kie...@de...; ale...@ha...; Stephen Gaito; Hiro Kishimoto; Fred Maciel; Andreas Maier; Wettling, Fred; tr...@nc...; ba...@ca...; Way...@te...; Chr...@te...; dc...@in...; John Robert Scales (jscales); dav...@bt...; col...@bt...; chr...@bt...; kev...@bt...; mur...@bt...; ste...@bt...; pra...@rd...; Krueger, Marjorie (StorageWorks); Duggan, Jerry P; Daggett, Jeremy; GARG Sukesh RD-ILAB-SSF; Fratini, Stephen; Winston_Bumpus@Dell.com; Francesco Caruso; Heather Kreger; Paul.Vonbehren@Sun.COM; Roger Reich Cc: Chad Brandon; cimbit(mailer list) Subject: [technical] Model Wizard Open Source & Binary Availability Announcement Hi Folks, You are getting this message since you have at one point or other expressed interest in Model Wizard. The Model Wizard open source project is now open for business! It provides a model independent infrastructure for easing developer access to large information models, using a concept called 'blueprints' (using OMG terminology but which the DMTF calls 'profiles'). It also has an 'exporter' function that can be used to export generated artifacts or integrate with more sophisticated tools such as AndroMDA (http://www.andromda.org <http://www.andromda.org/> ). The home page is here: http://modelwizard.sourceforge.net/ <http://modelwizard.sourceforge.net/> The Source Forge project is here: https://sourceforge.net/projects/modelwizard <https://sourceforge.net/projects/modelwizard> Source access: via CVS (see project page) Binary access: see the installation instructions on the home page. Model Wizard also installs on-line documentation into Eclipse's help system (help ... help contents). If you are interested in contributing to the project, that would be great. From what I can see the following might be worth working on: 1) Support for other models (the source includes support for Cisco's UML2 based model and CIM V2). 2) Transformation outputs for other models (the only transformation outputs are for the UML2 model). 3) Improvements to the base Model Wizard code. .... :-) lots are needed. 4) Automated build. Also, I do need to work on build and developer documentation. I guess at present I will need to walk through setup with you. I will document the use of AndroMDA with Model Wizard fairly soon to allow someone a chance of writing an equivalent for the CIM or other models. I've no experience running an open source community, so I'm going to have to make this up as I go along. For now, if you want to join the community, you should subscribe to mod...@li... <mailto:mod...@li...> and/or join the project from the project page. I will arrange a teleconference in February to coordinate development efforts. I will announce details of this to the modelwizard-developers email list. Steve Jerman stj...@ci... Cisco Systems |
From: Swortwood Bill-G. <bil...@mo...> - 2005-10-28 16:42:41
|
_____ From: Gar...@ra... [mailto:Gar...@ra...] Sent: Thursday, October 27, 2005 10:09 PM To: Swortwood Bill-G3666C Cc: Rah...@ra... Subject: Comments on HPI-MIB from August 18, 2005 Bill, Thanks for responding to my voicemail message, and for talking with me today. Per our conversation, I am sending you the comments that I have, based on my review of the August 18, 2005 draft revision of the HPI-MIB that I had received a while back from Rahul. I tried to find the links to the current revision of the HPI-MIB, but I saw one that had only minor differences from that revision at the following URL: http://cvs.sourceforge.net/viewcvs.py/openhpi/openhpi-subagent/mib/hpi-mib.mib?rev=HEAD If you could point me to where I can find the latest revision and/or send me the latest revision, I would be happy to take a look at it as well. Thanks in advance for taking the time to review my comments. I should note, first, that it is clear that a lot of good, hard work went into the creation of the HPI-MIB module, and that it looks like it models the HPI spec very well (based on my limited understanding of HPI). I would hope that you can help the OpenHPI group see that cleaning up the remaining issues (many of which are not caught by MIB compilers, even the "anal-retentive" ones) could only help ensure that it will be accepted in a multi-vendor environment that is still based on SMIv2 and SNMPv1/SNMPv2c/SNMPv3. Thanks. Best regards, Gary Gary Hanson RadiSys Corporation desk: 503-615-1547 cell: 503-680-1452 Summary The HPI-MIB module has been created to provide a means to access the HPI API using SNMP, via a set of objects and notifications specified in SMIv2. As such, it seems reasonable to expect the HPI-MIB module to conform not only to the HPI specification but also to the standards for SNMP and SMIv2 as defined by the IETF. However, this is not the case with the draft HPI-MIB published on August 18, 2005. The HPI-MIB violates several basic SMIv2 rules for defining objects and notifications. It also fails to follow some basic conventions normally followed by SMIv2 MIB modules. Finally, it appears to promote SNMP agent behaviors that are at odds with rules for processing SNMP messages. I realize that the OpenHPI group is not an IETF working group, and is not pursuing the development of the HPI-MIB as an IETF standard. However, given that the HPI-MIB is obviously intended to be widely used as a standard MIB module by multiple vendors of computing and networking equipment, it is my hope that the OpenHPI group will correct these violations in order to achieve compliance with the IETF standards. Fortunately, the changes necessary to bring the MIB module into compliance are not difficult, and any resulting changes to prototype SNMP agent software would likely be very localized. I'll enumerate the issues, along with proposed corrections. Be aware that changing a MIB module after it is "released" for generate usage is not a good idea, so I encourage you to make the fixes before releasing it. If the OpenHPI group would like help editing the HPI-MIB to bring it into compliance before it is released, please let me know, and I would be happy to help. SMIv2 violations in HPI-MIB module 1a. A SYNTAX of Counter32 is used for objects representing gauge-like semantics (thus violating section 7.1.6 of RFC 2578). Change the following objects to use a SYNTAX of Gauge32: * saHpiDomainInfoEntryCount * saHpiDomainReferenceEntryCount * saHpiDomainAlarmEntryCount * saHpiResourceEntryCount * saHpiHotSwapEntryCount * saHpiEventEntryCount * saHpiResourceEventEntryCount * saHpiDomainEventEntryCount * saHpiSensorEventEntryCount * saHpiSensorEnableChangeEventEntryCount * saHpiHotSwapEventEntryCount * saHpiWatchdogEventEntryCount * saHpiSoftwareEventEntryCount * saHpiOEMEventEntryCount * saHpiUserEventEntryCount * saHpiAnnouncementEntryCount * saHpiResourceEventLogEntryCount * saHpiDomainEventLogEntryCount * saHpiSensorEventLogEntryCount * saHpiSensorEnableChangeEventLogEntryCount * saHpiHotSwapEventLogEntryCount * saHpiWatchdogEventLogEntryCount * saHpiSoftwareEventLogEntryCount * saHpiOEMEventLogEntryCount * saHpiUserEventLogEntryCount * saHpiRdrEntryCount * saHpiCtrlDigitalEntryCount * saHpiCtrlDiscreteEntryCount * saHpiCtrlAnalogEntryCount * saHpiCtrlStreamEntryCount * saHpiCtrlTextEntryCount * saHpiCtrlOemEntryCount * saHpiSensorEntryCount * saHpiInventoryEntryCount * saHpiAreaEntryCount * saHpiFieldEntryCount * saHpiWatchdogEntryCount * saHpiAnnunciatorEntryCount 1b. Here's an additional related suggestion that may help. Renaming the above objects as "<table descriptor prefix>ActiveEntries" instead of "<table descriptor prefix>EntryCount" as they are changed from Counter32 to Gauge32 would not only help clarify the meaning of these objects, but would also help ensure that all pieces of code that use the incorrect BER encoding will be found and fixed. (The term "active entries" is already used in the DESCRIPTION of saHpiEventLogInfoEntries.) Doing this would also avoid embedding the term "Count" in the descriptor, to avoid further confusion between counters and gauges. 2. Another set of objects indicates the total number of objects registered in each table over the lifetime of the given table. These objects use the SYNTAX of Counter32, as is proper. However, the descriptors chosen for these objects do not follow the normal convention of picking a name for the thing being counted and adding an "s" to denote plurality (as per section 3.1 of RFC 2578). If the following objects were re-named as "<table descriptor prefix>LifetimeEntries" instead of "<table descriptor prefix>EntryCountTotal" the descriptors would follow this convention. In addition, their semantics would be also be better implied by their descriptor: * saHpiEventEntryCountTotal * saHpiResourceEventEntryCountTotal * saHpiDomainEventEntryCountTotal * saHpiSensorEventEntryCountTotal * saHpiSensorEnableChangeEventEntryCountTotal * saHpiHotSwapEventEntryCountTotal * saHpiWatchdogEventEntryCountTotal * saHpiSoftwareEventEntryCountTotal * saHpiOEMEventEntryCountTotal * saHpiUserEventEntryCountTotal * saHpiResourceEventLogEntryCountTotal * saHpiDomainEventLogEntryCountTotal * saHpiSensorEventLogEntryCountTotal * saHpiSensorEnableChangeEventLogEntryCountTotal * saHpiHotSwapEventLogEntryCountTotal * saHpiWatchdogEventLogEntryCountTotal * saHpiSoftwareEventLogEntryCountTotal * saHpiOEMEventLogEntryCountTotal * saHpiUserEvenLogtEntryCountTotal -- notice the misspelling in red, presumably should be "EventLog" 3a. The SaHpiTime TEXTUAL-CONVENTION is currently based on Counter64. However, Counter64 and Counter32 is a SYNTAX intended for use in counting things, events, etc. by the means of computing deltas between successive samples and is thus not appropriate for representing timestamps. This is especially so if the timestamp has a set of values with special significance (like the value 0x8000000000000000, or the value ranges that represent absolute vs. relative time, or the values 0 and -1.). If a 64-byte timestamp is desired, it is not appropriate to pick Counter64 merely because it contains 64 bits. If the objective is to model each timestamp as a single 64-bit value, a better approach that is consistent with SMIv2 conventions would be to use a SYNTAX of OCTET STRING (SIZE (8)) instead of Counter64. 3b. It may also help to re-name the TEXTUAL-CONVENTION from SaHpiTime to SaHpiTimeString, to better indicate that the time is represented in the form of a hexadecimal-encoded string. 4. The following objects are defined with a SYNTAX of SafUnsigned64, which is a TEXTUAL-CONVENTION based on Opaque: * saHpiAutoInsertTimeoutForInsert * saHpiHotSwapExtractTimeout * saHpiEventLogInfoTime This conflicts with the requirement in section 7.1.9 of RFC 2578 that objects in a "standard" MIB module should not use a SYNTAX of Opaque. Although the HPI-MIB is intended for the IETF standards track, it is intended to be an "ad hoc" standard promoted by OpenHPI and SAForum, so I would consider that this requirement applies to it as well. The TEXTUAL-CONVENTION for SafUnsigned64 has a REFERENCE to the discussion about Opaque in David Perkins' and Evan McGinnis' book. However, it is better to adhere to the actual SMIv2 rules defined in RFC 2578 than to follow David's opinion in his book. Remember that he was one of the three editors charged with cleaning up inconsistencies in SMIv2, and he either changed his mind or lost this particular battle. Anyway, it appears that these three objects can simply use a SYNTAX of SaHpiTime instead, if the semantics are close enough. I would recommend doing so and avoiding Opaque altogether. Note that if Opaque were to be used, even in a TEXTUAL-CONVENTION, it must be included in the IMPORTS clause, per section 3.2 of RFC 2578. The current HPI-MIB does not do that. Again, though, I would recommend using SaHpiTime (or SaHpiTimeString, as per 3b above) instead of Opaque. 5a. One INDEX object is an auxiliary object that has a SYNTAX of Counter32, which violates section 7.7 of RFC 2578: * saHpiRdrEntryId Since the object obviously has semantics consistent with SaHpiEntryId, it would be better to use that SYNTAX. 5b. A related object also has a SYNTAX of Counter32: * saHpiRdrNextEntryId Since it is obvious that the saHpiRdrEntryId and saHpiRdrNextEntryId are in the same numbering space, the latter should also be changed to use a SYNTAX of SaHpiEntryId. 6a. Some INDEX objects that are auxiliary objects are currently defined with a MAX-ACCESS other than not-accessible. The following should have their MAX-ACCESS changed to "not-accessible" to comply with section 7.7 of RFC 2578. * saHpiDomainId (currently is accessible-for-notify) * saHpiDomainAlarmSeverity (currently is read-create) * saHpiRdrEntryId (currently is accessible-for-notify, even though it is not used in any notifications) * saHpiAreaId (currently is accessible-for-notify) * saHpiFieldId (currently is accessible-for-notify) Note that once that is done, these objects would have to be removed from OBJECT-GROUP clauses in which they are currently listed. Specifically: * remove saHpiDomainId from saHpiDomainInfoGroup * remove saHpiDomainAlarmSeverity from saHpiDomainAlarmGroup * remove saHpiRdrEntryId from saHpiRdrGroup * remove saHpiAreaId from saHpiAreaGroup * remove saHpiFieldId from saHpiFieldGroup 6b. Also, as a result of fixing 6a above, one of these not-accessible objects can no longer be included in notifications, per section 8.1 of RFC 2578: * saHpiDomainId The good news is that it is usually better to use a non-INDEX object in notifications, anyway, since such an object already includes the desired instance information and (if chosen well) can also include some additional information that would frequently be useful to notification receiver applications. I'd recommend using saHpiDomainActiveAlarms in place of saHpiDomainId in each of the nine notifications. In other words, this object would be substituted for saHpiDomainId in each of the OBJECTS lists in the various NOTIFICATION-TYPE clauses. 7. I would assume that the entries in the following tables should have a one-to-one relationship with the entries in the saHpiSensorTable (similar to the one-to-one relationship that exists between the entries in ifXTable and those they augment in the base table ifTable): * saHpiSensorReadingMaxTable * saHpiSensorReadingMinTable * saHpiSensorReadingNominalTable * saHpiSensorReadingNormalMaxTable * saHpiSensorReadingNormalMinTable * saHpiSensorThdPosHysteresisTable * saHpiSensorThdNegHysteresisTable If this is true, to be compliant with section 7.8.1 of RFC 2578, the *Entry clauses for these tables should use an AUGMENTS clause instead of an INDEX clause. There may be some other examples of one-to-one relationships as well, although I haven't scrutinized the HPI-MIB thoroughly enough to tell. If so, they should also follow suite. However, I assume that the entries in the following tables are NOT guaranteed to have a one-to-one relationship with the entries in saHpiSensorTable, because the DESCRIPTIONs for them specifically state that, "If SAI-HPI-B.01.01 SaHpiSensorThdDefnT field IsAccessible == FALSE then no threshold record is created.": * saHpiSensorReadingThdLowCriticalTable * saHpiSensorReadingThdLowMajorTable * saHpiSensorReadingThdLowMinorTable * saHpiSensorReadingThdUpCriticalTable * saHpiSensorReadingThdUpMajorTable * saHpiSensorReadingThdUpMinorTable 8. The nine notifications are not defined with 0 as next-to-last sub-component, which violates section 8.5 of RFC 2578. Even if no implementations of the HPI-MIB use SNMPv1, it would be wise to set a good example by following this convention, for the sake of other future MIB designers who might choose to use the HPI-MIB as an example. The easiest way to handle this is to add "hpiNotificationsPrefix OBJECT IDENTIFIER :: = { hpiNotifications 0 }", and then define the nine notifications as { hpiNotificationsPrefix 1 } through { hpiNotificationsPrefix 9 }. 9. The spelling of SaHpiInventoryFieldEntry is unrelated to saHpiFieldEntry. The former should be changed to SaHpiFieldEntry in three places. 10. The saHpiAdministrationGroup should be an OBJECT-GROUP instead of a NOTIFICATION-GROUP. Other conventions not followed by HPI-MIB module 11. It is not typical to include a descriptor in the IMPORTS clause and then not use it. The following descriptor should be removed: * DateAndTime 12a. The TEXTUAL-CONVENTION for SaHpiEntryId implies that instances for the first and last entries in a table would be 0x00000000 and 0xFFFFFFFF. This seems to imply that the corresponding objects for identifying an EntryId in a particular table would be re-numbered in the following cases (of which the second and third cases are probably the most likely): * If a new entry is added before the first entry * If a new entry is added after the last entry * If the first entry is removed * If the last entry is removed If this is true, I believe that the indexing scheme resulting from this numbering convention would make it difficult for management applications to track table entries as they come and go, because of the re-numbering that would result. But perhaps I misunderstand what was intended. Can someone explain this to me more clearly? 12b. If the first entry is indeed intended to be numbered 0x00000000, then this actually conflicts with a convention mentioned in section 7.7 of RFC 2578, which states the following: "The use of zero as a value for an integer-valued index object should be avoided, except in special cases." It doesn't identify those special cases, so perhaps it is acceptable here, but it would still be better to use 0x00000001 as the first instance of table rows. 13. The embedding of SAForum document version numbers (e.g., "hpiB0101") into the hierarchy of OIDs implies that there are plans to replace the existing objects and notifications with a new MIB module in future.. If this is true, then re-using "HPI-MIB" for that module's name and some other descriptor for the hierarchy (e.g., "hpiC0101") would render it difficult to distinguish objects and notifications in the current module from those in a future module in the event that some of the descriptors are NOT changed in the new module. This is because objects and notifications must be uniquely identified as <module name>::<descriptor>. For example, if the new HPI-MIB module retains saHpiWatchdogEventAction, then there is no way to distinguish the object from the current HPI-MIB from that in the new HPI-MIB, even though the latter would be under hpiC0101 instead of hpiB0101. This is because they would both be called HPI-MIB::saHpiWatchdogEventAction. I would recommend making one of the following changes: * Name the existing MIB module as HPI-B0101-MIB, retaining the hpiB0101 node. This would be better if you anticipate making MAJOR changes to the module in the future, while still retaining many descriptors for objects and notifications that you wish to retain. * Replace the hpiB0101 node with an hpi node. This would be better if you anticipate making MINOR changes to the module in the future, deprecating or obsoleting some small number of objects and/or notifications while adding some replacements or new ones. 14. The first statement in the DESCRIPTION for hpiB0101 implies that users with concerns for security should consider SNMPv2c to be as secure as SNMPv3. This is untrue, since SNMPv2c is in fact no more secure than SNMPv1 (since they both use community names in cleartext). This statement should instead recommend that users pick SNMPv3 if they have strong concerns for security. 15. The conformance information is usually written according to a convention that allows for future revision of the various object and notification groups and the compliances themselves. Some suggestions: * It would be better to divide conformance information into saHpiCompliances and saHpiGroups (both under saHpiConformance) than to put compliances and groups both under hpiMIBCompliances * It would be more consistent with other MIB modules to define compliances first and then define groups. * It would be nice to add the traditional "-- this module" after MODULE keyword (as in the IF-MIB in RFC-2863). 16. Some additional editing would help make the HPI-MIB module easier to read. Some suggestions: * It would be better to use consistent indentation for various constructs. * It would be better to avoid tab characters altogether, so that indentation is the same even when read by programs using different tab stops. Just replace them with the appropriate number of space characters. 17. Descriptors are easier to read if embedded acronyms are not fully capitalized. Some suggestions: * Use "Snmp" instead of "SNMP" in saHpiSNMPResourceId. * Use "Oem" instead of "OEM" in various object and notification descriptors (e.g., as in saHpiCtrlOemTable" instead of as in "saHpiOEMEventLogEntryCountTotal") 18. There is an inconsistent use of the term "Notifications" vs. "Notification" in the NOTIFICATION descriptors: * saHpiSensorNotification * saHpiSensorEnableChangeNotification * saHpiResourceNotifications * saHpiDomainNotifications * saHpiWatchdogNotification * saHpiHotSwapNotification * saHpiSoftwareNotifications * saHpiOEMNotifications * saHpiUserNotifications I think it would be better to use "Notification" instead of "Notifications" in order to denote what each notification actually means as it is generated: 19. Several objects define mappings between SA_ERR_HPI_* values and SNMPv2 PDU error-status values. Some of these mappings cause the semantics to conflict with the intentions. (I need a little more time to write up a list of the specific mappings that are in conflict -- I wanted to at least let you know that the conflicts exist.) Other issues and questions 19. The object hierarchy in the HPI-MIB is currently defined under hpiD, which is imported from the SAF-TC-MIB module. But it is not clear where to get the SAF-TC-MIB module from the OpenHPI web pages. Where can we retrieve a copy of that module? 20. The differences between the two lists of objects in items 1 and 2 above indicate that some tables have an object indicating the current # of entries AND an object indicating the total # of lifetime entries, but other tables just have the former. It is not clear why the latter is important for some tables but not for others. I would assume that the latter set of objects are provided so that they can be polled periodically to determine if a new entry has been added that needs to be dealt with, and that some tables do not need this functionality. If so, it may be better to have an object for each table that indicates when it last changed (e.g., as in ifTableLastChanged), since that can also shown when entries have been removed. 21. The SaHpiStatusCondType TEXTUAL-CONVENTION is not used. It looks like it should be used for the following objects that currently use an equivalent enumerated INTEGER: * saHpiDomainAlarmCondStatusCondType * saHpiAnnouncementStatusCondType BTW, the note in the saHpiDomainAlarmCondStatusCondType object's DESCRIPTION should be moved to the TEXTUAL-CONVENTION for SaHpiStatusCondType, since it presumably applies to all objects using that convention. 22. The saHpiUserEventRowStatus object says that, "The status column uses four defined values" and then proceeds to list only two. It is not clear whether this was supposed to be more like saHpiDomainAlarmRowStatus or not, although it is clear that some cut-and-pasting was used in the two DESCRIPTIONs. 23. There is a comment following the MAX-ACCESS of read-only for saHpiDomainEventLogEntryId that says, "### SMIv2 bug?" It is unclear what bug this comment refers to. Perhaps an earlier version of the HPI-MIB attempted to use this object in the INDEX clause while it was read-only, thus leading to a MIB compiler error. At this point, I don't see anything wrong here, so the comment can probably be removed. 24. There are typographical errors in DESCRIPTIONs. Here are some of the more obvious ones -- I suspect there are more: * use "SNMP" instead of "SNMP protocol" (which is redundant) * hpiB0101 * use "individual" instead of "indivdual" * hpiB0101 * use "data" instead of "date" * saHpiDomainTag * use "columnar object" instead of "calumnar node" * saHpiAreaIdIndex * use "pertinent" instead of "pertient" * saHpiEventLogInfoEntry * use "minimum" instead of "minum" * saHpiCtrlAnalogDefaultMinState * use "exists" instead of "exits" * saHpiDomainRef * use "saHpiSoftwareEventTable" intead of "saHpiSwEventTable" * saHpiEventRowPointer * use "saHpiOEMEventTable" instead of "saHpiOemEventTable" (unless change "OEM" to "Oem" as described above) * saHpiEventRowPointer * use "scalar object" instead of "columnar node" for objects that are, in fact, scalars * saHpiHpiVersion * saHpiAgentVersion * saHpiSNMPResourceId * saHpiDiscover * saHpiResourceEventEntryCountTotal * saHpiResourceEventEntryCount * saHpiDomainEventEntryCountTotal * saHpiDomainEventEntryCount * saHpiSensorEventEntryCountTotal * saHpiSensorEventEntryCount * saHpiSensorEnableChangeEventEntryCountTotal * saHpiSensorEnableChangeEventEntryCount * saHpiHotSwapEventEntryCountTotal * saHpiHotSwapEventEntryCount * saHpiWatchdogEventEntryCountTotal * saHpiWatchdogEventEntryCount * saHpiSoftwareEventEntryCountTotal * saHpiSoftwareEventEntryCount * saHpiOEMEventEntryCountTotal * saHpiOEMEventEntryCount * saHpiUserEventEntryCountTotal * saHpiUserEventEntryCount * saHpiResourceEventLogEntryCountTotal * saHpiResourceEventLogEntryCount * saHpiDomainEventLogEntryCountTotal * saHpiDomainEventLogEntryCount * saHpiSensorEventEntryLogCountTotal * saHpiSensorEventLogEntryCount * saHpiSensorEnableChangeEventLogEntryCountTotal * saHpiSensorEnableChangeEventLogEntryCount * saHpiHotSwapEventLogEntryCountTotal * saHpiHotSwapEventLogEntryCount * saHpiWatchdogEventLogEntryCountTotal * saHpiWatchdogEventLogEntryCount * saHpiSoftwareEventLogEntryCountTotal * saHpiSoftwareEventLogEntryCount * saHpiOEMEventLogEntryCountTotal * saHpiOEMEventLogEntryCount * saHpiUserEventLogEntryCountTotal * saHpiUserEventLogEntryCount * use "columnar object" instead of "columnar node" * ...this applies to all occurrences, other than those mis-used for scalar objects mentioned above... END OF COMMENTS |
From: Daniel F de A. <dde...@us...> - 2005-08-19 18:58:46
|
Bill, Currently, the saHpiDomainAlarmSeverity columnar node is set to accessible-for-notify access. Since this node is inspected and used in= the saHpiAlarmAdd API, the node needs to changed to read-create access. I'= ve talked about this issue with David, and I have also updated the node to= reflect this change in our working version. Unless you disagree, pleas= e update your working version as well. Regards, -Dan Daniel F. de Araujo Linux Technology Center Phone: 512-838-5925 Tie Line: 678-5925= |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-19 02:37:41
|
Folks , the clock has just ran out on this. The (good/bad) news is that we have the period between now and November for the CR to nail down finer points, like grammar, DEFVAL values, spelling, and the like. Going through the MIB for format (absolutely dreadful job- just finished at 7:00PM!) took most of the day , I caught spelling and grammar issues, and a few descriptions that could= be=20 improved on. So I doubt we are done. I fixed what I found that I could. I have no tech writer available to me, and will be off the radar for the week coming -- will be in muggy Alabama, far way from internet access. I have a feeling when I come back that there will be changes STILL to be done. When I get back let's figure what those are, and a process going forward.=20 I have shipped out a zip of the cleaned up MIB. I ran it through the comp= ilers. I put it out for a release vote. I then voted to release it for SAF revie= w. Let's get this to company review, and apply our changes and issues to the= =20 company review version. For now we at least have a stake in the ground. Cheers, Bill=20 -----Original Message----- From: ope...@li... [mailto:openhpi-saf-= mib...@li...] On Behalf Of David Judkovics Sent: Thursday, August 18, 2005 7:17 AM To: Swortwood Bill-G3666C Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Swortwood Bill-G3666C wrote: >The response was > >" Announcements are a type of Management Instrument (like controls,=20 >sensors, etc.). I would generally see them under the RDR branch of the=20 >tree, and not under the event or event log branch of the tree. Though=20 >they sometimes capture events as Annunciator Conditions, > Charlene, This would validate the current location of the AnnouncementTable, which = is the Event branch. =20 The AnnouncementTable under the EventLog branch has beed removed. I have not moved the AnnouncementTable to the Reources branch. If this=20 is to be done today is the day. If we were to do this we should=20 create a new branch/folder that is the Annunciator Branch and within that= branch should be the EntryCount for the AnnunciatorTable, the Annunciato= rTable and the AnnouncementTable. To me the creation and/or existance of an Announcement is very much analy= gous to an event. Therefore I am comfortable leaving the=20 AnnouncementTable in its present location. And I am willing to move it. DJ >they aren't trying to emulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...] >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO Septem= ber 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agi= le & Plan-Driven Development * Managing Projects & Teams * Testing & QA S= ecurity * Process Improvement & Measurement * http://www.sqe.com/bsce5sf = _______________________________________________ Openhpi-saf-mib-wg mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-saf-mib-wg |
From: Todd, C. J <cha...@in...> - 2005-08-18 23:22:41
|
Hi David, Konrad and Dan,=20 I need to inform you all that I am going to be transferring to another division at Intel. And as of September 16, 2005, I will no longer be working directly on SAF-related issues. After the 16th, you'll need to work with the HPI WG on HPI specific issues and questions -- most likely indirectly via Bill. =20 It was a pleasure working with you all, Charlene The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.=20 |
From: David J. <dju...@us...> - 2005-08-18 23:14:43
|
Swortwood Bill-G3666C wrote: >The response was=20 > >" Announcements are a type of Management Instrument (like controls, sens= ors, etc.). I would generally see them under the RDR branch of the tree,= and not under the event or event log branch of the tree. Though they so= metimes capture events as Annunciator Conditions,=20 > Charlene, This would validate the current location of the AnnouncementTable, which=20 is the Event branch. =20 The AnnouncementTable under the EventLog branch has beed removed. I have not moved the AnnouncementTable to the Reources branch. If this=20 is to be done today is the day. If we were to do this we should=20 create a new branch/folder that is the Annunciator Branch and within=20 that branch should be the EntryCount for the AnnunciatorTable, the=20 AnnunciatorTable and the AnnouncementTable. To me the creation and/or existance of an Announcement is very much=20 analygous to an event. Therefore I am comfortable leaving the=20 AnnouncementTable in its present location. And I am willing to move it. DJ >they aren't trying to emulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: Todd, C. J <cha...@in...> - 2005-08-18 21:35:53
|
Hi All, To try to clarify: Annunciators are Management Instruments -- like = Sensors or Controls or Watchdog Timers or Inventory Data Repositories. = They are as similar to an event as a Control would be. (And in fact, = you could look at them as a sort of "super-control".) =20 I think you are trying to relate Annunciator Conditions to events, but = that is still a confusing interpretation. An Annunciator Condition is = something that drives the Annunciator to announce something via = implementation-specific means. Some implementations decide to announce = alarms (which are not quite the same thing as events, btw), and others = do not. In fact, you can indicate alarm conditions (say via LEDs or = audible alarms) without even having an Annunciator Management = Instrument. =20 More important to note is that some implementations may decide to = announce other non-alarm conditions, which are related to the status of = the platform. What exactly is announced, when the Annunciator = Management Instrument is in the AUTO or SHARED modes is = implementation-dependent. =20 I don't see Annunciators being analogous to events. I don't even see = Annunciator Conditions being analogous to events. In some cases, = Annunciator conditions are related to alarms, but this is certainly not = the rule (if it were, we wouldn't have needed annunciators at all). If = you contrast the fact that annunciator conditions can reflect any status = condition deemed important by the implementation and/or HPI User and the = fact that alarm conditions that follow very strict rules that define = alarms -- hopefully it makes sense that alarms and annuncator conditions = are NOT the same things. In fact, that's why there are two separate = concepts to handle them. Because they aren't the same. =20 I will try to dig up some use case examples that were written by the = main proponent of Annunciators to try to illustrate, but I can't = guarantee I'll be able to find that information... Charlene The content of this message is my personal opinion only and although I = am an employee of Intel, the statements I make here in no way represent = Intel's position on the issue, nor am I authorized to speak on behalf of = Intel on this matter.=20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Thursday, August 18, 2005 7:17 AM To: Swortwood Bill-G3666C Cc: Todd, Charlene J; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Swortwood Bill-G3666C wrote: >The response was=20 > >" Announcements are a type of Management Instrument (like controls, = sensors, etc.). I would generally see them under the RDR branch of the = tree, and not under the event or event log branch of the tree. Though = they sometimes capture events as Annunciator Conditions,=20 > Charlene, This would validate the current location of the AnnouncementTable, which = is the Event branch. =20 The AnnouncementTable under the EventLog branch has beed removed. I have not moved the AnnouncementTable to the Reources branch. If this=20 is to be done today is the day. If we were to do this we should=20 create a new branch/folder that is the Annunciator Branch and within=20 that branch should be the EntryCount for the AnnunciatorTable, the=20 AnnunciatorTable and the AnnouncementTable. To me the creation and/or existance of an Announcement is very much=20 analygous to an event. Therefore I am comfortable leaving the=20 AnnouncementTable in its present location. And I am willing to move = it. DJ >they aren't trying to emulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the = saHpiAnnouncementEventLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would = like a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do = if we are running short on time or I can do it within 30 minutes of a = resolution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the = acknowledging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the = Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is = aware of the alarm=20 >>> and to influence platform-specific alarm annunciation = that may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: David J. <dju...@us...> - 2005-08-18 20:39:55
|
Todd, Charlene J wrote: >Hi All, >I can't really answer David's question, without knowing what the purpose= of that table really is. A tabled called "saHpiAnnouncementEventLogTabl= e" does not make any sense to me. =20 > =20 > I think that is the question. What was the purpose of this table. =20 Presently we are storing the announcements in the Events branch, in a=20 table named saHpiAnnouncementTable. I believe this may have been a case of being 'copy' happy. The table=20 is meanigless. I started this thread just make sure. It has been removed in the table Bill is scrubbing. >Is there a table elsewhere that contains Announcement conditions? I hon= estly don't know, but my gut feeling is that there probably isn't such a = table. If that is the case, I would say that the saHpiAnnouncementEventL= ogTable table should be removed, and replaced with a very similar table u= nder the RDR branch of the tree. That new table would be something like = "saHpiAnnouncementTable". =20 > >Charlene > >The content of this message is my personal opinion only and although I a= m an employee of Intel, the statements I make here in no way represent In= tel's position on the issue, nor am I authorized to speak on behalf of In= tel on this matter.=20 > >-----Original Message----- >From: ope...@li... [mailto:openhpi-saf= -mi...@li...] On Behalf Of David Judkovics >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: Todd, Charlene J; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the=20 >saHpiAnnouncementEventLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= =20 >a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do=20 >if we are running short on time or I can do it within 30 minutes of a=20 >resolution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>-----------------------------------------------------------------------= - >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practi= ces >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & = QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5s= f >_______________________________________________ >Openhpi-saf-mib-wg mailing list >Ope...@li... >https://lists.sourceforge.net/lists/listinfo/openhpi-saf-mib-wg > > =20 > |
From: David J. <dju...@us...> - 2005-08-18 20:29:39
|
Todd, Charlene J wrote: >I agree that the Announciator Number should be part of any announciator = table (and be part of the index to any particular announciator row that y= ou'd want to access to read/manipulate a particular announciator manageme= nt instrument). > =20 > The AnnunciatorTable does have as one of its indexes the AnnunciatorNum.=20 The AnnouncementTable does not have the AnnunciatorNum as one of its=20 indexes, but it now has an additional columnar node that is the=20 Annoucements corresponding AnnunciatorNum. >Charlene > >The content of this message is my personal opinion only and although I a= m an employee of Intel, the statements I make here in no way represent In= tel's position on the issue, nor am I authorized to speak on behalf of In= tel on this matter.=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Friday, August 12, 2005 11:00 AM >To: Swortwood Bill-G3666C; Todd, Charlene J; Daniel F de Araujo; saf mib= ; Konrad Rzeszutek >Subject: AnnouncementTable Missing AnnunciatorNum, Urgent!!! >Importance: High > >I believe there is an issue with the AnnouncementTable.=20 > >The 'ack' a given Announcement the minimum Id's required are; SessionId,= =20 >ReourceId, and AnnunciatorNum. To specify a specific Announcement the=20 >Announcement EntryId is also required. > >Unfortunately the current AnnouncementTable does not maintain nor have=20 >access to the AnnunciatorNum value. > >SaErrorT SAHPI_API saHpiAnnunciatorGetNext( > SAHPI_IN SaHpiSessionIdT SessionId, > SAHPI_IN SaHpiResourceIdT ResourceId, > SAHPI_IN SaHpiAnnunciatorNumT AnnunciatorNum, <=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=20 >MISSING !!!! > SAHPI_IN SaHpiSeverityT Severity, > SAHPI_IN SaHpiBoolT UnacknowledgedOnly, > SAHPI_INOUT SaHpiAnnouncementT *Announcement >); > > >1.) I propose an 'AnnunciatorNum' columnar node be added to the=20 >Announcement table. =20 > >2.) I would also propose adding a similar columnar node to the=20 >AnnouncementEventLog table but the existence of the table is in question. > >Best Regards/ Mit freundlichen Gr=FCssen > >David Judkovics > >dmj...@us... >Adv. Software Engineer >LTC xSeries Linux >IBM Server -- Endicott, NY >Tel: 607-429-4745 - Tie 620-4745 > > > > =20 > |
From: Todd, C. J <cha...@in...> - 2005-08-18 19:44:20
|
Hi All, I can't really answer David's question, without knowing what the purpose = of that table really is. A tabled called = "saHpiAnnouncementEventLogTable" does not make any sense to me. =20 Is there a table elsewhere that contains Announcement conditions? I = honestly don't know, but my gut feeling is that there probably isn't = such a table. If that is the case, I would say that the = saHpiAnnouncementEventLogTable table should be removed, and replaced = with a very similar table under the RDR branch of the tree. That new = table would be something like "saHpiAnnouncementTable". =20 Charlene The content of this message is my personal opinion only and although I = am an employee of Intel, the statements I make here in no way represent = Intel's position on the issue, nor am I authorized to speak on behalf of = Intel on this matter.=20 -----Original Message----- From: ope...@li... = [mailto:ope...@li...] On Behalf Of = David Judkovics Sent: Wednesday, August 17, 2005 2:30 PM To: Swortwood Bill-G3666C Cc: Todd, Charlene J; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Importance: High Swortwood Bill-G3666C wrote: > OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 > forward back the current HPI MIB? > =20 > - Bill Yes, And we have on one unanswered question. Should the=20 saHpiAnnouncementEventLogTable be removed. From Charlene's repsonse I believe the answer is yes. And I would like = a definitive YES or NO from her. If the answer is YES the remove of the table is something you could do=20 if we are running short on time or I can do it within 30 minutes of a=20 resolution and checkin to SF and email you a copy. If you feel its no big deal we have a useless table we can proceed now. = Your call. > > = ------------------------------------------------------------------------ > From: David Judkovics [mailto:dju...@us...] > Sent: Friday, August 12, 2005 2:18 PM > To: David Judkovics > Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 > Konrad Rzeszutek; saf mib > Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB > > David Judkovics wrote: > >> >>The two columnar nodes have been added in order to support the = acknowledging of Domain Alarms and Annoucements based on severity.=20 >> >>Also a AnnunciatorNum columnar node has been added to support the = Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe(). >> >> >>saHpiDomainAlarmTable: >> >>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge Alarms based on = severity. >> An HPI SNMP Manager acknowledges an alarm to indicate that it is = aware of the alarm=20 >> and to influence platform-specific alarm annunciation = that may be provided =20 >> . >> . >> . >> . >>=20 >> " >> ::=3D { saHpiDomainAlarmEntry 5 } >> >>saHpiAnnouncementTable: >> >>Two new columnar nodes have been added. >> >> >>saHpiAnnunciatorNum OBJECT-TYPE >> =20 >> > Named changed to > > saHpiAnnouncementAnnunciatorNum OBJECT-TYPE > > For consistency. > >> SYNTAX SaHpiInstrumentId >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Annunciator number for the addressed Annunciator." >> ::=3D { saHpiAnnouncementEntry 2 } >> >> >>saHpiAnnouncementAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge=20 >> all Announcements of a particular severity." >> ::=3D { saHpiAnnouncementEntry 7 } >> >> >> >> >>Best Regards/ Mit freundlichen Gr=FCssen >> >>David Judkovics >> >>dmj...@us... >>Adv. Software Engineer >>LTC xSeries Linux >>IBM Server -- Endicott, NY >>Tel: 607-429-4745 - Tie 620-4745 >> > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle = Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & = QA Security * Process Improvement & Measurement * = http://www.sqe.com/bsce5sf _______________________________________________ Openhpi-saf-mib-wg mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/openhpi-saf-mib-wg |
From: David J. <dju...@us...> - 2005-08-18 19:19:29
|
Swortwood Bill-G3666C wrote: > OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 > forward back the current HPI MIB? > =20 > - Bill Yes, And we have on one unanswered question. Should the=20 saHpiAnnouncementEventLogTable be removed. From Charlene's repsonse I believe the answer is yes. And I would like=20 a definitive YES or NO from her. If the answer is YES the remove of the table is something you could do=20 if we are running short on time or I can do it within 30 minutes of a=20 resolution and checkin to SF and email you a copy. If you feel its no big deal we have a useless table we can proceed now. =20 Your call. > > -----------------------------------------------------------------------= - > From: David Judkovics [mailto:dju...@us...] > Sent: Friday, August 12, 2005 2:18 PM > To: David Judkovics > Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 > Konrad Rzeszutek; saf mib > Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB > > David Judkovics wrote: > >> >>The two columnar nodes have been added in order to support the acknowle= dging of Domain Alarms and Annoucements based on severity.=20 >> >>Also a AnnunciatorNum columnar node has been added to support the Ack'i= ng in any mode of Announcements in the saHpiAnnouncementTabe(). >> >> >>saHpiDomainAlarmTable: >> >>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge Alarms based on = severity. >> An HPI SNMP Manager acknowledges an alarm to indicate that it is awar= e of the alarm=20 >> and to influence platform-specific alarm annunciation t= hat may be provided =20 >> . >> . >> . >> . >>=20 >> " >> ::=3D { saHpiDomainAlarmEntry 5 } >> >>saHpiAnnouncementTable: >> >>Two new columnar nodes have been added. >> >> >>saHpiAnnunciatorNum OBJECT-TYPE >> =20 >> > Named changed to > > saHpiAnnouncementAnnunciatorNum OBJECT-TYPE > > For consistency. > >> SYNTAX SaHpiInstrumentId >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Annunciator number for the addressed Annunciator." >> ::=3D { saHpiAnnouncementEntry 2 } >> >> >>saHpiAnnouncementAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge=20 >> all Announcements of a particular severity." >> ::=3D { saHpiAnnouncementEntry 7 } >> >> >> >> >>Best Regards/ Mit freundlichen Gr=FCssen >> >>David Judkovics >> >>dmj...@us... >>Adv. Software Engineer >>LTC xSeries Linux >>IBM Server -- Endicott, NY >>Tel: 607-429-4745 - Tie 620-4745 >> > |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-18 19:03:30
|
The response was=20 " Announcements are a type of Management Instrument (like controls, = sensors, etc.). I would generally see them under the RDR branch of the = tree, and not under the event or event log branch of the tree. Though = they sometimes capture events as Annunciator Conditions, they aren't = trying to emulate the event log functionality. " Reading further, it looks like the logging of events should be handled = by other table objects. There seems to be no compelling reason to keep the table, according to = Charlene. Make it go bye-bye. That help ? - Bill =20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Wednesday, August 17, 2005 2:30 PM To: Swortwood Bill-G3666C Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Importance: High Swortwood Bill-G3666C wrote: > OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to = > forward back the current HPI MIB? > =20 > - Bill Yes, And we have on one unanswered question. Should the = saHpiAnnouncementEventLogTable be removed. From Charlene's repsonse I believe the answer is yes. And I would = like a definitive YES or NO from her. If the answer is YES the remove of the table is something you could do = if we are running short on time or I can do it within 30 minutes of a = resolution and checkin to SF and email you a copy. If you feel its no big deal we have a useless table we can proceed now. = =20 Your call. > > = ---------------------------------------------------------------------- > -- > From: David Judkovics [mailto:dju...@us...] > Sent: Friday, August 12, 2005 2:18 PM > To: David Judkovics > Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 > Konrad Rzeszutek; saf mib > Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB > > David Judkovics wrote: > >> >>The two columnar nodes have been added in order to support the = acknowledging of Domain Alarms and Annoucements based on severity.=20 >> >>Also a AnnunciatorNum columnar node has been added to support the = Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe(). >> >> >>saHpiDomainAlarmTable: >> >>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge Alarms based = on severity. >> An HPI SNMP Manager acknowledges an alarm to indicate that it is = aware of the alarm=20 >> and to influence platform-specific alarm annunciation = that may be provided =20 >> . >> . >> . >> . >>=20 >> " >> ::=3D { saHpiDomainAlarmEntry 5 } >> >>saHpiAnnouncementTable: >> >>Two new columnar nodes have been added. >> >> >>saHpiAnnunciatorNum OBJECT-TYPE >> =20 >> > Named changed to > > saHpiAnnouncementAnnunciatorNum OBJECT-TYPE > > For consistency. > >> SYNTAX SaHpiInstrumentId >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Annunciator number for the addressed Annunciator." >> ::=3D { saHpiAnnouncementEntry 2 } >> >> >>saHpiAnnouncementAckBySeverity OBJECT-TYPE >> SYNTAX SaHpiSeverity >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "Use this columnar node to acknowledge=20 >> all Announcements of a particular severity." >> ::=3D { saHpiAnnouncementEntry 7 } >> >> >> >> >>Best Regards/ Mit freundlichen Gr=FCssen >> >>David Judkovics >> >>dmj...@us... >>Adv. Software Engineer >>LTC xSeries Linux >>IBM Server -- Endicott, NY >>Tel: 607-429-4745 - Tie 620-4745 >> > |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-18 18:49:36
|
MIB forwarded to Bill compiled clean with SimpleMIB website compiler and MIBDesignerII, no changes. A first! I am at line 2100, cleaning up formatting. I am debating if I will put the MIB in an 'official' SAF Frame doc, or just insert in the 'pile o mibs' and ship out as a ZIP package. Will keep you all updated. - Bill |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-18 17:17:41
|
Since we can also DEPRECATE a table or objects in the MIB, I can live wit= h it either=20 way.=20 - Bill=20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Thursday, August 18, 2005 7:31 AM To: Swortwood Bill-G3666C Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib; dm= ju...@us... Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Swortwood Bill-G3666C wrote: >The response was > >" Announcements are a type of Management Instrument (like controls, sens= ors, etc.). I would generally see them under the RDR branch of the tree,= and not under the event or event log branch of the tree. Though they so= metimes capture events as Annunciator Conditions, they aren't trying to e= mulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > =20 > Here is the latest (Thursday, Aug 18, 10:30 AM EST) MIB with the saHpiAn= nouncementEventLogTable removed.=20 I sent out a question to Charlene just prior to this one. There is one=20 last issue Charlene raised. The moving of the AnnouncementTable from the= Events branch to the Reources branch. There is a valid reason for and against this move. I vote not to move the= table. See other email for justification. .... frankly I don't understand why there isn't an Announcement Event=20 Type. The HPI mechanism for identifying new Announcements and/or=20 Announcement Status changes is non-optimal at best (from a realtime syste= ms and ease of use perspective). > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...] >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-18 17:17:34
|
Got it. I will take it from here. Thanks.=20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Thursday, August 18, 2005 7:42 AM To: Swortwood Bill-G3666C Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB Swortwood Bill-G3666C wrote: MIB sent as compressed file. >The response was > >" Announcements are a type of Management Instrument (like controls, sens= ors, etc.). I would generally see them under the RDR branch of the tree,= and not under the event or event log branch of the tree. Though they so= metimes capture events as Annunciator Conditions, they aren't trying to e= mulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...] >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: David J. <dju...@us...> - 2005-08-18 17:17:18
|
Swortwood Bill-G3666C wrote: >The response was=20 > >" Announcements are a type of Management Instrument (like controls, sens= ors, etc.). I would generally see them under the RDR branch of the tree,= and not under the event or event log branch of the tree. Though they so= metimes capture events as Annunciator Conditions, they aren't trying to e= mulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > =20 > Here is the latest (Thursday, Aug 18, 10:30 AM EST) MIB with the=20 saHpiAnnouncementEventLogTable removed.=20 I sent out a question to Charlene just prior to this one. There is one=20 last issue Charlene raised. The moving of the AnnouncementTable from=20 the Events branch to the Reources branch. There is a valid reason for and against this move. I vote not to move=20 the table. See other email for justification. .... frankly I don't understand why there isn't an Announcement Event=20 Type. The HPI mechanism for identifying new Announcements and/or=20 Announcement Status changes is non-optimal at best (from a realtime=20 systems and ease of use perspective). > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: David J. <dju...@us...> - 2005-08-18 17:09:10
|
Swortwood Bill-G3666C wrote: MIB sent as compressed file. >The response was=20 > >" Announcements are a type of Management Instrument (like controls, sens= ors, etc.). I would generally see them under the RDR branch of the tree,= and not under the event or event log branch of the tree. Though they so= metimes capture events as Annunciator Conditions, they aren't trying to e= mulate the event log functionality. " > > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. > > Make it go bye-bye. > > That help ? > >- Bill >=20 > >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High > >Swortwood Bill-G3666C wrote: > > =20 > >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >> > >Yes, > >And we have on one unanswered question. Should the saHpiAnnouncementEve= ntLogTable be removed. > > From Charlene's repsonse I believe the answer is yes. And I would like= a definitive YES or NO from her. > >If the answer is YES the remove of the table is something you could do i= f we are running short on time or I can do it within 30 minutes of a reso= lution and checkin to SF and email you a copy. > >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. > > =20 > >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >> >>David Judkovics wrote: >> >> =20 >> >>>The two columnar nodes have been added in order to support the acknowl= edging of Domain Alarms and Annoucements based on severity.=20 >>> >>>Also a AnnunciatorNum columnar node has been added to support the Ack'= ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>> >>> >>>saHpiDomainAlarmTable: >>> >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that it is awa= re of the alarm=20 >>> and to influence platform-specific alarm annunciation t= hat may be provided =20 >>> . >>> . >>> . >>> . >>> >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>> >>>saHpiAnnouncementTable: >>> >>>Two new columnar nodes have been added. >>> >>> >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>> >>> =20 >>> >>Named changed to >> >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >> >>For consistency. >> >> =20 >> >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>> >>> >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>> >>> >>> >>> >>>Best Regards/ Mit freundlichen Gr=FCssen >>> >>>David Judkovics >>> >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>> >>> =20 >>> >> > > =20 > |
From: Todd, C. J <cha...@in...> - 2005-08-18 16:42:25
|
More context, if needed (from a previous exchange on the HPI WG email = reflector). I'm still hunting down the use case emails, which are very = helpful in understanding the intent of the Annunciator MI. =20 =20 Charlene =20 ***************************** =20 =20 Q: What are HPI "Annunciator" management instruments, how are they used, = and how do they relate to the Domain Alarm Table? =20 A: It is a common feature of various platforms to have built-in methods = of displaying status information to a technician. For example, these = methods may include LEDs, text displays, audible alarms, dry-contact = relay closures, etc. It is difficult for portable management software = to use these devices effectively, because they may differ from platform = to platform. One platform may have three LEDs to indicate alarm levels; = another may have a single LED that changes color or blinks for different = alarm levels. Others may have text displays, text displays in = conjunction with LEDs, or relays. If management software has to = directly interact with each individual control on each different = platform, then that software could not easily move from one platform to = the next. =20 To help address this problem, HPI provides the "Annunciator" management = instrument. The purpose of this management instrument is to allow = management software to interact with platform status information display = hardware in an abstract way that is independent of the specifics of how = that particular platform displays information (i.e., through lighting = LEDs, or putting messages on a text display, or whatever). An HPI = Annunciator is a virtual device into which a set of "Announcements" can = be loaded. The platform-specific HPI implementation will take whatever = actions are appropriate for that platform to display (that is, to = "annunciate") that set of Announcements. One platform that has only = LEDs may simply light an LED if any Announcements, or any Announcement = of a sufficient severity is present. Another platform may scroll = through all active Announcements on a small front-panel text display. A = third may take a combination of these actions, all dependent on what = specific display hardware is available on that platform. =20 Announcements can be added to or deleted from an HPI Annunciator by a = management application using the HPI interface. So, if the management = application determines that some condition should be displayed, it can = add an Announcement for that condition to the Annunciator, and the = platform specific HPI implementation will take whatever actions are = appropriate to communicate the information on its display(s). = Platforms may also automatically add or delete Announcements in an HPI = Annunciator. Thus, a management application can learn what information = is being displayed by reading the set of Announcements in an = Annunciator. There is no requirement, however, on what information a = platform must automatically announce, so reading the contents of an = Annunciator is not a reliable way to learn status information about the = system; it is just a way to learn what information is being displayed. =20 There is a potential confusion between the functionality and use of HPI = Annunciators, and the HPI Domain Alarm Table (DAT). Although they are = both tables that contain information about abnormal "Alarm" conditions = on the platform, these two facilities are intended to serve different = purposes. The purpose of the HPI Annunciator management instrument is = as described above: it provides an abstract interface to some sort of = physical status display hardware. The primary purpose of the DAT, on = the other hand, is to communicate Alarm status information to HPI users = via the HPI interface. Because these two structures serve different = purposes, there are some subtle, but significant differences in their = functionality, as described below. =20 1) The specification describes explicitly what information the HPI = implementation will add to and remove from the DAT, but does not place = any restrictions on what the implementation will add to or remove from = an Annunciator (except that an Annunciator may be set into "User Mode" = in which case the HPI implementation must not add or remove any = Announcements). The reason for this difference is that the DAT is = intended to be a place users can learn about the status of the system. = Thus, it is important to define what status information will be = reflected in the DAT. On the other hand, the Announcements in an = Annunciator will reflect whatever the platform happens to be displaying = to a technician. Because the HPI specification does not address what = information should be displayed to technicians on a platform, it cannot = dictate what Announcements the implementation must add to an = Annunciator. =20 2) Users may only add "User" Alarms to the DAT, but they may add any = sort of Announcements to an Annunciator. Because the DAT is primarily = used to communicate from the platform to users, having users add the = same sort of Alarms to the DAT as the HPI implementation adds itself = (e.g., sensor or resource Alarms) would be potentially very confusing, = hence the restriction to User Alarms. There may be valid reasons for = users to add Announcements concerning sensor or resource status = conditions to an Annunciator, though. For example, a user can choose to = place an Annunciator into "User Mode" and thus directly control all = information that is displayed to the technician. In this case, the user = can provide a "filter" for system status conditions, and choose to = display (or not) individual Announcements, including sensor and resource = Announcements, by writing them to the Annunciator. =20 3) All Alarms in the DAT must have a severity of SAHPI_CRITICAL, = SAHPI_MAJOR, or SAHPI_MINOR, but Announcements in an Annunciator may = have any severity level. The purpose of the DAT is specifically to = communicate Alarm conditions to users, which is why its entries are = restricted. A platform Annunciator, though, may be designed to display = normal conditions as well as Alarm conditions. =20 3) Users may not delete any Alarms from the DAT except for User Alarms, = but users may delete any Announcements from an Annunciator (unless the = Annunciator is in "Auto Mode," which prevents any additions or deletions = by the user). Allowing a user to delete Alarms from the DAT would make = it invalid as a source of status information for other users. On the = other hand, if a user is attempting to control what is displayed via an = Annunciator, then the user needs to be able to delete any Announcement = that the user concludes should no longer be displayed. =20 4) There is always one and only one DAT per domain, but there may be any = number of Annunciators located in one or more Resources. DATs are = located in each Domain so that users have a single, easy to access table = that can be used to learn about all Alarm conditions within the entire = Domain. Annunciators, like other management instruments, are defined to = reflect actual platform management hardware - in this case display = hardware - which may or may not exist throughout the system. = Annunciators are housed in resources, like all management instruments, = because they are associated with actual display hardware managed through = resources. =20 There may be multiple Annunciators on a single resource, or spread among = multiple resources if there are multiple logical status displays on the = platform. A "logical status display" may itself contain multiple = devices. For example a single "logical status display" may be made up = of three LEDs indicating "Minor", "Major", or "Critical" alarms are = present, a text display that shows details of the alarms, and an audible = alert that sounds when unacknowledged alarms are present. All of these = devices, working together to display the same set of alarms would be one = "logical status display", and thus interfaced through one Annunciator. = But, say a platform contained a separate set of "Minor/Major/Critical" = LEDs for different sub-systems. Then each set of LEDs would be a = separate "logical status display", each displaying a different set of = Announcements (e.g., Announcements related to each individual = sub-system), so the HPI implementation would need to create multiple = Annunciator management instruments for each sub-system's LED set. =20 A primary point of confusion arises from the fact that there is a way to = add User Alarms to the DAT. If the purpose of the DAT is to communicate = Alarm conditions from the HPI implementation to the user, why would the = user ever want to add information to the DAT? The main reason for this = capability is simply to allow the User to make the DAT be a more = "complete" database of Alarm conditions in the system. Users may add = Alarms to the DAT so that they can later retrieve that Alarm = information, or so that other users that access the same Domain can find = both HPI implementation generated and User generated Alarms in one = place. =20 =20 In addition, an HPI implementation may use the contents of the DAT to = drive implementation-specific status displays. The HPI specification = addresses this (in section 3.2.1, on page 19):=20 HPI implementations should use the contents of a Domain Alarm Table to = control the annunciation of alarms on a platform. Alarm annunciation by = a particular HPI implementation is implementation-specific. The = implementation may directly control annunciation hardware as a result of = changes to the DAT, or it may utilize HPI control or annunciator = management instruments in various resources to announce the alarms. It = is implementation-specific what annunciation actions are taken when = alarms are added, removed, or acknowledged in the Domain Alarm Table. =20 Although the specification says that an implementation "should" somehow = use the contents of the DAT to control display of alarm information on = the platform, a user cannot depend on an HPI implementation to provide = this capability. It is true that an HPI implementation may do whatever = it wishes with the contents of the DAT "below the line" of the HPI = interface, and this includes providing some sort of automatic display of = status information from the DAT on the platform. But, the user cannot = assume that adding User Alarms to the DAT has any effect on the system = other than to add a record to the DAT, which can be subsequently read by = HPI users. =20 The HPI interface thus provides three ways for users to interface with = display hardware: 1) Individual LEDs, text panels, audible alarms, relays, etc. may be = exposed as specific HPI Controls. When so exposed, an HPI user is able = to directly turn individual LEDs on or off, place specific text on a = text display panel, an so forth. With this sort of interface, the user = can control both what alarm data is displayed and how it is displayed. = But, the user application must deal with the fact that different = platforms will have different sets of display hardware controls, so = producing portable management applications may be very difficult. =20 2) "Logical displays" consisting of multiple LEDs, text panels, etc. may = be modeled as HPI Annunciators. When Annunciators are defined, an HPI = user can see and control what status conditions are being displayed on a = particular "logical display" in the system without needing to understand = the specifics of how the data is presented on the platform display = hardware. The user has control over what information is to be = displayed, but not how it is displayed. By hiding the details of = platform-specific display hardware, this level of interface can be more = easily used by portable management applications. =20 3) An HPI implementation may automatically control platform displays = using data found in the DAT. The user can add User Alarms to the DAT, = and the HPI implementation may use this to update its status displays. = However, the user has no control over how, or even if the User Alarm is = displayed in the system, nor any way of displaying non-alarm status = information. =20 An HPI implementation may make any or all of these interfaces available. = For example: 1) Each LED, text panel, audible alarm, alarm relay, etc., may be = modeled as an individual HPI Control. This allows an HPI user to take = direct control of each device, if desired. These HPI Controls can also = be modeled in "Auto Mode", allowing the HPI implementation to control = them as part of a "logical display" tied to an HPI Annunciator. =20 2) Each "logical display" collection of LEDs, text panels, etc., that = are used together to display status information can be modeled as an HPI = Annunciator. This allows an HPI user to interface in a portable way = with the "logical display" by reading and writing Announcements. The = Annunciator can be implemented by software (within the HPI = implementation) that analyzes the current set of Announcements and = drives the "logical display" by changing the Control State of the = individual HPI Controls tied to each LED, text panel, etc.=20 =20 3) If the HPI implementation automatically drives platform displays from = the contents of a DAT, it can also define Annunciators for each logical = display, and then automatically populate Announcements in those = Annunciators from the DAT. If the Annunciators can be changed to "User" = mode, this allows the user to override the automatic status display = provided by the HPI implementation. Even if the Annunciator does not = allow User access - i.e., if the Annunciator is configured to operate = only in "Auto" mode - there are arguments for exposing to the user what = status information is being displayed by reflecting it in an HPI = Annunciator. =20 =20 =20 =20 =20 The content of this message is my personal opinion only and although I = am an employee of Intel, the statements I make here in no way represent = Intel's position on the issue, nor am I authorized to speak on behalf of = Intel on this matter.=20 =20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Thursday, August 18, 2005 7:17 AM To: Swortwood Bill-G3666C Cc: Todd, Charlene J; Daniel F de Araujo; Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB =20 Swortwood Bill-G3666C wrote: =20 >The response was=20 >=20 >" Announcements are a type of Management Instrument (like controls, = sensors, etc.). I would generally see them under the RDR branch of the = tree, and not under the event or event log branch of the tree. Though = they sometimes capture events as Annunciator Conditions,=20 >=20 Charlene, =20 This would validate the current location of the AnnouncementTable, which = is the Event branch. =20 =20 The AnnouncementTable under the EventLog branch has beed removed. =20 I have not moved the AnnouncementTable to the Reources branch. If this=20 is to be done today is the day. If we were to do this we should=20 create a new branch/folder that is the Annunciator Branch and within=20 that branch should be the EntryCount for the AnnunciatorTable, the=20 AnnunciatorTable and the AnnouncementTable. =20 To me the creation and/or existance of an Announcement is very much=20 analygous to an event. Therefore I am comfortable leaving the=20 AnnouncementTable in its present location. And I am willing to move = it. =20 DJ =20 >they aren't trying to emulate the event log functionality. " >=20 > Reading further, it looks like the logging of events should be handled = by other table objects. > There seems to be no compelling reason to keep the table, according to = Charlene. >=20 > Make it go bye-bye. >=20 > That help ? >=20 >- Bill >=20 >=20 >-----Original Message----- >From: David Judkovics [mailto:dju...@us...]=20 >Sent: Wednesday, August 17, 2005 2:30 PM >To: Swortwood Bill-G3666C >Cc: 'Todd, Charlene J'; Daniel F de Araujo; Konrad Rzeszutek; saf mib >Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >Importance: High >=20 >Swortwood Bill-G3666C wrote: >=20 > =20 >=20 >>OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to=20 >>forward back the current HPI MIB? >>=20 >>- Bill >> =20 >>=20 >=20 >Yes, >=20 >And we have on one unanswered question. Should the = saHpiAnnouncementEventLogTable be removed. >=20 > From Charlene's repsonse I believe the answer is yes. And I would = like a definitive YES or NO from her. >=20 >If the answer is YES the remove of the table is something you could do = if we are running short on time or I can do it within 30 minutes of a = resolution and checkin to SF and email you a copy. >=20 >If you feel its no big deal we have a useless table we can proceed now. = =20 >Your call. >=20 > =20 >=20 >>---------------------------------------------------------------------- >>-- >>From: David Judkovics [mailto:dju...@us...] >>Sent: Friday, August 12, 2005 2:18 PM >>To: David Judkovics >>Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo;=20 >>Konrad Rzeszutek; saf mib >>Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB >>=20 >>David Judkovics wrote: >>=20 >> =20 >>=20 >>>The two columnar nodes have been added in order to support the = acknowledging of Domain Alarms and Annoucements based on severity.=20 >>>=20 >>>Also a AnnunciatorNum columnar node has been added to support the = Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe(). >>>=20 >>>=20 >>>saHpiDomainAlarmTable: >>>=20 >>>saHpiDomainAlarmAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge Alarms based on = severity. >>> An HPI SNMP Manager acknowledges an alarm to indicate that = it is aware of the alarm=20 >>> and to influence platform-specific alarm annunciation = that may be provided =20 >>> . >>> . >>> . >>> . >>>=20 >>> " >>> ::=3D { saHpiDomainAlarmEntry 5 } >>>=20 >>>saHpiAnnouncementTable: >>>=20 >>>Two new columnar nodes have been added. >>>=20 >>>=20 >>>saHpiAnnunciatorNum OBJECT-TYPE >>>=20 >>>=20 >>> =20 >>>=20 >>Named changed to >>=20 >> saHpiAnnouncementAnnunciatorNum OBJECT-TYPE >>=20 >>For consistency. >>=20 >> =20 >>=20 >>> SYNTAX SaHpiInstrumentId >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Annunciator number for the addressed Annunciator." >>> ::=3D { saHpiAnnouncementEntry 2 } >>>=20 >>>=20 >>>saHpiAnnouncementAckBySeverity OBJECT-TYPE >>> SYNTAX SaHpiSeverity >>> MAX-ACCESS read-create >>> STATUS current >>> DESCRIPTION >>> "Use this columnar node to acknowledge=20 >>> all Announcements of a particular severity." >>> ::=3D { saHpiAnnouncementEntry 7 } >>>=20 >>>=20 >>>=20 >>>=20 >>>Best Regards/ Mit freundlichen Gr=FCssen >>>=20 >>>David Judkovics >>>=20 >>>dmj...@us... >>>Adv. Software Engineer >>>LTC xSeries Linux >>>IBM Server -- Endicott, NY >>>Tel: 607-429-4745 - Tie 620-4745 >>>=20 >>> =20 >>>=20 >>=20 >=20 > =20 >=20 =20 |
From: Swortwood Bill-G. <bil...@mo...> - 2005-08-17 17:59:16
|
OK, I am now back up for air with SAF AIS SNMP. Are you guys ready to = forward back the current HPI MIB? =20 - Bill _____ =20 From: David Judkovics [mailto:dju...@us...]=20 Sent: Friday, August 12, 2005 2:18 PM To: David Judkovics Cc: Swortwood Bill-G3666C; 'Todd, Charlene J'; Daniel F de Araujo; = Konrad Rzeszutek; saf mib Subject: Re: [Openhpi-saf-mib-wg] Three Nodes Added to the MIB David Judkovics wrote:=20 The two columnar nodes have been added in order to support the = acknowledging of Domain Alarms and Annoucements based on severity.=20 Also a AnnunciatorNum columnar node has been added to support the = Ack'ing in any mode of Announcements in the saHpiAnnouncementTabe(). saHpiDomainAlarmTable: saHpiDomainAlarmAckBySeverity OBJECT-TYPE SYNTAX SaHpiSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "Use this columnar node to acknowledge Alarms based on = severity. An HPI SNMP Manager acknowledges an alarm to indicate that it is = aware of the alarm=20 and to influence platform-specific alarm annunciation = that may be provided =20 . . . . =20 " ::=3D { saHpiDomainAlarmEntry 5 } saHpiAnnouncementTable: Two new columnar nodes have been added. saHpiAnnunciatorNum OBJECT-TYPE =20 Named changed to=20 saHpiAnnouncementAnnunciatorNum OBJECT-TYPE For consistency. SYNTAX SaHpiInstrumentId MAX-ACCESS read-create STATUS current DESCRIPTION "Annunciator number for the addressed Annunciator." ::=3D { saHpiAnnouncementEntry 2 } saHpiAnnouncementAckBySeverity OBJECT-TYPE SYNTAX SaHpiSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "Use this columnar node to acknowledge=20 all Announcements of a particular severity." ::=3D { saHpiAnnouncementEntry 7 } Best Regards/ Mit freundlichen Gr=FCssen David Judkovics dmj...@us... <mailto:dmj...@us...>=20 Adv. Software Engineer LTC xSeries Linux IBM Server -- Endicott, NY Tel: 607-429-4745 - Tie 620-4745 |
From: David J. <dju...@us...> - 2005-08-12 21:19:05
|
David Judkovics wrote: > >The two columnar nodes have been added in order to support the acknowled= ging of Domain Alarms and Annoucements based on severity.=20 > >Also a AnnunciatorNum columnar node has been added to support the Ack'in= g in any mode of Announcements in the saHpiAnnouncementTabe(). > > >saHpiDomainAlarmTable: > >saHpiDomainAlarmAckBySeverity OBJECT-TYPE > SYNTAX SaHpiSeverity > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Use this columnar node to acknowledge Alarms based on s= everity. > An HPI SNMP Manager acknowledges an alarm to indicate that it is aware= of the alarm=20 > and to influence platform-specific alarm annunciation th= at may be provided =20 > . > . > . > . >=20 > " > ::=3D { saHpiDomainAlarmEntry 5 } > >saHpiAnnouncementTable: > >Two new columnar nodes have been added. > > >saHpiAnnunciatorNum OBJECT-TYPE > =20 > Named changed to saHpiAnnouncementAnnunciatorNum OBJECT-TYPE For consistency. > SYNTAX SaHpiInstrumentId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Annunciator number for the addressed Annunciator." > ::=3D { saHpiAnnouncementEntry 2 } > > >saHpiAnnouncementAckBySeverity OBJECT-TYPE > SYNTAX SaHpiSeverity > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Use this columnar node to acknowledge=20 > all Announcements of a particular severity." > ::=3D { saHpiAnnouncementEntry 7 } > > > > >Best Regards/ Mit freundlichen Gr=FCssen > >David Judkovics > >dmj...@us... >Adv. Software Engineer >LTC xSeries Linux >IBM Server -- Endicott, NY >Tel: 607-429-4745 - Tie 620-4745 > |
From: David J. <dju...@us...> - 2005-08-12 21:16:36
|
Todd, Charlene J wrote: > Hi David, > > Announcements are a type of Management Instrument (like controls, > sensors, etc.). I would generally see them under the RDR branch of > the tree, and not under the event or event log branch of the tree. > Though they sometimes capture events as Annunciator Conditions, they > aren't trying to emulate the event log functionality. > Should the AnnouncementEventLogTable be removed? This is the question that needs a resolution before the FTF. I'm reluctant to move the AnnouncementTable from Event branch at this point. Unless Bill thinks we should I vote to leave it there. When the next release of the B spec is released we could discuss moving it then. > > > Let me take a quick example: > > (1) A resource provides an Annunciator, and it "advertises" as such in > its RDR repository > > (2) Sometime later a temperature sensor trips a critical threshold > > (3) Several things happen in response to the temperature sensor > tripping this threshold: > > (A) Assuming events are enabled for this sensor and this threshold > of this sensor, an event is created and is put into the event queue > > (B) Assuming events are enabled for this sensor and this threshold > of this sensor, an alarm condition is recorded in the DAT > > (C) The event may also optionally (at the discretion of the > implementation) be stored in the Resource and Domain Event Logs as > appropriate > > (D) And the event may optionally trigger an Annunciator condition > to be raised. This is conditional upon what the rules are for that > particular announciator, and what status conditions it considers > "announcable". > > (4) The temperature sensor returns to normal readings > > (A) Assuming deassert events are enabled for this sensor and this > threshold, a deassert event is created and is put into the event queue > > (B) The alarm condition is removed from the DAT > > (C ) The deassert event may be added to the event log > (implementation-dependent). Not that the assertion event remains in > the event log. > > (D) and the deassertion may optionally remove the Announciator > condition. This is conditional upon what the rules are for that > particular announciator. > > > > If a very similar resource did not provide an Annunciator, the whole > scenario would remain the same, except for Steps 1, Step 3D, and Step 4D. > > > > Does this help? > > > > Charlene > > > > > > The content of this message is my personal opinion only and although I > am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > ------------------------------------------------------------------------ > > From: David Judkovics [mailto:dju...@us...] > Sent: Friday, August 12, 2005 6:13 AM > To: Todd, Charlene J > Cc: Daniel F de Araujo; bil...@mo...; > ope...@li...; David M Judkovics > Subject: Re: [Openhpi-saf-mib-wg] RE: HPI-MIB: AnnouncementEventLogTable > Importance: High > > > > Todd, Charlene J wrote: > > Dan, > > I think I need a bit more context. What is an AnnouncementEventLog > supposed to represent? HPI has the concept of Event Logs, and another > concept of Annunicators - but they aren't the same thing. > > The is so because there is no Event Type Announcement? > > > So I'm not too clear what these tables are meant to map to in the HPI > world... > > Presently we have a table for Announcements under the Event and the > EventLog branches of the MIB. Announcements are Created be writing to > the Announcement Table under the Event branch. > > Even though there is no Announcement Event type I believe the > reasoning was this is where Announcements will be stored (Event > branch). This means they will persist here even if they are ack'd. > If they are deleted they should be removed from this table which is > different from the other tables under the Event branch. > > I assumed the Announcement table in the EventLog branch is for the > storing any events that may be stored in the HPI EventLog. > > Are you saying Announcements will never be identified via > saHpiEventLogEntryGet()? > > You seem to be saying no. If this is the case we may not need the > table under the EventLog branch. > > > > > > Charlene > > > > The content of this message is my personal opinion only and although I > am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > ------------------------------------------------------------------------ > > From: Daniel F de Araujo [mailto:dde...@us...] > Sent: Thursday, August 11, 2005 2:37 PM > To: bil...@mo... <mailto:bil...@mo...>; > Todd, Charlene J; ope...@li... > <mailto:ope...@li...> > Cc: David M Judkovics > Subject: HPI-MIB: AnnouncementEventLogTable > > > > Bill, Charlene, et al - > > While inspecting the hpi-mib today, I noticed that the > AnnouncementEventLogTable has a few columnar nodes designated as > read-create. The problem is that I don't believe there is actually a > way to create a new announcement event log through any of the HPI > APIs. The closest API that we could use is saHpiEventLogEntryAdd, > however, the spec specifically states that the event field must be of > type SAHPI_ET_USER. Should the read-create attributes of the > announcement event log table be changed to read-only? > > Reference (line 6164 - 6285): > > saHpiAnnouncementEventLogSeverity OBJECT-TYPE > SYNTAX SaHpiSeverity > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Only used with DAT and Annunciator functions. > This is not a valid severity for events or alarms." > ::= { saHpiAnnouncementEventLogEntry 4 } > > > saHpiAnnouncementEventLogAcknowledged OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Acknowledged flag." > ::= { saHpiAnnouncementEventLogEntry 5 } > > > saHpiAnnouncementEventLogStatusCondType OBJECT-TYPE > SYNTAX INTEGER { > undefined(0), > sensor(1), > resource(2), > oem(3), > user(4) } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Status Condition Type." > ::= { saHpiAnnouncementEventLogEntry 6 } > > > saHpiAnnouncementEventLogEntityPath OBJECT-TYPE > SYNTAX SaHpiEntityPath > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "See Textual-Convention for details." > ::= { saHpiAnnouncementEventLogEntry 7 } > > > saHpiAnnouncementEventLogSensorNum OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Sensor associated with status Only valid > if saHpiAnnouncementEventLogStatusCondType is sensor(1)." > ::= { saHpiAnnouncementEventLogEntry 8 } > > > saHpiAnnouncementEventLogEventState OBJECT-TYPE > SYNTAX SaHpiEventState > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Sensor event state. Only valid if > saHpiAnnouncementEventLogStatusCondType is sensor(1)." > ::= { saHpiAnnouncementEventLogEntry 9 } > > > saHpiAnnouncementEventLogName OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (0..255)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "AIS compatible identifier associated with Status condition." > ::= { saHpiAnnouncementEventLogEntry 10 } > > > saHpiAnnouncementEventLogMid OBJECT-TYPE > SYNTAX SaHpiManufacturerId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Manufacturer Id associated with status condition, > required when saHpiAnnouncementEventLogStatusCondType is oem(3)." > ::= { saHpiAnnouncementEventLogEntry 11 } > > > saHpiAnnouncementEventLogTextType OBJECT-TYPE > SYNTAX SaHpiTextType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Field Data. > See Definition for SaHpiTextType for more details." > ::= { saHpiAnnouncementEventLogEntry 12 } > > > saHpiAnnouncementEventLogTextLanguage OBJECT-TYPE > SYNTAX SaHpiTextLanguage > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Field Data. > See Definition for SaHpiTextLanguage for more details." > ::= { saHpiAnnouncementEventLogEntry 13 } > > > saHpiAnnouncementEventLogText OBJECT-TYPE > SYNTAX SaHpiText > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Field Data. > The type of date is specified > by saHpiResourceTagTextType and saHpiResourceTagLanguage." > ::= { saHpiAnnouncementEventLogEntry 14 } > > > saHpiAnnouncementEventLogDelete OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This function allows the HPI SNMP Manager to delete a single > announcement. Announcements may be deleted individually by specifying > a specific index and setting this columnar node to destroy(6). > " > ::= { saHpiAnnouncementEventLogEntry 15 } > > Regards, > -Dan > > Daniel F. de Araujo > Linux Technology Center > Phone: 512-838-5925 > Tie Line: 678-5925 > > > |
From: David J. <dju...@us...> - 2005-08-12 21:11:45
|
The two columnar nodes have been added in order to support the acknowledg= ing of Domain Alarms and Annoucements based on severity.=20 Also a AnnunciatorNum columnar node has been added to support the Ack'ing= in any mode of Announcements in the saHpiAnnouncementTabe(). saHpiDomainAlarmTable: saHpiDomainAlarmAckBySeverity OBJECT-TYPE SYNTAX SaHpiSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "Use this columnar node to acknowledge Alarms based on se= verity. An HPI SNMP Manager acknowledges an alarm to indicate that it is aware = of the alarm=20 and to influence platform-specific alarm annunciation tha= t may be provided =20 . . . . =20 " ::=3D { saHpiDomainAlarmEntry 5 } saHpiAnnouncementTable: Two new columnar nodes have been added. saHpiAnnunciatorNum OBJECT-TYPE SYNTAX SaHpiInstrumentId MAX-ACCESS read-create STATUS current DESCRIPTION "Annunciator number for the addressed Annunciator." ::=3D { saHpiAnnouncementEntry 2 } saHpiAnnouncementAckBySeverity OBJECT-TYPE SYNTAX SaHpiSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "Use this columnar node to acknowledge=20 all Announcements of a particular severity." ::=3D { saHpiAnnouncementEntry 7 } Best Regards/ Mit freundlichen Gr=FCssen David Judkovics dmj...@us... Adv. Software Engineer LTC xSeries Linux IBM Server -- Endicott, NY Tel: 607-429-4745 - Tie 620-4745 |
From: Todd, C. J <cha...@in...> - 2005-08-12 19:33:32
|
I agree that the Announciator Number should be part of any announciator = table (and be part of the index to any particular announciator row that = you'd want to access to read/manipulate a particular announciator = management instrument). Charlene The content of this message is my personal opinion only and although I = am an employee of Intel, the statements I make here in no way represent = Intel's position on the issue, nor am I authorized to speak on behalf of = Intel on this matter.=20 -----Original Message----- From: David Judkovics [mailto:dju...@us...]=20 Sent: Friday, August 12, 2005 11:00 AM To: Swortwood Bill-G3666C; Todd, Charlene J; Daniel F de Araujo; saf = mib; Konrad Rzeszutek Subject: AnnouncementTable Missing AnnunciatorNum, Urgent!!! Importance: High I believe there is an issue with the AnnouncementTable.=20 The 'ack' a given Announcement the minimum Id's required are; SessionId, = ReourceId, and AnnunciatorNum. To specify a specific Announcement the=20 Announcement EntryId is also required. Unfortunately the current AnnouncementTable does not maintain nor have=20 access to the AnnunciatorNum value. SaErrorT SAHPI_API saHpiAnnunciatorGetNext( SAHPI_IN SaHpiSessionIdT SessionId, SAHPI_IN SaHpiResourceIdT ResourceId, SAHPI_IN SaHpiAnnunciatorNumT AnnunciatorNum, = <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 MISSING !!!! SAHPI_IN SaHpiSeverityT Severity, SAHPI_IN SaHpiBoolT UnacknowledgedOnly, SAHPI_INOUT SaHpiAnnouncementT *Announcement ); 1.) I propose an 'AnnunciatorNum' columnar node be added to the=20 Announcement table. =20 2.) I would also propose adding a similar columnar node to the=20 AnnouncementEventLog table but the existence of the table is in = question. Best Regards/ Mit freundlichen Gr=FCssen David Judkovics dmj...@us... Adv. Software Engineer LTC xSeries Linux IBM Server -- Endicott, NY Tel: 607-429-4745 - Tie 620-4745 |
From: Todd, C. J <cha...@in...> - 2005-08-12 19:32:23
|
Hi David, Announcements are a type of Management Instrument (like controls, sensors, etc.). I would generally see them under the RDR branch of the tree, and not under the event or event log branch of the tree. Though they sometimes capture events as Annunciator Conditions, they aren't trying to emulate the event log functionality. =20 =20 Let me take a quick example: (1) A resource provides an Annunciator, and it "advertises" as such in its RDR repository (2) Sometime later a temperature sensor trips a critical threshold (3) Several things happen in response to the temperature sensor tripping this threshold: (A) Assuming events are enabled for this sensor and this threshold of this sensor, an event is created and is put into the event queue (B) Assuming events are enabled for this sensor and this threshold of this sensor, an alarm condition is recorded in the DAT (C) The event may also optionally (at the discretion of the implementation) be stored in the Resource and Domain Event Logs as appropriate (D) And the event may optionally trigger an Annunciator condition to be raised. This is conditional upon what the rules are for that particular announciator, and what status conditions it considers "announcable". =20 (4) The temperature sensor returns to normal readings (A) Assuming deassert events are enabled for this sensor and this threshold, a deassert event is created and is put into the event queue (B) The alarm condition is removed from the DAT (C ) The deassert event may be added to the event log (implementation-dependent). Not that the assertion event remains in the event log. (D) and the deassertion may optionally remove the Announciator condition. This is conditional upon what the rules are for that particular announciator. =20 If a very similar resource did not provide an Annunciator, the whole scenario would remain the same, except for Steps 1, Step 3D, and Step 4D. =20 Does this help? =20 Charlene =20 =20 The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.=20 ________________________________ From: David Judkovics [mailto:dju...@us...]=20 Sent: Friday, August 12, 2005 6:13 AM To: Todd, Charlene J Cc: Daniel F de Araujo; bil...@mo...; ope...@li...; David M Judkovics Subject: Re: [Openhpi-saf-mib-wg] RE: HPI-MIB: AnnouncementEventLogTable Importance: High =20 Todd, Charlene J wrote:=20 Dan, I think I need a bit more context. What is an AnnouncementEventLog supposed to represent? HPI has the concept of Event Logs, and another concept of Annunicators - but they aren't the same thing. =20 The is so because there is no Event Type Announcement? So I'm not too clear what these tables are meant to map to in the HPI world... Presently we have a table for Announcements under the Event and the EventLog branches of the MIB. Announcements are Created be writing to the Announcement Table under the Event branch.=20 Even though there is no Announcement Event type I believe the reasoning was this is where Announcements will be stored (Event branch). This means they will persist here even if they are ack'd. If they are deleted they should be removed from this table which is different from the other tables under the Event branch. I assumed the Announcement table in the EventLog branch is for the storing any events that may be stored in the HPI EventLog. =20 Are you saying Announcements will never be identified via saHpiEventLogEntryGet()? You seem to be saying no. If this is the case we may not need the table under the EventLog branch. =20 Charlene =20 The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.=20 ________________________________ From: Daniel F de Araujo [mailto:dde...@us...]=20 Sent: Thursday, August 11, 2005 2:37 PM To: bil...@mo...; Todd, Charlene J; ope...@li... Cc: David M Judkovics Subject: HPI-MIB: AnnouncementEventLogTable =20 Bill, Charlene, et al -=20 While inspecting the hpi-mib today, I noticed that the AnnouncementEventLogTable has a few columnar nodes designated as read-create. The problem is that I don't believe there is actually a way to create a new announcement event log through any of the HPI APIs. The closest API that we could use is saHpiEventLogEntryAdd, however, the spec specifically states that the event field must be of type SAHPI_ET_USER. Should the read-create attributes of the announcement event log table be changed to read-only? Reference (line 6164 - 6285): saHpiAnnouncementEventLogSeverity OBJECT-TYPE SYNTAX SaHpiSeverity MAX-ACCESS read-create STATUS current DESCRIPTION "Only used with DAT and Annunciator functions. This is not a valid severity for events or alarms." ::=3D { saHpiAnnouncementEventLogEntry 4 } saHpiAnnouncementEventLogAcknowledged OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION "Acknowledged flag." ::=3D { saHpiAnnouncementEventLogEntry 5 } saHpiAnnouncementEventLogStatusCondType OBJECT-TYPE SYNTAX INTEGER { undefined(0), sensor(1), resource(2), oem(3), user(4) } MAX-ACCESS read-create STATUS current DESCRIPTION "Status Condition Type." ::=3D { saHpiAnnouncementEventLogEntry 6 } saHpiAnnouncementEventLogEntityPath OBJECT-TYPE SYNTAX SaHpiEntityPath MAX-ACCESS read-create STATUS current DESCRIPTION "See Textual-Convention for details." ::=3D { saHpiAnnouncementEventLogEntry 7 } saHpiAnnouncementEventLogSensorNum OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-create STATUS current DESCRIPTION "Sensor associated with status Only valid if saHpiAnnouncementEventLogStatusCondType is sensor(1)." ::=3D { saHpiAnnouncementEventLogEntry 8 } saHpiAnnouncementEventLogEventState OBJECT-TYPE SYNTAX SaHpiEventState MAX-ACCESS read-create STATUS current DESCRIPTION "Sensor event state. Only valid if saHpiAnnouncementEventLogStatusCondType is sensor(1)." ::=3D { saHpiAnnouncementEventLogEntry 9 } saHpiAnnouncementEventLogName OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "AIS compatible identifier associated with Status condition." ::=3D { saHpiAnnouncementEventLogEntry 10 } saHpiAnnouncementEventLogMid OBJECT-TYPE SYNTAX SaHpiManufacturerId MAX-ACCESS read-create STATUS current DESCRIPTION "Manufacturer Id associated with status condition, required when saHpiAnnouncementEventLogStatusCondType is oem(3)." ::=3D { saHpiAnnouncementEventLogEntry 11 } saHpiAnnouncementEventLogTextType OBJECT-TYPE SYNTAX SaHpiTextType MAX-ACCESS read-create STATUS current DESCRIPTION "Field Data. See Definition for SaHpiTextType for more details." ::=3D { saHpiAnnouncementEventLogEntry 12 } saHpiAnnouncementEventLogTextLanguage OBJECT-TYPE SYNTAX SaHpiTextLanguage MAX-ACCESS read-create STATUS current DESCRIPTION "Field Data. See Definition for SaHpiTextLanguage for more details." ::=3D { saHpiAnnouncementEventLogEntry 13 } saHpiAnnouncementEventLogText OBJECT-TYPE SYNTAX SaHpiText MAX-ACCESS read-create STATUS current DESCRIPTION "Field Data. The type of date is specified by saHpiResourceTagTextType and saHpiResourceTagLanguage." ::=3D { saHpiAnnouncementEventLogEntry 14 } saHpiAnnouncementEventLogDelete OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This function allows the HPI SNMP Manager to delete a single announcement. Announcements may be deleted individually by specifying=20 a specific index and setting this columnar node to destroy(6). " ::=3D { saHpiAnnouncementEventLogEntry 15 } Regards, -Dan Daniel F. de Araujo Linux Technology Center Phone: 512-838-5925 Tie Line: 678-5925 =20 |