Conference azur::mcc

6406.0. "Who does preprocessing on WILDCARDS ?" by KETJE::PACCO (Horum omnium fortissimi sunt Belgae) Tue Nov 14 1995 14:47

Who is expanding 'CIRCUIT *' in the command

	SHOW CIRCUIT * ENDPOINT * all IDENTIFIERS

I would have tought the access module entry, responsible for the
entry point, which is part of the AM I wrote,
	VERB = SHOW
	ENTITY = CIRCUIT * ENDPOINT *
	PARTITION = IDENTIFIERS
would have to take care of this.  Nothing of this is true.  Instead
the AM receives individually by name each of the 'known' circuits.
If partial of no wildcard is used, the AM receives the right input.
    
    The dispatch table of my AM shows here:
    mcc_dispatch_entry -
        SHOW,-
        < MCC_ENTITY <CIRCUIT, *> <ENDPOINT, *> >,-
        IDENTIFIER,-
        mcc_dna5osi_circuit_st
    

Who is able to solve this mystery?

	Kind regards,
	Dominique.

===================================================================
MCC> sho circ * end * all id
...
I get the list of all circuits, individually.
Service interface dump
Directive SHOW
Partition IDENTIFIER
Handle state FIRST
Input entity AES dump
        entity [0] wild = NOT_WILD class = 53 id = 12 type = 5
        instance = ..+,y..u7�+�......mcc..aaj-mcq..
        %X08002B2C791E097537B22BF59500100001036D6363010761616A2D6D63710000
        entity [1] wild = INSTANCE_FULL class = 1
...

I see no SHOW CIRCUIT IDENT in the function dispatch tables.
However I see

Verb           = (1)
Entity         = < (53) * >
Attribute      = (1)
Dispatch count = 0

Verb           = (1)
Entity         = < (53) *  (1) * >
Attribute      = (1)
Dispatch count = 0
 
at the access dispatch tables.  The 'endpoint' has the value '1'.
===================================================================
MCC> sho circ .mcc.* end * all id
Service interface dump
Directive SHOW
Partition IDENTIFIER
Handle state MORE
Input entity AES dump
        entity [0] wild = INSTANCE_PARTIAL class = 53 id = 12 type = 5
        instance = ..+,y..u7�+�......mcc..*..
        %X08002B2C791E097537B22BF595000A0001036D636304012A0000
        entity [1] wild = INSTANCE_FULL class = 1
===================================================================
MCC> sho circ .mcc.1 end * all id
Service interface dump
Directive SHOW
Partition IDENTIFIER
Handle state FIRST
Input entity AES dump
        entity [0] wild = NOT_WILD class = 53 id = 12 type = 5
        instance = ..+,y..u7�+�......mcc..1..
        %X08002B2C791E097537B22BF595000A0001036D63630101310000
        entity [1] wild = INSTANCE_FULL class = 1
===================================================================

    

Dominique,

In the case of wildacrd on global entities, the FCL PM expands the wildcard by
doing a DIRECTORY command (to the Registration FM) to get all matching entities
and then issues the call for each matching entity.

I don't remember if the FCL PM Use Manual says that clearly, but the SRM (at
least the V3.0 one) has a specific section on that. See SRM V3.0 vol 1 section
4.3.1 Global Entity wildcarding, p. 4-15.

Best regards,

Marc.

    Marc,
    
    That's what I suspected, but why then do half the work?  I mean why
    does the FCL_PM only the expansion  of FULL-wildcarding, and not
    PARTIAL-wildcarding ?  As global entities are anyhow names, the
    wildcard strategy on names (PARTIAL and FULL) is known and managed by
    DNS anyhow.  Therefore I wonder why the same is not done for partial
    wildcarding.  It would have save coding in the different AM's, or am I
    wrong ?
    
    Regards,
    	Dominique.

Dominique, 

The Registration FM knows how to deal with partially wildcarded fullnames, but I
haven't tried it with a partially wildcarded global identifier that is not a
fullname (NB: i am not sure if there are many of those, BTW). 

Apart from the fact that the Registration FM might not support partial wildcards
on non-fullnames, I don't see any reason apart from an implementation
restriction for not having the FCL PM expand the partial wildcard.

From the point of view of your AM, the SRM (same section) says explicitely that
all MMs should be able to deal with wildcards, including global/partial ...
Dealing does not mean accepting, but at least being able to return the
corresponding exception. The reason for that requirement is that a call might be
made from another MM with a global (or partial) wildcard and the AM should know
what to do with that. Most of the AMs will simply return the exception :
"Unsupported wildcard in target entity specification".

Best regards,

Marc.

    Marc,
    
    The actual situation sounds as a compromise.
    2). The work the registration-FM is doing is a courtesy for 'simple'
    AM's.
    1). Full wildcard is more often used than partial, therefore the latter
    was not implemented (yet?).
    3). If the AM is called by other MM's, you have to implement everyting
    anyhow, decision by the MM itself.
    
    Thanks,
    Dominique.