Conference azur::mcc

>> show unix .unix.felon cpu 0 all statistics
>>
>> %MCC-E-INV_IN_ENTITY,
>>   software error: invalid in_entity (input entity) parameter

  Does your AM support Statistics?  Do you have a Dispatch Entry
  for this directive?  If not, then somehow it is falling into the
  Performance Analyzer (PA) FM and then getting rejected because
  PA does not support your FM.

>> show unix .unix.felon cpu 0 all status
>>
>> %MCC-S-RESPONSE, success with response reply

  You obviously have a dispatch entry for this directive.

/keith

here is what is happening...

The PM always does a mcc_call_function(V,E,P, ...) and if there is not 
entry in the function dispatch table, the dispatcher tries the access 
dispatch table before declaring an error.  In you case, the mcc_call 
function dispatch key looks like: 
	V = SHOW
	E = <your class and instance>
	P = STATISTICS.  

The PA FM is signed up, in the function dispatch table, to catch 
	V = SHOW
	E = <any class, any instance>
	P = STATISTICS

You probably enrolled your SHOW STATISTICS entry point into the access
dispatch table just like all your other entry point.  Well what is 
happening is that the PA FM is catching the dispatch.

What you need to do is enroll (only!) your SHOW STATISTICS entry point
in both the function and access tables.  This dispatch ordering is done
by most-specifc to most-general, so your class-specific entry will
appear in the table before the PA entry.  Since the dispatcher uses
first-match, SHOW STATISTICS for your class will always dispatch to your
entry point and PA continues to catch all cases for which there is no
specific entry (like it is supposed to). 

Now, you might ask how do I enroll in both?  You have to modify your
mcc_*_init and mcc_*_probe routines and your VECTOR.MAR.  Look in the
Management Module Programming Guide for descriptions and directions for
enrolling in dispatch tables.  Check out the Example FM for an example
of enrolling in multiple tables.  The Example FM enrolls its service
entry points into the FUNCTION dispatch table and its own
self-management entry points into the ACCESS dispatch table.  The
Example FM *VECTOR.MAR also gives a good example of what is necessary to
create dispatch table entries for ACCESS and FUNCTION. Just make sure
you put the SHOW STATISTICS in both the ACCESS and FUNCTION tables. When
you are finished, your ACCESS table should look identical to what it did
before and your FUNCTION table should have a single entry in it, SHOW
STATISTICS. 

good luck,

...kjn

just a note on why you are getting the invalid in_entity error...

The PA FM is catching the mcc_call_function(VEP).  The FM validates the
selected entity class against the classes it knows about.  Since the PA
FM does not know about the your entity class - it returns the "invalid
in-entity" message. 

...kjn

    Great, thanks, but ...
    
    I have looked at the mcc_example__init.c source, and understand what I
    have to change in our application except that in the example probe
    function the comments refer to both EXAMPLE_MGMT_DISPATCH_TABLE and
    EXAMPLE_SRVC_DISPATCH_TABLE; however the actual code only seems to use
    the latter. I have read 7.7.2 of the Management Module Programming
    manual but can find no explanation as to why it does not call
    mcc_enr_save_bias() with both tables. 
    
    regards,
    
    
    Mike Wheeler
    
    
    P.S. thanks for the plain english, assume-no-knowledge
    explanation in the previous replies; this is exactly what I need. (Am i
    the only one who ends up fixing problems in systems I no nothing
    about?)
     

 I thought I was going to tell you ...

 -------------------------------------------------------------------------

  MCC_EXAMPLE__INIT.C

    >>> Init Routine:

    This routine Enrolls both tables, that is:

      o EXAMPLE_MGMT_DISPATCH_TABLE in the Access Table, and
      o EXAMPLE_SRVC_DISPATCH_TABLE in the Functional Table

    >>> Probe Routine:

    There is only 1 call to 'mcc_enr_save_bias', passing the
    address of EXAMPLE_SRVC_DISPATCH_TABLE .. This is because
    both tables are contiguously defined in memory:


  ------------------------------------------------------------------------

  But I just checked the Example FM Vector file .. and the MGMT table
  is defined first, then the SRVC table.  This would mean that when
  you call 'mcc_enr_save_bias', you'd pass the address of the MGMT
  table ........ but the code is passing the SRVC table.

  I don't know how it works!  And I wrote the code 8(

  Can some MCC Kernel type explain how come the Example FM is working,
  when the Dispatch Table define SECOND is passed to 'save_bias' ??

  /keith

    RE .5:
    
    The tables are contiguous in memory.  If you specify someplace in the
    middle of the tables (the label of the 2nd table) as the "aiming point"
    of the enroll, all offsets in the dispatch table are calculated from
    that point.  Negative offsets work, but are not guaranteed or
    recommended.
    
       Ted

    So the answer is .. the Example FM probe routine is ok, but 
    specifying the 'second' table in the mcc_enr_save_bias routine
    is not recommended.  But only one call to save_bias is needed as
    the table are defined contiguous in memory.
    
    I'll file a QAR on the Toolkit to correct the call to save_bias
    in the probe routine.
    
    /keith

I would suspect that good coding practice, maintainability, etc., would 
dictate a call to _enr and _save_bias for each table, even though not
absolutely necessary.  

...kjn

RE: .8

> I would suspect that good coding practice, maintainability, etc., would 
> dictate a call to _enr and _save_bias for each table, even though not
> absolutely necessary.  

  Ted .. is that right ?

  Should MM's which have both Access & Functional (two) tables
  make two calls to the mcc_enr_save_bias for each table?  If so, the
  Example FM will need to be updated .. AND .. the Toolkit Documentation.


  /keith

    RE .9:
    
    Only a single call to mcc_enr_save_bias should be made per MM, as only
    one bias value is stored in the MM's address space when it runs.  This
    bias value is applied to all dispatch tables of the MM.
    
    Ted

re. -1

Interesting, as several of the Framework FMs call enr_save_bias twice, 
once for each table.  FMs are really the only MMs that enroll into two 
tables.  (And AMs that support the STatistics partiion, as well)

...kjn