| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 6355.1 | y | KETJE::PACCO | Horum omnium fortissimi sunt Belgae | Wed Aug 09 1995 23:17 | 165 |
| The problem can be seen on the text field of the notification displayed
by the notification fm of the iconic map.
The following summarises what happens as seen from:
a NOTIFICATION on the fcl_pm
a GETEVENT on the fcl_pm
a dump of that GETEVENT
a NOTIFICATION on the notification_fm (Iconic map).
================================================================================
The notification, as a result of:
NOTIFY DOMAIN .mcc.pl1
!!!!!!!!!!!!!! Alarm, 1995-08-09-21:44:09. !!!!!!!!!!!!!! [1]
Domain: bc:.mcc.pl1 Severity: Warning
Notification Entity: Node bc:.pl1.m.rpl109 HDLC Link rpl110 Logical Station rpl1
10
Event Source: Node bc:.pl1.m.rpl109
Event: Alert
Special notification
Source Event = "Station Initialising"
Source Object = Node bc:.pl1.m.rpl109 HDLC Link
rpl110 Logical Station rpl110
================================================================================
The event received as a result of:
GETEVENT NODE .pl1.m.rpl109 ANY NOTIFICATION EVENT
Node bc:.pl1.m.rpl109
AT 1995-08-09-21:44:08.460 NOTIFICATION EVENTS
Successfully received events:
Event Mode = non-confirmed,
Managed Object = Node bc:.pl1.m.rpl109 ,
Target Entity = Node bc:.pl1.m.rpl109 HDLC Link
rpl110 Logical Station rpl110 ,
Target Severity = Warning,
Probable Cause = CommunicationsSubsystemFailure,
Event: Alert
Special notification
Source Event = "Station Initialising"
Source Object = Node bc:.pl1.m.rpl109 HDLC Link
rpl110 Logical Station rpl110
================================================================================
I the out_p dump of the same getevent :
MCC> getevent node .pl1.m.rpl109 any notification event
*****************************************************
* FCL PM Arguments before call_function: *
*****************************************************
VERB code: 65
PARTITION code: 16
AES dump of ENTITY IN:
Depth=0 Class = 1 Instance = bc:.pl1.m.rpl109 Id = 1 Dt = 5
ILV dump of IN_P: in_p is NULL
ILV dump of IN_Q: in_q is NULL
TIME SPEC is: 0, NOW
**********************************************
FCL PM Arguments on return from call_function:
CVR returned:
%MCC-S-RESPONSE, success with response reply
ILV dump of OUT_P:
[ 1 ] (
[ 2 ] 01
[ 3 ] (
[ 65535 ] 01 00 00 00 01 00 01 00 24 00 0e 02 30 00 00 00 22 00
00 01
01 00 00 00 05 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 08 00 2b 2c 79 1e 09 75 37 b2 2b f5
95 00 12 00 01 03 70 6c 31 01 01 6d 01 06 72 70 6c 31 30 39
00 00 00 00
)
[ 4 ] (
[ 65535 ] 01 00 00 00 01 00 01 00 24 00 0e 02 30 00 00 00 22 00
00 01
01 00 00 00 05 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 54 00 00 00 08 00 2b 2c 79 1e 09 75 37 b2 2b f5
95 00 12 00 01 03 70 6c 31 01 01 6d 01 06 72 70 6c 31 30 39
00 00 00 00 03 00 00 00 01 01 01 00 00 00 0e 02 84 00 00 00
00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00
00 00 00 00 00 00 00 00 84 00 00 00 01 00 00 00 01 02 01 00
08 00 0e 02 b4 00 00 00 08 00 00 01 00 00 00 00 04 00 00 00
00 00 00 00 01 06 72 70 6c 31 31 30 00 1a 80 21 bc 00 00 00
01 06 72 70 6c 31 31 30 00 00 00 00 01 03 01 00 08 00 0e 02
ec 00 00 00 08 00 00 01 00 00 00 00 04 00 00 00 00 00 00 00
01 06 72 70 6c 31 31 30 51 41 37 21 00 00 00 00 01 06 72 70
6c 31 31 30
)
[ 5 ] 04
[ 6 ] 06
[ 1 ] (
[ 100 ] (
[ 1 ] 53 74 61 74 69 6f 6e 20 49 6e 69 74 69 61 6c 69 7
3 69 6e 67 -- Station Initialising
[ 2 ] (
[ 65535 ] 01 00 00 00 01 00 01 00 24 00 0e 02 3
0 00 00 00 22 00 00 01
01 00 00 00 05 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00
00 00 00 00 54 00 00 00 08 00 2b 2c 79 1e 09 75 37 b2 2b f5
95 00 12 00 01 03 70 6c 31 01 01 6d 01 06 72 70 6c 31 30 39
00 00 00 00 03 00 00 00 01 01 01 00 00 00 0e 02 84 00 00 00
00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 23 00 00 00
00 00 00 00 00 00 00 00 84 00 00 00 01 00 00 00 01 02 01 00
08 00 0e 02 b4 00 00 00 08 00 00 01 00 00 00 00 04 00 00 00
00 00 00 00 01 06 72 70 6c 31 31 30 00 1a 80 21 bc 00 00 00
01 06 72 70 6c 31 31 30 00 00 00 00 01 03 01 00 08 00 0e 02
ec 00 00 00 08 00 00 01 00 00 00 00 04 00 00 00 00 00 00 00
01 06 72 70 6c 31 31 30 51 41 37 21 00 00 00 00 01 06 72 70
6c 31 31 30
)
)
)
)
AES dump of ENTITY OUT:
Depth=0 Class = 1 Instance = bc:.pl1.m.rpl109 Id = 1 Dt = 5
================================================================================
And what is seen on the notification fm of the Iconic MAP:
(I have writtin it from the detailed window).
The request was:
NOTIFY DOMAIN .mcc.pl1
Domain: Domain bc:.mcc.pl1
Entity: Node bc:.pl1.m.rpl109 HDLC Link rpl110 Logical Station rpl110
Event Source: Node bc:.pl1.m.rpl109
Severity: warning
Timestamp: 1995-08-09-21:44:09.198
Text: ~ ,Unknown probable cause 3
(There are also some binary characters before ~)
Details:
Successfully received events:
Alert
Special Notification
Event Mode non-confirmed
Managed Object Node bc:.pl1.m.rpl109
Target Entity Node bc:.pl1.m.rpl109 HDLC Link rpl110 Logical Station rpl110
Target Severity Warning
Probable Cause CommunicationsSubsystemFailure
Source Event Station Initialising
Source Object Node bc:.pl1.m.rpl109 HDLC Link rpl110 Logical Station rpl110
|
| 6355.2 | Put information in event data field, not in getevent arguments | TAEC::FLAUW | Marc Flauw, TeMIP Technical Office, VBO | Wed Aug 16 1995 16:49 | 32 |
| Dominique,
# Class (1) : NODE
# Directive (6) : GETEVENT
# -----> Response (8) : GETEVENTSUCCESS
# Definition (3) : PRESENTATION_NAME
# Definition (3) : REPLY_TEXT
# Argument (4) : GETEVENTRESPONSE 1
# Argument (4) : EVENTMODE 2
# Argument (4) : MANAGEDOBJECT 3
# Argument (4) : TARGETENTITY 4
# Argument (4) : TARGETSEVERITY 5
# Argument (4) : PROBABLECAUSE 6
Why do you want to add additional arguments to the getevent response ? Why
not defining these arguments as arguments of the event data ?
If you want to use TeMIP Alarm Handling in the future, you need to follow
the format of OSI Alarms as defined in TeMIP documentation. ManagedObject,
PerceivedSeverity and ProbableCause are mandatory fields (in the event
data) for an OSI alarm.
I would recommend you to use that format instead of changing the getevent
response. If you need to post as part of the event generated the original
event, then the additional info field is perfectly suited for that job.
Contact me off-line if you need more details.
Best regards,
Marc.
|
| 6355.3 | Notification now much better. | KETJE::PACCO | Horum omnium fortissimi sunt Belgae | Thu Aug 17 1995 19:30 | 53 |
| A more detailed explanation of the error and its context
as I see it.
If a notification event is in OSF format (I assume the
attribute OSI_mode is saying this) all arguments of
the notification HAVE to be according what is shown in
osi_alarms.ms . This means an argument with
code 1 ALWAYS means managed object (Mandatory)
code 2 ALWAYS means event type (Mandatory)
code 3 ALWAYS means probable cause. (Mandatory)
code 4 ALWAYS perceived severity
etc ...
In my example code 3 was not used, only 1 and 2 were used,
and then even for other purposes. (I am still learning
by trying to do a real exircise).
As this argument was mandatory, the decoding routines went somehow
slightly eroneous, and tried to put an error message in the
text field. This field for OSI alarms contain the concatenation of
Event-type (code 2) and probable cause (code 3).
I changed the structure of the notification event,
to more align it with the OSI alarms (as described in
osi_alarms.ms), and now the additional text appears clearly.
The behaviour of this was not very easy to understand.
In fact the 'Text' field of the notification was composed, even
with WRONG data types for the elementary arguments.
And this was difficult to understand.
Documentation is also rather poor on explaining such details.
My new notification now shows:
==============================
Domain: Domain bc:.mcc.pl1
Entity: Circuit bc:.mcc.rpl109-rpl110 Endpoint A
Event Source: Circuit bc:.mcc.rpl109-rpl110 Endpoint A
Severity: warning
Timestamp: 1995-08-17-18:10:49.178
Text: CommunicationsAlarm, CommunicationsSubsystemFailureOt
Details:
Event Time 1995-08-17-18:10:49.178
Event Type CommunicationsAlarm
Additional Text Station Initialising
Managed Object Node bc:.pl1.m.rpl109 HDLC Link rpl110 Logical Station rpl110
Probable Cause CommunicationsSubsystemFailure
Perceived Sev Warning
|
| 6355.4 | Look at TeMIP Reference Guide for more info | TAEC::FLAUW | Marc Flauw, TeMIP Technical Office, VBO | Fri Aug 18 1995 09:53 | 18 |
| Dominique,
You can find a good description of an OSI alarm, along with mandatory fields and
how to encode one in the TeMIP Reference Guide.
Have a look in either :
- TAEC::TEMIP$PUBLIC:[DOC.OSF.TEMIP.V200]
- unitel /pub/osf/temip/V200/doc
and look for temip_ref (.ps or .decw_book).
If you use TeMIP Alarm Handling, wrongly formatted OSI alarms will be rejected
and an appropriate error message is printed in the trace file of the Operation
Context.
Best regards,
Marc.
|