Conference azur::mcc

I do not believe you are allowed to return the same argument more than
once.  If that's what you need, your argument should be a sequence of
the LATIN1STRINGs (as in your example).

I suspect that the FCL & IMPM are simply walking throught the Out-P 
buffer and decoding each piece of data as it is found - by looking
things up in the dictionary.

It appears to me that the PMs should detect if an argument has already
been seen and ignore or report-as-an-error.

Your best bet is to not use this bug-feature.  If I were to write
an FM that talked to your AM ... I would decode Out-P as described by
your MSL and MRM (Module Reference Manual).  I wouldn't expect to find
multiple argument #10, and would probably ignore them (depending on how
I actually processed Out-P).

/Keith

    
    Err, Kieth.
    
    I used this bug/feature just recently, in fact.  It simplifies our user
    input from FCL significantly when we enhanced some PASS/BLOCK features
    in phase 4.
    
    Currently, in DNA4, when setting up the event filter, you use a PASS
    command something like this:
    
    	PASS NODE4 name OUTBOUND STREAM name REMOTE SINK name CLASS = 5,
    		EVENT TYPE =(0,1,2)
    
    To describe the events you would like passed to a given Remote Event
    Sink.  We have a set of enhancements that had the side effect of
    teaching the Access module how to handle multiple  sets of these
    class/type pairings.  That is, now we allow something like this:
    
    	PASS NODE4 name OUTBOUND STREAM name REMOTE SINK name -
    		CLASS = 5, EVENT TYPE =(0,1,2), -
    		CLASS = 3, EVENT TYPE =(0,5), -
    		CLASS = 4, EVENT TYPE =(15)
    
    So, you can describe lots of events in a single PASS command, and we
    will try to do our best stuff with it.
    
    In hindsight, it might have made sense to use some more complex input
    schema, like a SEQUENCE consisting of class and type, or something like
    that.  Oops.  Anyway, the above command works now only because the 
    enforcement is left to the AM and we were able to make sense of what
    looks like a sensible command.
    
    Just another view.  You know, in the same way that "every problem is an
    opportunity",  "every bug is a feature".
    
    -Jim
    
    

    At the very least, Jim's use of this "feature" is disallowed by the
    Entity Model.
    
    See, for example, section 5.3.3:
    
    	The director may not send duplicate arguments.
    
    
    I've yet to find explicit text in the Entity Model or SRM that
    disallows duplicate reply arguments, but in general I would recommend
    against it. As .1 says, use the available techniques.
    
    I am sure, though I can't find any explicit text there either, that
    OSI management does not permit duplicate arguments - I expect it would
    fail ASN decoding.
    
    I'll also QAR the SRM so we can explicitly say don't do it.
    
    Colin

the SRM does actually disallow it, and the FCL used to at least also note
this as a bug in the release notes. The note might have gotten lost in the
suffle but we do know that this is a bug. From the Iconic Map I am uncertain
how, with the forms up, you could force an attribute or argument more than
once?

jill

The Iconic Map presents a form for input of arguments so the same argument 
could not be entered more than once. However in decoding out_p for the reply,
for each argument returned, we decode it according to dictionary information.
Presently, we do not keep track of whether the same argument is returned more
than one time.   

Verna