Conference azur::mcc

Richard,

There are many directives that the Iconic Map does not display in the operations
menu: for example, register, deregister, create, delete, getevent.   In each
case, there are reasons behind not displaying them.  

For example, we issue create and register directives if necessary when an entity 
is added to a domain. Getevent is not exposed at the user interface: we allow
for the rule view to create rules.

Verna  

RE: .1

>There are many directives that the Iconic Map does not display in the operations
>menu: for example, register, deregister, create, delete, getevent.   In each
>case, there are reasons behind not displaying them.  

Actually, the IMPM really does make all of those except getevent available
at the user interface. They may not be in the operations menu, but they
may be invoked, though implicitly, under the user's control from the
toolbox.

Is that true for GetEvent? Perhaps I missed it. There are the Notification
Services, or course, but those are added value services layered on
GetEvent, and shouldn't decide whether the directive appears on the
operations menu.

GetEvent is not accessable via the IMPM.  It was thought (maybe incorrectly)
that providing it through the IMPM was not necessary.   Do think the user
should be able to issue it from the IMPM?  Does it buy him/her anything?

If so, I could put it back.

/Jim

RE: .3

Well, sure I think it is useful, or I wouldn't have asked. :-) 

I've made misguided requests here before, though, so let's see
where I'm coming from. 

First we have to ask whether we ever expect to have a director without
BMS (Notification Services). If so, then there would be NO way to detect or
wait for an event using IMPM. 

If we assume that NS will be there, then we have to ask whether it is
always the appropriate mechanism. Don't get me wrong (Jill), NS is
great stuff, but it is kinda overkill for an ad hoc, one time need to
know when an event occurs. Along with the class of events being
defined for network entities, we use events to announce the completion of
asynchronous operations, or Tasks. Once one of these tasks is started,
we can exit DECmcc, log off and go home, and then check its status in
the morning with a Show directive. Or, if it is something we want to wait
for, we should be able to bring up a GetEvent window and wait for the
event. To have the NS notify us, we'd have to define an alarm rule that
triggers on the event, and then keep the map window visible. If I want to
start the operation and then navigate elsewhere in the entity hierarchy
and work on other objects, it might be hard for me to do.

The bottom line is, why try to second guess the MSL designer? The SRM says
of the DISPLAY clause on the directive, "The management module developer
can choose whether to have the user interface recognize the directive".

One justification I can see for doing that second guessing would be a
philosophy of "FCL is the debugging interface, and we will make directives
available through it that we won't through IMPM". That is a useful
consideration, but too rigid in implementation. If I want to optionally
make certain directives available, I can define a non-displayed characteristic
and have those directives DEPEND ON it. I can use something like Diagnose
to turn on all sorts of things that Joe Customer doesn't see.

Jim, I can see how there is probably now a compatibility issue with this,
too. If all the dictionaries out there have DISPLAY defaulting to TRUE for
GetEvent, and the IMPM starts making it visible, that may be a problem.

    Richard,
    
    In V1.2, the IMPM's notification services will be enhanced beyond
    only being able to pick up alarms.
    
    In a nutshell, it will give you what FCL can give you for the Notify
    command (which picks up both alarms and events).  It will also give
    you a window to monitor notification in a chronological manner, which
    frees you up to navigate elsewhere in your map windows.
    
    The above new functionality fulfills most of your reasons for needing
    the GetEvent directive directly from the IMPM.  Pete Ditmars is working
    on the above new functionality.  There may be more functionality that
    I am neglecting to mention here.
    
    Christine
    

Yes, unluckily too late, we did find and qar the fact that in the v1.1
FCL display=false is NOT checked when verbs are queried from the
forms mode. The same problem also exists for display=false arguments
and attributes.

jill

    
    I will make the GETEVENT directive available from the operations menu
    for the eft kit(s).  This will encourage mm developers to set the
    display = false if they don't want the users to see it.   
    
    /Jim

Doing that will drastically effect the notification services. Let's talk off
line and get back with an answer here. Notification cares if the getevent
is set display=false, and if it is false you won't be able to utilize
all of the functions of the notify command.

jill

   We decided to display the GETEVENT directive in the operations menu for
the next few baselevels.  If there are lots of complaints that it is too
ugly or useless or ... it will be filtered out again.  
    

/Jim