Conference azur::mcc

It is a goal that we will at some point pass the WITH clause across the call
interface for just the reason you are specifying. Currently though it is
handled solely within the PM (this was done in V1.0 because it allowed us to
implement WITH once in the PM and have it work for all modules; instead of
implementing it for each module).

To jump on the subject ...

What happens if we encode the WITH in in_q and call directly an MM by
mcc_call_access/function (supposing the target MM is able to handle it) ?

Is this in_q trapped somewhere or will the MM receive it ?

Regards

Pierre

If you encode something in in_q it will go right through. It is up to the
receiving xM to validate the data. Though I would suggest that you check
to see what the Control_FM will do if something is in in_q that isn't
in the architeture.

Currently though the encoding of with has not been defined; nor has the
in_q argument code needed to do the encoding.

    
    	The problem is that the WITH qualifier requires that an attribute
    has a value.  All I care about is that the attribute exist.  With this
    in mind, can I check for the existance of an attribute (as a filterable
    qualifier)?
    
    ~Jon.

>If you encode something in in_q it will go right through. It is up to the
>receiving xM to validate the data. Though I would suggest that you check
>to see what the Control_FM will do if something is in in_q that isn't
>in the architeture.

Control FM enforces directive and partition combinations by means of its 
vector table.  The vector table macro has no provision for in_q checking.
So, any directive and partition combination the registrar has asked for
will be passed by Control FM, with no regard to Entity, or in_q, or
any other mcc_call parameter.

Ruth

    
>    	The problem is that the WITH qualifier requires that an attribute
>    has a value.  All I care about is that the attribute exist.  With this
>    in mind, can I check for the existance of an attribute (as a filterable
>    qualifier)?
    
 Jon, the answer to the question as asked is no.  If you know an attribute
is not predictable (you can get this information from the dictionary),
you are going to have to ask the entity for the attribute
to see if it is present.  It might be as easy as determining the variant of
the entity you are communicating with (e.g. know that this variant does not
include attribute z) or you might have to ask the entity to display 
all attributes in the partition, and look for the not predictable
ones (e.g. this entity doesn't provide values for defined but un-engaged 
attributes). 

Ruth

if you only care that it exists you could do something like

	,with (attr= value) or (attr >< value)

this way if the attr exists at all then this statement will always evaluate
to true.

Re: .7

> if you only care that it exists you could do something like
> 
> 	,with (attr= value) or (attr >< value)
> 
> this way if the attr exists at all then this statement will always evaluate
> to true.

Does the  SRM  *define*  that or is it just the way the PM currently behaves
today?  We had a long discussion in NETMAN about the meaning of filters that
include  attributes  that  don't exist.  My position (which others disagreed
with)  was  that an error should be returned: that is what my implementation
does (of course, not from MCC as that doesn't pass filters to the AM but you
can  see  the  error  using  filters  from  NCL).   I  believe we left it as
implementation-specific in NETMAN: not very nice but saved arguing any more!

I don't  know  whether  ISO define the behaviour.  I believe they defined an
operator  which  determines  whether  an attribute exists or not but I don't
know  what  they  say  about the relational operators used with non-existent
attributes.

If it  doesn't  do  so already, the SRM needs to define what happens in this
case: it isn't immediately obvious what the behaviour should be.

Graham

That is how the PM works right now, mostly for the reason you just stated,
we don't pass it down to the AM. 

The WITH clause is defined for the purpose of filtering out data output
that you aren't interested in seeing. The SRM *WILL* (I am told) some
time in the near future add in more on filtering and scoping so that
it is handled by the service providers instead of the PMs.

More information on this topic will be coming available as the proposal
for this is writen (and my understanding is it will take into 
consideration the filtering/scoping work specified in the OSI specs.)

jill

    re: .2 (a long time ago?)
    
.2> What happens if we encode the WITH in in_q and call directly an MM by
    
    It is our intention to encode the WITH clause in the AES and hence be
    passed in in_entity and not in in_q
    
    Even if you could predict how we could solve this, the problem is that
    fixing the MMs is only one aspect.  Presumably you'd like historical
    access to work as well - so the IM has to be changed.  It's not just
    a simple fix, else we would have done it by now.
    
    Colin

Re .-1

What is (are) the advantage (s) to encode the WITH clause into the AES ?

Regards

Pierre

For what it's worth, ISO treats an attribute compare (A<x) as having three
possible outcomes, True, False and "indeterminate", the last of course
for the case where there is no A. A simple application of tri-state logic :-)

Mark

    DECnet-ULTRIX CML currently does not match any entity which does not
    have a defined value for the filter attribute.  I think this is 
    what Mark meant but I'm not sure.  However, no error is returned 
    in this case.  You can always tell whether this is happening by
    just showing the filter attribute for the set of entities of interest.
    
    ben