Conference azur::mcc

    well....... it is unclear because the function you are
    requesting/describing is not currently supported.
    
    There are discussions in this area but nothing concrete/implemented
    yet.
    
     

    I think the Phase V NETMAN and NCL architectures provide some input
    to this discussion.  Specifically these architectures suggest that
    the NETMAN architects intended the AM (and the NCL equivalent) to
    let the agent do the cross-class wildcarding.  However, I have no
    idea what impact this might have on the dispatcher, database, etc.
    if any.
    
    The NETMAN architecture describes how to encode a cross-class
    wildcard, such as SHOW.  in entity_model_t1_0_1, dated 30-nov-1990,
    in section 7.5.1, it says that the entity class code 127 is
    reserved and used to indicate the wildcarded entity class.
    
    NCL also alludes to this in its description of entity syntax.
    
    The net effect is that the command:
    
    ncl> show node x * all attributes
    
    means 
    
    "show (all attribuutes of) all sibling subentities (of whatever class)
    contained in node x".
    
    This is actually expressed in the DNA CMIP protocol as a single
    PDU, with class code 127 as the bottom-most class code in the PDU.
    
    This feature suggests that the AM could just 'pass through' this kind
    of wildcard to the agent.  DECnet-ULTRIX supports this functionality
    today.  This provides some useful functionality
    for DNU.  The above command lets you know which software modules
    are actually installed and running on the system (i.e. DNS, DTSS,
    MTA, X.25...).  You can't find that information out without talking
    to the agent.
    
    ben

The AM  should  be  responsible for it.  That way the DNA5 AM can send it to
the  entity  agent and AMs for protocols which can't do that can look in the
dictionary.

Graham

  On the other hand, a single AM may not be responsible for, or even know about,
  all the child classes at the same level in the containment hierarchy.
   
  Kathrin

  Jon,
	The architecture allows for class wildcarding.  In section 5.3.3 on
 page 67 of the SRM is a description of class wildcarding.  Class wildcarding
 is not supported in V1.0 or V1.1 of DECmcc.

	Both global and child entity class wildcarding is allowed by the SRM.
 However, global entity class wildcards may not be passed across the
 mcc_call interface.  Therefore, expansion must occur at the PM or FM level.
 Child class wildcards may be handled at the PM or FM level given that the
 information is in the dictionary.  This is how the Iconic Map works.  When
 you double-click on a global entity in a domain, a child entity view is
 displayed.  This is done by going to the dictionary, determining what the
 child classes are for the next level down, and doing a SHOW with an
 instance wildcard for each class.

	Full child class wildcarding can also be handled by the AM, as Ben
 suggested.  The dispatching process takes class wildcards into account. 
 So, yes, the AM must have an entrypoint to handle it.  The MCC_AES_*
 routines described in chapter 11 of the SRM discuss various sorts of
 wildcarding, including class wildcarding.  For example, there is an
 argument for  MCC_AES_CREATE, MCC_AES_GET, etc., called WILDTYPE which
 can have a value of MCC_K_AES_CLASS_WILD.

	Class wildcarding is not supported throughout the system for V1.0
 and V1.1.  The PM's (FCL and the Iconic Map) do not support it at this
 time.  This is an area which certainly will be looked at for future
 release.
							- Dave

    On further reflection, I may have said something confusing in .2
    The function of cross-class wildcarding is useful, but I don't see
    any reason why the AM couldn't expand the wildcard, assuming the
    AM's dictionary is up-to-date.  Either way is fine by me.
    
    ben
    

    
    My problem is that I'm communicating with another director.  I'd like
    to be able to pass the class wildcard to this other director and let it
    expand the class information.  If a PM or FM, does this then I can't
    pass this information along (its also more inefficient because I have
    to send one request for each class).  If the AM expands this
    information then I can let the other director perform the class
    expansion (I only need to send 1 request for all classes).
    
    My other problem is knowing which entrypoint gets called when a class
    is wildcarded.  This last point has an effect on where I do class
    wildcard processing (and expansion in a relatively few cases).
    
    Thanx for the information thus far!!!!
    
    ~Jon.