[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

4830.0. "Problems with independently developed AM, Event order reversed" by FRAIS::ORCHIS::MAASS (Information, that's all I need...) Tue Apr 06 1993 13:39

Hi all,

back from holiday and into the mud! I have a customer (a big software house (is
that correct?)), that develops a management solution for the reservation appli-
cation of the european railways. This application runs on IBM and Siemens hosts
in eleven countries all over Europe and will be managed using DECmcc.

Now here comes the problem: the AM is running, the application is generating two
events (Application Up and Application Down) with a gap of two seconds between the
events. However, when looking at the DECmcc notification window, the events seem
to arrive in reverse order.

The network between the management station and the application host is a piece of
Ethernet cable, according to the customer.

I'm stunned. I'll include logfiles and information and hope that maybe you can
help me out.


Thanks a lot in advance



Josch

==================================================================================


MSL Definition File

EVENT PARTITION NOTIFICATION EVENTS = 16 :
  (* This partition contains ALARM events *)

	EVENT UICAPPL Remote Production Down = 9331 :
		DISPLAY = TRUE,
		SYMBOL = UICAPPL_REM_PRODN_DOWN,
	END EVENT UICAPPL Remote Production Down;

	EVENT UICAPPL Remote Production Up = 9332 :
		DISPLAY = TRUE,
		SYMBOL = UICAPPL_REM_PRODN_UP,
	END EVENT UICAPPL Remote Production Up;


Alarm Rule Definitions

CREATE DOMAIN UIC_NS:.D6 RULE UICAPPL_REM_PRODN_DOWN -
	EXPRESSION = (OCCURS(Pro * UICAPPL * UICAPPL Remote Production Down)), -
	SEVERITY   = Major, -
	CATEGORY   = "UICAPPL ALARMS", -
	DESCRIPTION = "Remote production Application down", -
	ALARM FIRED PROCEDURE	= DKA300:[MCC_HSUP.DCL]HSUP_ALARMS_ALL_ALARM.COM,-
	ALARM EXCEPTION PROCEDURE = DKA300:[MCC_HSUP.DCL]HSUP_ALARMS_LOG_EXCEPTION.COM,-
	ALARM FIRED PARAMETERS = "BROADCAST=APPLSUP,MAIL=APPLSUP",-
	BATCH QUEUE = "MCC$BATCH"
!
!
CREATE DOMAIN UIC_NS:.D6 RULE UICAPPL_REM_PRODN_UP -
	EXPRESSION = (OCCURS(Pro * UICAPPL * UICAPPL Remote Production working)), -
	SEVERITY   = Major, -
	CATEGORY   = "UICAPPL ALARMS", -
	DESCRIPTION = "Remote production Application down", -
	ALARM FIRED PROCEDURE	= DKA300:[MCC_HSUP.DCL]HSUP_ALARMS_ALL_ALARM.COM,-
	ALARM EXCEPTION PROCEDURE = DKA300:[MCC_HSUP.DCL]HSUP_ALARMS_LOG_EXCEPTION.COM,-
	ALARM FIRED PARAMETERS = "BROADCAST=APPLSUP,MAIL=APPLSUP",-
	BATCH QUEUE = "MCC$BATCH"


Event Sink Time Stamps (as logged by the application before sending the event)
	
Event 9332 (Remote Production Up)
18-MAR-1993 12:17:36.49

Event 9331 (Remote Production Down)
18-MAR-1993 12:17:38.62


Notification Application Details (as seen in the notification Application window)

ID	Alarm			Event Time	Timestamp
--	-----			----------	---------

44	UICAPPL_REM_PRODN_DOWN	12:17:44.58	12:17:49.83
45	UICAPPL_REM_PRODN_UP	12:17:40.62	12:18:20.79

Now, the timely order of the events seems to be reversed, even though the Event
Times reflect the correct order. Is this a normal behaviour or does it reflect
some unexpected behaviour of DECmcc? I haven't found any explanation of the dif-
ference between Event Time and Timestamp except that Event Time specifies the
time when the event happened and Time Stamp reflects the time the listing was
requested. I wasn't able to reproduce the problem with a test rule looking for a
change in the Seconds Since Last Zeroed counter of a DECnet circuit.

Can you shed some light?


Thanx in advance



Josch
T.RTitleUserPersonal
Name
DateLines
4830.1??MCDOUG::dougpre-retinal integrationTue Apr 06 1993 14:0112
Please don't take this the wrong way, but have you done a code inspection
or debug run of the application that's *sending* the event to make certain
that the event codes & symbols for UP/DOWN aren't *swapped* ?  Also be sure
to verify that the code that's creating the logfile text doesn't have the
actual *text* swapped (i.e. it writes "up" when it means "down" and vice
versa).

I know it sounds silly, but I can't think of much else that would account
for such a complete reversal of expected output...

/doug