[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

5344.0. "Help ! NOTIFY response Event or OSI event..." by TOSKI::HAYES (Keep trying ! C.Hayes ALF 385-2988) Thu Jul 15 1993 14:28


	Hello,


	I have a third party trying to encode an OSI event.
	They are using TeMIP include files to do this
	osi_alarms.ms and MCC getevent file mcc_getevent_directive.ms.

	The getevent is working now, the notify domain also,
	but it seems the Notification FM is encoding a response EVENT (
	code 8 in ILV dump) instead of a response OSIEVENT (code 7 in the 
        ILV dump of the Notify response).

	The question is simple :
	What could make the Notification FM decide to encode an EVENT
	instead of an OSI event, according to the response to the getevent
	it does.
	This will help us correct our code.

	See attached a dictionary dump of the notify response try to explain
	what I am talking about...
		
		Thanks to help
	
	
			Catherine

   Class (1) : DOMAIN
---> Directive (6) : NOTIFY
       Definition (3) : DIRECTIVE_TYPE
       Definition (3) : DISPLAY
       Definition (3) : CATEGORIES
       Definition (3) : PRESENTATION_NAME
       Request (7) : NOTIFY 121
       Response (8) : NOMORE 2
       Response (8) : ENTITYPARTIALSUCCESS 4
       Response (8) : OCCURRENCEPARTIALSUCCESS 5
       Response (8) : NOTIFICATIONSTARTED 6
       Response (8) : OSIEVENT 7 ---> This is the response we want to get
       Response (8) : EVENT 8    ---> This is the response we get instead !
       Exception (9) : UNABLETOCONTINUE 1
       Exception (9) : GETEVENTLOST 2
       Exception (9) : ENROLLMISSING 3
       Exception (9) : UNABLETOINTERPRET 7
       Exception (9) : NOTABLES 8
       Exception (9) : UNABLETOGETPRIMARYIDENT 11
       Exception (9) : ERRORDETERMININGDOMAINCONTENTS 12
       Exception (9) : NONOTIFICATION 13
       Exception (9) : NOEVENTS 14
T.RTitleUserPersonal
Name		DateLines
5344.1Check presence of Osi Mode argumentTAEC::LAVILLATFri Jul 16 1993 03:5440
Catherine,

You forgot about the TESTOBJ AM ?!?!

Seriously, I think what make the difference is the OSI MODE argument you have
to add in the getevent response (See getevent MSL files supplied in T1.1.1
TeMIP kit).

So a GETEVENT response for an OSI event should be something like :


ILV dump of OUT_P:

[  1 ] (
    [  1 ] (
        [  1702 ] (
            [  4 ]             01
            [  3 ]             00
            [  9 ] (
                [  65535 ]                 1a 00 00 00 01 00 01 00 18 00 0e 02 3
0 00 00 00 15 00 00 01
                01 00 00 00 05 00 00 00 00 00 00 00 1a 00 00 00 00 00 00 00
                00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
                00 00 05 00 01 01 61 00 00 00 00 00
                )
            [  1 ]             02
            [  2 ]             0c a4 cd 34 99 81 cc 01 ff ff ff ff ff ff 78 10
            )
        )
    [  2 ]     00
    )

Check that you have the [ 2 ] argument supplied in the response, and then you
should be Ok.

Regards.

Pierre.
5344.2confirmed instead of non-confirmed ?TOSKI::HAYESKeep trying ! C.Hayes ALF 385-2988Fri Jul 16 1993 10:0618
    
    
    	Thanks Pierre,
    
    	No the TESTOBJ_AM is still in my heart !
    
    	They have the encoded the OSI_Mode, but encoded non-confirmed
    	instead of confirmed :
    
    	[2] 01
    
    	Can this be THE problem ?
    
    
    		Thanks
    
    
    			Catherine
5344.3Should beTAEC::LAVILLATFri Jul 16 1993 11:386
So , try [2] 00

and you will see...

Pierre.
5344.4Are Notif FM authors sleeping ??TOSKI::HAYESKeep trying ! C.Hayes ALF 385-2988Fri Jul 16 1993 15:2214
    
    
    	Does not help, still [8] istead of [7].
    
    	Hey, MCC framework notification FM folks, any other ideas ? 
    
    	I cannot believe everyone forgot the Notification FM code !!
    	
        Customer is on the verge of shutting down MCC or TeMIP 
    	evaluation because of this stupid poblem.
    
                ...
5344.5MODE argument is needed.TOOK::CALLANDERMCC = My Constant CompanionMon Jul 19 1993 14:2515
    Well pierre is on the right track.  The notification FM looks for
    the getevent response argument code 2 (defined as the mode
    argument) to determine if it is an OSI event or not.  Mode can
    have a value of confirmed or nonconfirmed.  
    
    Two things to note:
    	1) this mode argument is a getevent response argument and *NOT*
           an argument of the event report.
    	2) I am pretty sure this is documented in the latest copy of
    	   the notification MRM.
    
    hope this helps.
    
    jill
5344.6Does not work...TOSKI::HAYESKeep trying ! C.Hayes ALF 385-2988Mon Jul 19 1993 14:51143

	Jill,


	Thanks for your help sofar.

	However, They have according to me and their attached ILV dump 
        correctly encoded the OSI_Mode, they have used [ 2 ] 00 
	and this outside the event report as needed.

	So, I still do not understand...note that I read the notification FM
	MRM though.

	1) Could it be because they also encoded Managed Object, Target
	Severity, and Target Entity.
	Pierre L. also suggested them to remove those last 3.
	I will let you know if it works as soon as they have tried. 

	2) in their out_entity, they have an AES of
	datatype internet name equal to the one returned in out_entity
	of the show all identifier.

	Do you have any other idea ? I attached an ILV dump of
	the getevent response and an ILV dump of the Notify domain response.

	It must be a tiny little stupid error but I hate to think they
	could stop their MCC/TeMIP evaluation because of this.

	Do you have another suggestion ?

        Should you need more information, I have their getevent code, 
	their MSL...


		Again thanks


	
			Catherine DTN 385-2988
	
		
Dump of the getevent response : OSI_Mode is correctly encoded



[  1 ] (
    [  1 ] (
        [  1711 ] (
            [  9 ] (
                [  0 ] (
                    [  1 ]                     01
                    [  2 ]                     07 c9
                    [  3 ]                     03
                    [  4 ]                     4a  -- J
                    [  5 ]                     64 65 63 64 65 6d 6f  -- decdemo
                    )
                )
            [  1 ]             0b
            [  2 ]             a8 ad 67 9a df 81 cc 01 ff ff ff ff ff ff d4 1e
            [  3 ]             13
            [  4 ]             01
            )
        )
    [  2 ]     00   ---> Correct OSI_Mode
    [  3 ] (
        [  0 ] (
            [  1 ]             01
            [  2 ]             07 c9
            [  3 ]             03
            [  4 ]             4a  -- J
            [  5 ]             64 65 63 64 65 6d 6f  -- decdemo
            )
        )
    [  4 ] (
        [  0 ] (
            [  1 ]             01
            [  2 ]             07 c9
            [  3 ]             03
            [  4 ]             4a  -- J
            [  5 ]             64 65 63 64 65 6d 6f  -- decdemo
            )
        )
    [  5 ]     01

----------------------------------------------------------------------------
Extract of the TeMIP trace : for an OSIEVENT notify domain response
I should have [ 7 ] instead of [ 8 ]:

BG CHILD collect-filter thrd received NOTIFY response DIFFERENT FROM OSI EVENT 

[  8 ] ( 
    [  1 ] ( 
        [  1 ]         03 26 80 49 
        [  2 ]         41  -- A
        [  3 ] ( 
            [  0 ] ( 
                [  1 ]                 01 
                [  2 ]                 07 c9 
                [  3 ]                 01 
                [  4 ]                 05 
                [  5 ]                 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 00 01 0a 63 72 
                6f 73 73 6e 65 74 64 64 00 00 
                )
            )
        [  4 ] ( 
            [  1 ] ( 
                [  1 ] ( 
                    [  1711 ] ( 
                        [  9 ] ( 
                            [  0 ] ( 
                                [  1 ]                                 01 
                                [  2 ]                                 07 c9 
                                [  3 ]                                 03 
                                [  4 ]                                 4a  -- J
                                [  5 ]                                 64 65 63 64 65 6d 6f  -- decdemo
                                )
                            )
                        [  1 ]                         0b 
                        [  2 ]                         c0 37 9e 99 df 81 cc 01 ff ff ff ff ff ff d4 1e 
                        [  3 ]                         13 
                        [  4 ]                         01 
                        )
                    )
                )
            )
        )
    [  2 ]     00 
    [  3 ] ( 
        [  1 ] ( 
            [  0 ] ( 
                [  1 ]                 01 
                [  2 ]                 07 c9 
                [  3 ]                 01 
                [  4 ]                 05 
                [  5 ]                 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0e 00 01 0a 63 72 
                6f 73 73 6e 65 74 64 64 00 00 
                )
            )
        )
    [  4 ]     10 
    )
5344.7Fixed - Thanks...TOSKI::HAYESKeep trying ! C.Hayes ALF 385-2988Wed Jul 21 1993 18:2324
    
    
    	Houra !
    
    
    	You were all right...
    
    	In fact the customer was using the design framework
    	mcc_desframe_set_cvr_and_reply.
    
    	He build a correct argument including both the event report and
        the OSI_Mode which he dumped and seemed correct.
    
    	But we found out that this mcc_desframe_set_cvr_and_reply
    	(V1.2) rebuild an out_p with had the event report but
    	not the OSI_Mode....
    
    	In the past, this routine did not know how to handle
    	ILV native, I assume it can handle half of it now...
    	
    
    	Thanks a lot to Pierre and Jill
    
    			Catherine
5344.8Question on EVENTS and OSI EVENTSEVTIS9::ROGGEBANDWhile my guitar gently weepsThu Jul 22 1993 07:1725
    Hi,
    
    All the previous exchange prompts me to ask a question: by using OSI
    event reports rather than the "standard" event reports, can I specify
    an event severity? If so, is the MRM the place to look for
    documentation on this? 
    
    I am currently involved in a project with Alcatel, where they have 5
    events, which map onto the current state of the object. Unfortunately,
    all these events light up the icon with an "undeterminate" color. They
    do not want to use notification services to redefine the event severity
    because the final project will use a specific notification window which
    they are developping. 
    
    We tried to use alarm rules to set the severity, but this causes the
    icon to turn "indeterminate" for a few seconds and then only take on
    the correct color after the appropriate rule fires. this is considered
    unacceptable. 
    
    So, the OSI event which includes a severity field may be the way to go
    if the notification FM handles it. Can anyone confirm all the above?
    
    Thanks,
    
    Philippe.
5344.9you are rightTAEC::LAVILLATFri Jul 23 1993 09:5210
    Philippe,

>    So, the OSI event which includes a severity field may be the way to go
>    if the notification FM handles it. Can anyone confirm all the above?
>    
	I confirm.

	Regards.

	Pierre.