| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1159.1 | Why the 'data' from the Change-Of function is in 'reverse' order | NANOVX::ROBERTS | Keith Roberts - DECmcc Toolkit Team | Tue Jun 18 1991 10:23 | 15 |
| Bill, The reason the data from the Change-Of function comes out in 'reverse'
order .. is due to the placement of the operands in the binary tree.
The code simply walks through the tree looking for 'data', then builds
a list of the data which was found. It just 'happened that way'.
I'm sure this could be changed - the tree would still be walked through
the same way, but the data could be sorted by time-stamp ... In the
future when Rule Expressions can be more complex, then all the data would
appear chronologically.
I no longer work on the Alarms team - Anil Navkal would call-the-shot.
Keith
DECmcc Toolkit Team
|
| 1159.2 | re .0 | GRANPA::DCOMFORT | Spent a little time on the mountain | Tue Jun 18 1991 11:32 | 60 |
| Hi,
I am on-site at SmithKline Beecham and setting up an MCC station. I
have recently installed BMS and DIR v1.1 and with this new version I
believe the change_of function produces the data in the order for which
you desire. Eg.
#1 14-JUN-1991 02:19:42.27 MAIL
From: PHMCC::COMMSYS "Area Reachability Report"
To: @MCC_AREA_ALARMS:AREA_MAIL_LIST.DIS
CC:
Subj: Area Reachability Report
Rule name: MCC 0 ALARMS RULE AREA_23
Detected at: 14-JUN-1991 02:19:19.19
Category: Area Reachability
Description: Area Reachability Report
Expression: (change_of(node4 phx25 area 23 state,*,*), at every
00:15:00)
Data: Node4 1.20 Area 23 State = Reachable 14-JUN-1991
02:04:19.11
Node4 1.20 Area 23 State = Unreachable 14-JUN-1991
02:19:18.99
...and (later that same day)...
#8 14-JUN-1991 05:34:37.36 MAIL
From: PHMCC::COMMSYS "Area Reachability Report"
To: @MCC_AREA_ALARMS:AREA_MAIL_LIST.DIS
CC:
Subj: Area Reachability Report
Rule name: MCC 0 ALARMS RULE AREA_23
Detected at: 14-JUN-1991 05:34:19.20
Category: Area Reachability
Description: Area Reachability Report
Expression: (change_of(node4 phx25 area 23 state,*,*), at every
00:15:00)
Data: Node4 1.20 Area 23 State = Unreachable 14-JUN-1991
05:19:18.99
Node4 1.20 Area 23 State = Reachable 14-JUN-1991
05:34:19.00
As far as the other situation where say a previously unknown area comes
on line, the OCCURS function in BMs/DIR v1.1 may help out.
(occurs(node4 phx25 area * Area Reachability Change))
I have not yet had the time to check this out as far as the mail
message that is generated, however it looks good.
Regards,
Dave Comfort
|
| 1159.3 | Some like it in the pot, nine days old! | WAKEME::ANIL | | Thu Jun 20 1991 13:52 | 18 |
|
Bill,
The order in which the data is to be printed in a matter of
personal choice. If we choose one way, we are certain to make
x% customer unhappy. I have no idea if printing data in ascending
order of time will make more that 50% users happy. The work involved
in printing the data one way as against the other is trivial.
Make up your mind and tell us which way you want to see the output
and we will do what you tell us. And yes I agree, we better be constant
when we print that data! :-)
Regards,
Anil Navkal
|
| 1159.4 | let the user choose | STAR::ROSENBERG | Duvie - On a buffalo wing and a prayer - ZKO3-2/Y05 (2Y08) - 381-1517 | Thu Jun 20 1991 15:34 | 11 |
| Anil,
If in fact it is relatively simple to order the information in either ascending
or descending order, make ~100% of the users happy by letting them select the
ordering.
I do not know what customization options are available to you, but I believe
you will get the biggest bang (or round of applause) for the implementation
buck if you do so.
Dave
|
| 1159.5 | | TOOK::STRUTT | Management - the one word oxymoron | Mon Jun 24 1991 17:27 | 17 |
| re: .4
.4> If in fact it is relatively simple to order the information in either ascending
.4> or descending order, make ~100% of the users happy by letting them select the
.4> ordering.
I believe this is the *wrong* way to think. Adding in the choice can
end up making more people unhappy, as they now have more options to
learn.
(Sorry to throw stones, but...) that's exactly how VMS got into
trouble, by adding so many sysgen parameters, rather than making hard
choices!
We want people to manage networks (or enterprises) - not have to learn
how many differnt ways they can configure MCC.
Colin
|
| 1159.6 | hide complexity yet provide flexibility | ENUF::GASSMAN | | Thu Jun 27 1991 15:24 | 8 |
| Another alternative is to make the engineering choice the default, but
allow changed to be made by services or the customer an option. That
way they don't have to deal with the complexity, but yet if they really
want to, they can. The remedy trouble ticket system uses this
approach. They give you the view of the data they feel is right, yet
let users design their own views to meet their needs.
bill
|