| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3948.1 | suggestion forwarded, thanks | MCC1::DITMARS | Pete | Wed Oct 28 1992 13:09 | 2 |
| I've forwarded your suggestion to the person responsible for
the alarms FM. It has been discussed before.
|
| 3948.2 | Extra functions in alarm rules | SEDSWS::MALLOY | | Wed Oct 28 1992 18:09 | 57 |
| Dave
-----
You are right . DECmcc is limited two states.
The value is checked and if the expression is TRUE then the icon
changes colour.
If expression can not evaluated then a exception is caused.
ie DECmcc can reach the target entity
My feeling is that a Exception, should be related to the Internals of
DECmcc . i.e. expression can evaluated because time interval is incorrect,
or internal error within Node4 AM,
or Node is not registered etc.
The alarm rules should allow the user to decide which state the
icon should change to.
+++++++++++++++++++
The polling alarm rules should be extended.
expression true state = clear
expression true procedure = mcc_common:xxxxxx
expression false state = minor
expression false procedure = mcc_common:uuuuuuu
Entity unreachable state = critical
Entity unreachable procedure = mcc_common:zzzzzz
expression exception state = critical
expression exception procedure = mcc_common:yyyyyy
+++++++++++++++++++
This would make the polling alarm rules more power and more flexible.
One rule performs several functions.
The other pain with the present rule structure .Is that when a command
file is submit to the batch queue, NO queue parameters can be passed
/noprint/nolog
/log=mcc_log: etc
++++++++++++++++=
Extra functions is need in all alarm rules types.
queue = sys$batch
queue parameters = noprint,nolog
+++++++++++++++++
T am only a customer service engineer in the field .
So this is only a view point from the my world.
Gary Malloy
|
| 3948.3 | Alarm acknowledgement | HLRG02::NOTES | | Thu Oct 29 1992 04:36 | 11 |
| > -< Extra functions in alarm rules >-
Hi,
I appreciated if DECmcc will implement the 'Alarm Acknowledgement' function in
the notification services. Customers are asking for this feature.
I know in TeMIP this is already done but this is not on VMS.
/-/ Henk.
|
| 3948.4 | and why not TeMIP on VMS ? | TAEC::FLAUW | | Fri Oct 30 1992 06:45 | 24 |
| Henk,
>I appreciated if DECmcc will implement the 'Alarm Acknowledgement' function in
>the notification services. Customers are asking for this feature.
>I know in TeMIP this is already done but this is not on VMS.
>
>
>/-/ Henk.
If this functionality is already developped in TeMIP, I don't see the point
in asking for it to be re-developped in DECmcc, just to have it available
on VMS -). In a period where every cent is important, I don't think that
duplicating functionality is the right direction to take. It might be easier to
port TeMIP to VMS.
If you think it is important to have TeMIP functionalities on VMS, please send
concrete examples and business figures to TeMIP Product Manager Claude Hary,
(ULYSSE::HARY). It has not been put in our plans so far, as following business
plan analysis, in the Telecom, Ultrix is more asked for than VMS.
Best regards,
Marc.
|
| 3948.5 | What is TeMIP | SEDSWS::MALLOY | | Fri Oct 30 1992 17:11 | 6 |
| Henk or Marc
What is TeMIP ???????????????????
Gary
|
| 3948.6 | More info on TeMIP | TAEC::FLAUW | | Thu Nov 05 1992 03:25 | 61 |
|
re: -.5
TeMIP is a product developped on top of DECmcc/Ultrix, providing fault
management capabilities on top of the alarm/notifications services. TeMIP runs
on Ultrix only.
The first version TeMIP V1.0 has been in FT since August 92 and will be in SSB
in a few days. It consists of the following modules :
- Alarm Handling FM
This module manages Operation Context objects. An Operation context is a
context of collection and management of alarms, defined by the domain tree to
which it applies, a Discriminator contruct (filter allowing you to collect
only some specific alarms) and a scheduling package to specify when you want
the collection to take place.
For each Operation Context, the collected alarms are transformed into alarm
objects, allowing to keep a status of the alarms (outstanding, acknowledged,
...), to provide operations on the alarms like acknowledgement, clearance,...
and to associate them with trouble tickets.
The alarms collection for OC is done in background mode even if no operator
is logged in. A same operation context can be shared by multiple operators
and if an operator acknowledges an alarm in 1 OC, all the other operators
using this OC will see the acknowledgement.
- Event Log FM :
This module manages the ISO Log objects. It provides event logging
capabilities for ISO events and alarms. As for Operation Context, it is
associated with a domain tree, a Discriminator construct and a
scheduling package.
It runs also in background mode.
- TEMIP NMS PM :
We provide a specific Motif X-windows PM acting in association with the
Iconic Map PM to display alarm objects and log records. This PM also offers a
graphic UI for setting filters (DC) and sheduling packages.
The new version of TEMIP (V1.1) will be soon in FT and will use DECmcc V1.3.
This version will provide the following modules :
- Trouble Ticket FM +PM
This module provides a Trouble Ticketing function, which is the follow-up of
problems. Trouble ticketing can work stand-alone or in conjonction with the
Alarm Handling FM. It uses a Ultrix-SQL database to store its information.
A Motif X-windows PM will also be provided to manage the TT FM functions.
If you need more information, please feel free to ask directly myself or
Claude Hary (ulysse::hary) who is the product manager.
You can also ask questions in the TeMIP notefile (TAEC::TEMIP).
Best regards,
Marc.
TeMIP V1.0 Project Manager
|