Conference azur::mcc

>First, congratulations for your work : it seems to work quiet well and 
>provide the functionality.

It was (in my opinion) a great team effort, involving nearly every project in
MCC.  I'm glad you like the results.  

>1- Event arguments are not displayed, this can be a problem when events
>arguments are important and meaningful.

Sorry about that.  Schedule constraints and lack of a good approach for
displaying event arguments such that they can be distinguished from normal 
FCL output prevented us from displaying event arguments via NOTIFY.  Suggestions
on the format of an event report (including its arguments) are welcome.

>2- We have accvios when stopping notification (with exit or TERMINATE) :
>I do not know if it comes from my GETEVENT routine, or from the notification
>fm (debug says it is inside NOTIFICATION_FM image).

Can you post the NOTIFY commands that cause these accvios?

    We can reproduce the accvios, at this time we are still uncertain
    where the problem is (which component), but since they are happening
    on the background thread where the notify is working, this should
    not have any effect on the main processing thread where the user
    enters commands.
    
    thanks
    (this was already in the QAR MCC_INTERNAL database, number 15.
    
    
    00015 OP Yes     QD_CALLANDER NOTIFICATI M QD_DUGAL      3-DEC-1990
    NOTIFY/TERMINATE ACCESS VIOLATION
      
    

Re .1 :

Why doing complicated when we can do simple ?

Perhaps I miss the problem ?

Here is my GETEVENT output :

MCC> getevent sms 0 ual * dest * chan * any ev

SMS 0 UAL RADIAN DESTINATION HOGGAR CHANNEL X2
AT 13-DEC-1990 09:01:45 Any Event

Getevent Success
Channel Fault
                                 Reason = GM1 retry

I would be completely satisfied with :

%%%%%%%%%%%%%% Event, 13-DEC-1990 09:01:45 %%%%%%%%%%%%%%
Domain: RADIAN_NS:.EVENTS                             Severity: N/A
Entity: SMS 0 UAL RADIAN DESTINATION HOGGAR CHANNEL X2
Channel Fault
                                 Reason = GM1 retry


Re .2:

Yes it is not an inconvenient for us, I was just worrying to know whether the
ACCVio was on my side or not.

Thanks and regards

Pierre 

    Thanks for the good word on notification, we are real pleased that
    people are testing it.
    
    Now to clarify something. The getevent command is NOT considered
    a notification function. It works, and therefore looks, just like
    any other MCC command.
    
    The NOTIFY directive and rule binding features (<verb> domain xxx
    rule yy) are part of notification services. For these services the
    PMs have both been modified to include special handling of the
    functions, as well as the addition of a new module. This special
    handling of notify is what causes the color changes in the map and
    the specialized output to the fcl display.
    
    It would actually be more work to make the getevent work like the
    notify. If you feel that this is what you want though, I can qar
    it as a suggestion for you in the nacqar database.
    
    jill
    

In fact, I don't want the getevent to work like notify, but the contrary :
having the notify behave exactly as the getevent verb in case of an 
event report issued via getevent.
I mean don't loose some information provided by the getevent function when
displayed via notify.

I know this is not so simple, since not only the getevent output is used by
the notification fm, but in my opinion the getevent case is enough specific 
here to have a special treatment.


Regards

Pierre

    I think where you are going. Well in the first release of notification
    (the one you have) there was a bug in the PM, where the additional
    information that you see on the getevent was not being displayed
    on the notify. This was a bug, not an intentional descision. I believe
    that this was documented in the release notes, if not my apologies.
    
    If it is soley the content you were talking about, then I think
    we are on good footing for the next release. But understand the
    format differences will still be there. This was done for many reasons,
    one good one is that with the different format it is easy to write
    a quick dcl procedure to pull out all of the events and alarms from
    the output log if you have logging turned on, or are using the
    print/capture functions (you could even get search to extract the
    lines for you).
    
    

    Re .0: Why would event arguments have to be distinguished from FCL
    output?  In fact, wouldn't it be a feature to have a consistent style
    of presenting argument and attribute values?  In DECnet-ULTRIX, the
    event logger calls the NCL display library to output event arguments
    and entity instances.

    Did you say you don't know how to show an event in output?  I don't
    know about the FCL, but for the Iconic Map I should think you could use
    the international symbol for information, which is a fat lowercase i,
    as opposed to the bell for an alarm.

    re .7
    
    Ben, soon we should have something showing how we are handling arguments
    on events (as previously stated there was a previous descision not
    to print the arguments, based upon feedback that should be changing).
    The argument output will be consistent (though potentially slightly
    different) with the other argument displays. The major difference
    between notification output and standard directives (request/response
    -- synchronous) is their header formats.
    
    
    

The main reason we wanted to use a different format than normal FCL output is
that NOTIFY output can occur between partitions in the case where the main
thread is doing multi-partition processing, which could lead to confusing
output (where do the arguments from the event report end and the arguments
for the next partition of the main thread processing resume? we've already been
 QAR'd on this).  Perhaps that isn't such a big deal... 
we could put an event report trailer out that would signal the end of the event 
report and resumption of normal processing output.  I'm beginning to lean 
that way.

Restricting FCL to only be able to output NOTIFY information when there is
no processing occurring in the main loop, which is another way to avoid the
confusing output, seems overly restrictive.  (probably not as restrictive
as not putting out the data.... )

There are also a few technical hurdles to be cleared to get the NOTIFY
output for event reports to look like normal FCL output too... I won't bore
you with the details.  Suffice it to say that it couldn't be fit into the 
V1.1 schedule.

Note that there IS a work-around for some folks... put your (simple) arguments
into the TEXT for your event report.  Unfortunately, there is a real bug
in the FAO processing in the EFT release... it will be fixed for SSB.