| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 513.1 | how to encode an event reply | GOSTE::CALLANDER |  | Tue Dec 04 1990 14:22 | 121 | 
|  |     an event report is not an attrib list.
    
    The following is a quick run, using alarms FM to show you what the
    getevent encoding looks like:
    
    MCC> create mcc 0 alarm rule foo1 exp=(node4 goste state=on, at
    every ::15)
     
    MCC 0 ALARMS RULE foo1
    AT  4-DEC-1990 14:13:26
    
    Entity created successfully.
    MCC> enable mcc 0 alarm rule foo1
    
    
    MCC 0 ALARMS RULE foo1
    AT  4-DEC-1990 14:14:14
    
    Normal operation has begun.
    MCC> getevent mcc 0 alarm rule foo1 any notification event
    
    
    *****************************************************
    *     FCL PM Arguments before call_function:        *
    *****************************************************
    
    VERB code:      65
    PARTITION code: 16
    AES dump of ENTITY IN:
    
    depth=3 class code= 7 instance = 0 class code= 1 instance =  no
    curlen class cod
    e= 5 instance = foo1
    
    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 ] (          			! response code (EVENTRECEIVED)
        [  1 ] (                        ! argument code (EVENTRESPONSE)
            [  25 ] (                   ! event code    (RULEFIRED)
                [  27 ] (               ! event arg     (EVIDENCE)
                    [  1 ] (
                        [  1 ] (
                   di         [  0 ] (
                                [  1 ]                             01
                                [  2 ]                           0c
                                [  3 ]                             02
                                [  4 ]                             19
                                [  5 ]                             11
    fb
                                )
                            )
                        [  2 ]                     53 74 61 74 65 20
    3d 20 4f 6e 20
     -- State = On
                        [  3 ]                     00 43 f2 86 8f 93
    c9 01 ff ff ff
    ff ff ff d4 1e
                        )
                    )
                [  21 ]             28 6e 6f 64 65 34 20 67 6f 73 74
    65 20 73 74 61
    74 65 3d 6f
                6e 2c 20 61 74 20 65 76 65 72 79 20 3a 3a 31 35 29 00
                [  29 ]             00
                )
            )
        )
    AES dump of ENTITY OUT:
    
    depth=3 class code= 7 instance = 0 class code= 1 instance =  no
    curlen class cod
    e= 5 instance = foo1
    
    
    MCC 0 ALARMS RULE foo1
    AT  4-DEC-1990 14:15:01 NOTIFICATION EVENTS
    
    Alarm Event Received
    Alarm Rule Fired
                                   EVIDENCE = { (          entity = Node4 4.507 ,
                                                             data = "State = On ",
                                                        timestamp = 4-DEC-1990 14:15:01.04 ) }
                                 Expression = (node4 goste state=on,at every ::15)
                         Perceived Severity = indeterminate
    MCC>
    
    From the dictionary this is the RULEFIRED event definition:
    
    DAP> SHO EVENT RULEFIRED
    
       Class (1) : MCC
         Subclass (2) : ALARMS
           Subclass (2) : RULE
    -------> Event (10) : RULEFIRED
               Definition (3) : PRESENTATION_NAME
               Definition (3) : DISPLAY
               Definition (3) : REPLY_TEXT
               Definition (3) : CATEGORIES
               Argument (4) : EVIDENCE 27
               Argument (4) : EXPRESSION 21
               Argument (4) : PERCEIVEDSEVERITY 29
    
    DAP>
    
    
    I hope that this helps. The basic statement is that you should encode
    it the same as you do a standard reply. The major change is where
    you put in the event code.
    
    /jill
    
 | 
| 513.2 | Pb was with my MSL definition of events | TENERE::LAVILLAT |  | Wed Dec 05 1990 05:31 | 45 | 
|  | 
Thanks for your answer.
I had already tried this ILV-encoding before, but got this :
ILV dump of OUT_P:
[  1 ] (
    [  1 ] (
        [  1 ] (
            [  1 ]             01
            [  2 ]             01
            )
        )
    )
AES dump of ENTITY OUT:
depth=2 class code= 9501 instance = 0 class code= 1 instance = toto
GMA_TEST 0 UAL toto
AT  5-DEC-1990 10:42:43 Any Event
Getevent Success
%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=0100000C, PC
=0023B3B0, PSL=03C00000
%SYSTEM-E-ACCVIO, access violation, reason mask=00, virtual address=0000000A, PC
=0000000A, PSL=0000000F
$
So because encoded as an AttribList the error message was slightly less
discouraging I thought it was a better way to do it...
The problem comes from my MSL definition of the event. It seems that the
FCL does not handle properly text substitution for events :
This works fine :
	 TEXT = "UAL State has change",
This will crash : 
	 TEXT = "UAL State has change from !<Previous State> to !<New State>",
Regards
Pierre.
 | 
| 513.3 | This ILV output looks correct | WAKEME::ROBERTS | Keith Roberts - DECmcc Alarms Team | Wed Dec 05 1990 07:45 | 23 | 
|  | RE: .2
>> [  1 ] (                        ! Response Id
>>     [  1 ] (                    ! Argument Id
>>         [  1 ] (                ! Event Code
>>             [  1 ]      01      !   Event Argument 1
>>             [  2 ]      01      !   Event Argument 2
>>             )
>>         )
>>     )
You had your Event Report encoded right, the first time.
When I looked at your MSL in 513.0 the first thing I noticed were
the arguments in the reply text ... I don't know if that is allowed (you
obviously got an ACCVIO).  None of the events produced by Alarms have
Arguments 'in' the text, nor any I've seen generated by the DECnet AM.
??
/Keith
 | 
| 513.4 | FCL has limited support for argument substitution in reply text (for ALL reply texts) | TOOK::DITMARS | Pete | Wed Dec 05 1990 16:28 | 24 | 
|  | Hi,
Thanks for the problem report.
FCL does support argument substitution in the reply text of an event.  It works
fine with arguments of the simplest datatypes, but I'm sure it doesn't work with
complex beasts like attribute lists, and it probably doesn't work with records,
sets, enumerations, etc..  These same restrictions apply to argument 
substitution for the reply text of RESPONSEs and EXCEPTIONs as well.
Can you let us know what the datatypes of the arguments you wanted to 
substitute were?  Were they enumerations?
Also, FCL (and the iconic map) is picky about incorrectly spelled 
argument names.  You'll get the "entity not found" message (indicating that 
there was no information found in the dictionary for that misspelled argument).
Again, this goes for EVENTs, RESPONSEs and EXCEPTIONs.
In any "event", FCL probably shouldn't have accvio'd.  I'll QAR this once I
understand better what we're doing wrong.
regards,
Pete
 | 
| 513.5 | They were enumerations datatype | TENERE::LAVILLAT |  | Thu Dec 06 1990 03:27 | 16 | 
|  | 
Both args were enumeration datatypes.
I was a little confused since text substitution worked correctly for 
RESPONSEs and EXCEPTIONs (the point was that arguments were Latin1String or
Simplenames in this cases).
Maybe you should document this restriction in release notes (sorry if they are,
and I did not see it) and try to avoid ACCVIOs ...
Anyway I removed my !<xxx> in the TEXT definition and then it worked fine,
it is not a great inconvenient.
Thanks and regards
Pierre.
 | 
| 513.6 | enum should work | TOOK::HAO |  | Thu Dec 06 1990 09:40 | 7 | 
|  |     Text substitions for enumeration datatype is supported.  If it doesn't
    work, it should be qared.  The datatypes that aren't supported for
    text substitution are the constructor/constructed ones like Set Of, 
    Sequence Of, Record, etc.
    
    Christine
    
 | 
| 513.7 | this has been QAR'd | TOOK::DITMARS | Pete | Thu Dec 06 1990 16:08 | 1 | 
|  |     It is QAR 84 in the MCC_INTERNAL QAR database.
 | 
| 513.8 | SPACES gone | GOSTE::CALLANDER |  | Wed Jan 09 1991 09:32 | 13 | 
|  |     The problem with extra blank lines should be rectified in the V1.1
    final release. 
    
    Ex: (using 30 day minimum ship kit--prebuild)
    
    MCC> register bridge ditmars line 1
    
    BRIDGE KISHKA_NS:.ditmars LINE 1
    AT  9-JAN-1991 09:30:14
    
    No such entity: BRIDGE KISHKA_NS:.ditmars LINE 1
                             Unknown Entity = BRIDGE KISHKA_NS:.ditmars LINE 1
    MCC>
 | 
| 513.9 | Event with no arg | DGOSW0::GUESDON |  | Mon Apr 22 1991 12:01 | 3 | 
|  |     When there is no argument associated with the event (For example, the
    initialisation of the entity is only associated with an event code), how
    can I encode the event ? Do I build an empty ILV construction ?
 | 
| 513.10 | you got it | TOOK::CALLANDER |  | Mon Apr 22 1991 13:14 | 3 | 
|  |  Simple do a put param begin for the getevent_success response,
then do a put cons begin for the event argument then a cons end
followed by a param end.
 | 
| 513.11 | *closed* qar 84 fixed | TOOK::CALLANDER |  | Thu May 16 1991 13:27 | 4 | 
|  |     RE .6, .7
    
    QAR 84 has been fixed and closed, as of the V1.1 SSB release.
    
 |