Conference azur::mcc

3541.0. "procedure to close an event" by ANNECY::HAGENMULLER (EIC Annecy - dtn 7887.41.99) Wed Aug 12 1992 05:23

We are answering to a RFP for SNCF (french railway company) who wants to
manage its telephone network (about 400 inteconnected PBX).
One of their main requirement is related to the "life cycle" of an event :

	when a problem occurs on a remote PBX an event (let's say event A) is 
	sent to the network management station (DECmcc for us) and the 
	corresponding PBX's icon must change color (assume red) blink.

	After a while, a remote (local to the PBX) operator acknoledges the
	problem (that is to say he is aware of the problem and will try to 
	to solve it) and an acknoledgement is sent to DECmcc in the form of a
	new event (let's say event B) : DECmcc must perform a correlation 
	between event A and event B and the PBX's icon must keep it's initial
	color but stop blinking.

	When the problem is eventually solved :

		- a final event (event C) is sent to DECmcc in order to clear
	the icon's color : DECmcc must still perform a corellation between
	event C and event A.

	OR

		- the network manager may decide himself to close the problem :
	by selecting event A he should be able to close it (namely to run a 
	procedure which will perform some tasks).


We are wondering whether DECmcc is able to manage such a event life cycle :
correlation between different events is possible through different fields
(text, event id ,...), but we don't known how to answer the following questions:

	- is there a way a network administrator can select an event and close
	it (for us this mean the possibility to run a procedure and give it 
	the PBX name and complete event A) (any idea even the writting of an FM 
	will be studied (seems that some information about an event is lost by
	the standard Alarm FM of DECmcc ?))
	The idea behind is to allow the network manager to keep for each
	problem 3 times (beginning, acknoledge and close) and to produce
	statistics on the unavailibility of the PBXs or the average time
	elapsed before a problem is acknoledged ...

	- is there a way to make an icon blink when an event is not acknoledged
	yet ?


In an other area we wonder if the child entities of an entity (for instance each
multiplexed circuit for a PBX) can be represented by different icons on the 
iconic map rather than text when one click with the mouse on the parent entity
icon (one way to achieve this is to use the data collector and define each PBX
as a domain and each circuit as a data colector entity type, but we would avoid
this workaround).

thanks in advance for any input.
Christophe.

Christophe,

What you are trying to solve looks exactly like what we have designed TeMIP 
Alarm Handling for : being able to follow the life cycle of both an alarm and 
a problem. 

Having the acknowledgement and problem follow-up done remotely is in that case 
the difference. 

I suggest that you have a look at the TEMIP Introduction manual, located on 
TAEC::TEMIP$PUBLIC:[DOC]TEMIP_INTRO_BFT_DRAFT.PS  and in the TeMIP notefile 
TAEC::TEMIP to see how TeMIP might answer your problem. 

We can then continue this discussion. 

Best regards,

Marc.

Hello Marc,

Thanks for your answer. I'd already looked at the TEMIP doc and notesfile but 
I haven't find the accurate answer to our problem (we need to log the exact 
time when the event is generated, acknoledged and closed in order to produce
different reports : stat and so on).

Furthermore TEMIP is currently in a pre-field test state (as Claude HARY told 
me a couple of days ago) and our customer wants to use his station before
end of this calender year. 

Anyhow , there are perhaps some features unknown to me (TEMIP doc given
numerous details except for the way you can launch procedure from the menus)
that could fullfill our need. I will call you in valbonne.

any other input with standard DECmcc is still wellcomed.

Ch.

re: -.2


	Most of the answers to -.2 have already be provided to Christophe 
	off-line, but for the sake of the other readers of this notefile -), 
	let me summarize my answers.

	TeMIP stores the time the event was generated (Event Time), received 
	(Alarm Object creation time), acknowledged and terminated. 

	With TeMIP V1.0-B, you will be able to archive the Alarm Objects in an 
	Ultrix/SQL database in order to produce reports on them.

	TeMIP V1.0-A will go to External FT at the end of the week and is 
	planned for SSB in November.

	TeMIP provides both an FM and a PM for Alarm Handling and TeMIP Alarm 
	Handling FM can as any other FM, be called by any application using 
	mcc_call.

	Hope this helps,

	Marc.