[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
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.R | Title | User | Personal Name | Date | Lines |
---|
4830.1 | ?? | MCDOUG::doug | pre-retinal integration | Tue Apr 06 1993 14:01 | 12 |
| 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
|