Conference azur::mcc

   First, to answer your question, I believe the problem you are seeing
   is the result of an incorrect PARENT statement in the children entity 
   definitions in your MSL.  In the parent statement, you should include
   a chain of all parent entities.  For instance, assuming that Node is
   your global entity, for the child entities of Storage, your Parent
   statement should look like this:

       PARENT = (Node, Storage)  
	
   Note that "PARENT" replaces "SUPERIOR".

   As an aside, you are supposed to (required to?) define an IDENTIFIER 
   ATTRIBUTES parition and support the SHOW IDENTIFIERS for all entities.  
   When an entity doesn't have any identifiers, you include an identifier
   partition for the entity in the MSL as follows:
		
	   IDENTIFIER ATTRIBUTES;
	   END ATTRIBUTES;
	      
   To support SHOW IDENTIFIERS for an entity with no identifiers, you 
   should return an empty attribute list.  This requires you to use the 
   following ILV calls:

	   MCC_ILV_PUT_PARAM_BEGIN     (*to begin encoding *)
	   MCC_ILV_PUT_CONS_BEGIN      (*to begin attribute list *)
	   MCC_ILV_PUT_CONS_END	       (*to end the attribute list*)
	   MCC_ILV_PUT_PARAM_END       (*to end the encoding *)

		  
			Hope this helps,
				       Lynne
  

    Lynne,
    
    My MSL is self-contained from Node through Storage and its children, so
    no PARENT declaration is needed. Each subclass is defined within its
    parent, in other words. (I should explain that I build a developer's
    dictionary by deleting all the Node and Node4 stuff. This lets me build
    the parse tables quickly.)
    
    I have an empty identifiers partition defined (MSL wouldn't let them by
    without it).
    
    The dictionary shows all the right subclasses, and the
    INSTANCE_REQUIRED definition is set to 0 for those without instances.
    
    Thanks for the tip about the empty ILV construct, I would have run across
    that sooner or later.
    
    Richard

SET FACE = RED

In my eagerness to check out the class hierarchy, I neglected to put any
directives on the children of Storage. So, er, well, the reason the parser
and FCL didn't want to do anything with them was because I hadn't said
that they *could* do anything.

Adding directives to the children helps a lot.

Richard

The SRM says that null instances should have a id of MCC_K_ID_NULL in the
entity specification.

I've got entities Storage and VMS defined as instance less. Entities Node
and File have entities.

MCC> create node oreo storage vms file a

DUMP OF ENTITY IN:

depth=4 class code= 10 instance = �class code= 11 instance =  no curlen class co
de= 12 instance =  no curlen class code= 13 instance = a

My AES dumper shows:

4 CI Pairs in Entity Spec, No Wildcard
  0: Class: 10 DataType: 5 Length: 24 Id: 1 Flags: 0
  1: Class: 11 DataType: 0 Length: 0 Id: 0 Flags: 0
  2: Class: 12 DataType: 0 Length: 0 Id: 0 Flags: 0
  3: Class: 13 DataType: 6 Length: 1 Id: 1 Flags: 0

All looks good except that the id for the instance-less CI levels is 0, not
127.

    
    I probably should reread all the previous entries for this note,
    but I am lazy this morning.
    
    I believe what you are questioning why the ID field is 0 when
    you have an instance less entity class? 
    
    If the parser doesn't parse an instance, it doesn't store one. The AES
    command used to create entity_in simply enters an instance less (null) 
    descriptor the the instance into the spec.
    
    I will ask the AES people about their storage of the null.

It is temping to think that and entity without instances show need a show
because there isn't anything to show. But the iconic_pm needs to be able
to do a show on everything it navigates through.

So make sure the MSL has Show defined, and the dispatch table has show
for at least the identifer partition.

The directive code doesn't even need to put anything in out_p, just
return a common exception of MCC_K_SHOW_EMPTY (empty partition).

The "new/improved" DECmcc SRM V1.1 (which isn't back from the printers yet)
has dropped mention of MCC_K_SHOW_EMPTY. An ECO to the SRM requested that
this response be "retired".

The "new" way of handling this is to return the response MCC_K_SHOW_SUCCESS
with a response argument of MCC_K_ARG_SHOW_VALUES (whose datatype is
Attrib_List), but containing no attributes.

You might want to use the "new" way to avoid future problems. 

RE: .7

Thanks, I'm in to avoiding future problems, I'll make the change.

> Thanks, I'm in to avoiding future problems, I'll make the change.

	Maybe you shouldn't be REQUIRED to support SHOW.

   By passing a null atrib list back you get bizzare user behavior.  For 
example, you do a SHOW MCC 0 ALARMS ALL IDENTIFIERS and get back

   MCC 0 ALARMS
   Identifiers
   AT 26-sep-1990

   Examination of attributes shows:


Thats all you see!  My first response to this was "where are the identifiers?"
is something broken?

I would rather see a message saying there aren't any. 

/Jim

    Jim,
    
    This was brought up when the ECO came around, but the descision
    was made to go with the new ECO.
    
    I agree that everyone should support show all identifiers on ALL
    entity classes. This allows things like FMs and PMs to be able to
    make certain assumptions in the everchanging and dynamic environment
    of MCC (like the FCLs assumption which allows us to support a default
    partition on all examine directives).
    
    As to the ugly reply text about the only thing we can do is surpress
    it if the attrib list is empty. The only thing is that the FCL logic
    handles the reply text before even opening the attrib list (design
    change would be needed).
    
    Unluckily here isn't the place to argue the pros and cons of the
    new ECO. But if people don't like I suggest we log a QAR against
    the SRM, or the PM's.
    

Yipes!

Maybe the ECOs should be more widely circulated...

 re - a few:

It is temping to think that and entity without instances show need a show
because there isn't anything to show. But the iconic_pm needs to be able
to do a show on everything it navigates through.

So make sure the MSL has Show defined, and the dispatch table has show
for at least the identifer partition.

	
	I may have misunderstood.  Are you saying that all ( child ) entities
	must support SHOW IDENTIFIERS?  Then yes, that's the case.  If you are
	saying the entity must support show for ALL of its partitions then
	there's something wrong.

    you need to support show all identifiers for all entity classes,
    parent and child.