Conference azur::mcc

>> What's missing?  What's wrong?  What have I missed?  
>> How does the in_p look like if the default is passed along the MCC call i/f?
>> Will I find the symbol MCC_K_SEB_SYM_ARG_SHOW_ALL_ID ILV-coded or what?



(1)  Show directives do not take arguments.  So, you should not put any
     in your MSL.  Remove the 'REQUEST' stuff from the Show directive.

(2)  For the Show directive you specified, you should expect:

	Verb:      SHOW
	Entity:    SEB <seb_entity> APPLICATION <appl_child_entity>
	Partition: MCC_K_PRT_CHARACTERISTCS
	In-P:      null

     For this directive you should return ** ALL ** your characteristic
     attributes ... the FCL PM will pick out the attribute which was
     requested on the command line and only display that one (not the
     rest of the attributes you returned).

(3)  You will not see the symbol MCC_K_SEB_SYM_ARG_SHOW_ALL_ID encoded
     anywhere.

(4)  Perhaps at a later date (DECmcc v2.0 ?) the Show directive may take
     request arguments as you have done in your MSL, but not yet.

Does this help?

Keith Roberts
DECmcc Toolkit Team

    repl .1
    
    >>> Does this help?
    
    Both yes and no!   I got the answer I was looking for, but I don't
    like it.   Why is this not documented (or if it is, so very hard
    to find)?  And furthermore, shouldn't the SAMPLE-AM provided be up to
    date?  I mean that in the MCC_SAMPLE_AM_SRVC_IF.MS there's a request
    part for the show-directive, both for the global entity and for the
    child entity (okey, in the show-directive routines the in_p is not
    looked at, but anyway...).
    
    If my entity whould have some 50-100 attributes (which will be the
    case) I really don't think it's nice way of implementing the
    show-directive to return all the 50-100 values and then let the PM
    decide what to display.  For my AM (and all other AMs as well) that
    will result in a lot of unwanted net-trafic.
    
    Shouldn't this have had higher priority so it would have been
    implemented?
    
    Is it documented somewhere what DECmcc v1.1 supports and more
    important what is not supported but documented (and therefore thaught
    as supported)?
    
        /Nils
    
    ps.  
    
    Sorry for being so negative, but my job is to implement an AM that
    supports the GETEVENT and SHOW directive (later there will be more).  
    The first problem I ran into after a lot of trouble was the
    event_report sent into the event_manager (MCC_EVENT_PUT) just going
    down the drain.  Reading the manuals about event-management, there's
    nothing written about event-reports not being taken care of, just that
    have to be provided!!!.  At the moment this makes DECmcc not usable for
    us.  The second thing is this with the in_p and SHOW-directive and the
    manual stating that the AM has to decode the in_p-argument....  
    What's next.....? 
    

    Re: no argument to SHOW being passed down to the AM (yet).....
    However, even though the AM does not get the argument passed down in
    in_p (yet), do you agree that the correct thing happens as far as the
    user is concerned, as the PM extracts the required attribute(s) from
    the output arguments and only displays the requested attribute(s)?
    
    I expect the release notes discuss which portions of the SRM are not
    (yet) implemented completely, including the fact that the PMs do not
    provide the "attributes wanted" argument.
    
    Colin

    re: P.S. in .2 about events
    
    Although this is slightly off the base topic, it seemed worthy of
    reply. You make comment about mcc_event_put, and the events "going down
    the drain". I don't follow *exactly* what you mean, but I guess that
    you were unaware of the necessity of having a matching, previously set
    up, mcc_event_get to ensure that the events you put get somewhere.
    
    I checked the SRM, to be sure we had not missed out such an obvious (to
    us) detail. On page 627, under the description for mcc_event_put, the
    first line says:
    	This routine is used to send the event data to any threads
    	which have requested the matching event data.
    
    On p369, in section 10.11, there is mention of a Getter thread and a
    Putter thread, which is elaborated on in subsequent subsections of
    10.11
    
    If you feel there is vital information missing that causes
    misunderstandings, please let me know (here, or via mail) and we will
    address it in a future version of the SRM.
    
    Colin

    repl .3
    
>>> do you agree that the correct thing happens as far as the
>>> user is concerned, as the PM extracts the required attribute(s) from
>>> the output arguments and only displays the requested attribute(s)?
    
    Yes, the PM should only show what I ask for.  (but I still think its
    the work of the AM to extract the info not the PM)
    
      /Nils
    

    repl .4
    
    sorry about this, it's another story.  I have the event-stuff working,
    i.e. the icon goes red on the map and I can see that a particular rule
    has fired.  The only truble is that the info in the event-report sent 
    to the event-manager thru the MCC_EVENT_PUT and retreived in my
    AM thru the MCC_EVENT_GET and from there sent to the FM that called my AM
    via the out_p-argument can not be retreived via the PM nor in the
    event-data file created by the alarms-fm, and I really need that info.
    (what a sentence... hope you understand)
    
    Thanks for your concern
    
    /Nils
    

Nils,

There is some confusion with Show Directive Arguments.

  o  The SRM says in section 15.4.1.13 that Show takes no Arguments
  o  The SRM says in section 15.4.2    that Show takes optional arguments

  >> This has been QAR'd today
       - The Show directive CAN take an argument.

  o  The current FCL PM processes individual attribute requests by
     filtering the entire partition of attributes returned by the MM,
     and only displaying the requested attributes.

  >> This was also QAR'd today
       - The FCL should pass a list of Attributes for the Show directive
         when specific attributes are requested in the command line.  The MM
         will process this attribute list, returning only the specified
         attributes.

  -----------

  Q: How can you get your MM up and running quickly?
  A: Today, even if you wrote code to process a list of Request Attributes,
     the FCL will not encode the request into In-P.  I suggest that you
     postpone this functionality for when the FCL implements the Show
     Request Argument (attributes_wanted).

     I do not know when the FCL plans on implementing this functionality.

  Q: The Sample AM has the Show Directive Request Arguments - how come?
  A: Probably because the SRM templates have them.  As you stated in .2
     the actual source code does not attempt to read In-P to process the
     request arguments.  The YOURMM templates do not have the Request
     Argument in the MSL - I will add this to the MSL for v1.2

I fully agree that returning many attribute values, when only one might have
been requested is inefficient.  But as you can see, it is our intention to
correct this.

In a future release of the Design Framework, it is our hope to provide the
'guts' of the Set and Show directives; the protocol and overhead.  You would
need only provide the code which interfaces to your entity; the conversion from
you entity's datatypes to MCC datatypes. The processing of the Show Arguments
would be done for you.

/keith

Nils, if enter your GETEVENT directive from the FCL, do you see the
event report displayed correctly?

The Alarms software does not process event *arguments* .. only the Event
code (ie, the event name, like "counters zeroed").  So, you won't see
see any of the event report in anything the alarms code generates as
output.

/keith

    repl .8
>>> Nils, if enter your GETEVENT directive from the FCL, do you see the
>>> event report displayed correctly?
    
    Yes I do.  Okey, I'm wrong again.  The event report doesn't vanish in
    this case,  but (isn't there always a but...) the guys managing the
    network will be using the iconic map PM, and there's no eventreport
    displayed there when a rule has fired due to an event.  Just that the
    event has occured.
    I know that this (notification FM not displaying event-reports) is not
    yet supported, so I'll just have to wait...
    
            thanks,
          Nils