Conference azur::mcc

2767.0. "PB with DNS and SHOW *" by TAEC::WEBER () Wed Apr 15 1992 12:15

    
    My customer has a inconsistency problem using DNS with the operation
	SHOW PARENT 1 CHILD * ALL IDENT
    whereas individual operations work properly.
    There is only one subclass wich has one identifier attribute
    which is the primary name.
    The parent entity has 5 instances of child entities registered in DECmcc.
        
    The code of the show_all_ident has been copied from the toolkit
    mcc_example__getevent.c, where the call to the mcc_event_get has been
    replaced by mcc_dns_get_identifiers. I have reviewed all the
    code and it is exact replication of the example, it seems to be correct (!).
    The "strange" behaviour is about the out_e :
    (they were dumped at FCL, but I am writing those infos out of a FAX)
    
1st response is correct:
PARENT 1:.child ent_1
Timestampxxx   Identifiers
    Les attributs sont:
			    Nom = ent_1	    
	    
2nd response is uncorrect
PARENT 1:.child ent_3
Timestampxxx   Identifiers
    Les attributs sont:
			    Nom = ent_2
Here, the ent_3 of the out_e should be ent_2

3rd response is uncorrect
PARENT 1:.child ent_4
Timestampxxx   Identifiers
ILV dump of OUT_P
    [ 1 ] (
	[ 2 ] 03 26 d3 ba
	)
	
Sofwtware logic error detected
	MCC Routine error = %MCC-E-INV_ENTITY, invalid entity structure
	
Here, the ent_4 of the out_e has been dumped because they were 5 entities.
If there are 4 of them, the output says that it is not dumpable.

There is no more responses.

I have asked to verify what was going out of the AM:
The p_callargs contains, when living the AM,
an out_e set to ent_2 in seconde response. It is displayed as ent_3 by the
FCL PM. 
The p_callargs contains, when living the AM,
an out_e set to ent_3 in third response. It is
displayed as ent_4 by the FCL PM.

I really wonder what happens. It seems that the dns_get_identifiers is
called again with the same handle and context. I have been told by the
customer that dns_get_identifiers is called only once in the AM.
However, because code replicates the mcc_example__getevent.c, the
dns_get_identifiers could be called when Handle State = Cancel or in
do_directive, when handle returned from dns call is examined and the
operation fails. To me, the cancel should not be invoked, and cannot
explain the unsuccessfull responses (at least the 2nd one).

Any idea about the sequence of MMs calls to dns when wildcard ?
Should'nt we avoid recalling dns in the cancel or in case
get_state (dns handle) fails ?

Thanks to have a look
Florence

    RE:.0
    
    In wildcard opertation in mcc_dns_get_identifiers(), the routine has to
    be called with the same handle.
    
    If you set the handle to CANCEL and call the mcc_dns_get_identifiers(),
    the output (both p_matching_entity and identifier) is invalid.
    
    The routine does look ahead in wildcard operation. When the routine
    was called second time with handle CANCEL, the output may contain
    incomplete results.
    
    When mcc_dns_get_identifiers() is called with wildcard, the routine
    is to be repeatedly called with the same handle until the handle state
    becomes FIRST.
    
    If you want to see the correct behaviour of the routine, try 
    MCC> dir parent 1 child *
    (This command causes the Registration FM to show all identifiers of the
     registered children of parent 1)
    
    William
    
    PS. Can you post the part of program in which the call to
        mcc_dns_get_identifiers() is made.