[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

851.0. "Filter on the presence of an attribute" by ULTMAT::BELANGER (A ROSE by anyother name, would not be manageable) Thu Mar 28 1991 14:50

    
    Is it possible to supply a filter for the presence of an attribute
    through the mcc_call interface?  As an example:  There exsist a number
    instances of an object which contain a non-predictable attribute and a
    caller (through the mcc_call interface) requests information to be
    returned for all instances of this object for which the attribute is
    present.
    
    ~Jon.
T.RTitleUserPersonal
Name
DateLines
851.1you seem to be asking for WIThTOOK::CALLANDERThu Mar 28 1991 18:425
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).
851.2What if we bypass the PM ?RIVAGE::LAVILLATFri Mar 29 1991 10:3410
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
851.3in_qTOOK::CALLANDERFri Mar 29 1991 12:477
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.
851.4WITH requires a value, presence does not...ULTMAT::BELANGERA ROSE by anyother name, would not be manageableMon Apr 01 1991 13:127
    
    	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.
851.5the enforcer fm doesn't careTOOK::KOHLSRuth KohlsMon Apr 01 1991 13:1914
>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

851.6*I* think the answer is no.TOOK::KOHLSRuth KohlsMon Apr 01 1991 13:4717
    
>    	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
851.7there is a way...TOOK::CALLANDERMon Apr 01 1991 14:416
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.
851.8InterestingMARVIN::COBBGraham R. Cobb (Wide Area Comms.), REO2-G/H9, 830-3917Thu Apr 04 1991 09:2526
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
851.9filters and scopingTOOK::CALLANDERThu Apr 04 1991 12:2113
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
851.10TOOK::STRUTTColin StruttTue Apr 09 1991 21:2713
    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
851.11TENERE::LAVILLATWed Apr 10 1991 07:347
Re .-1

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

Regards

Pierre
851.12True False and MaybeCAPN::SYLORArchitect = Buzzword GeneratorTue Apr 16 1991 15:345
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
851.13an example...NAC::ENGLANDFri Apr 26 1991 01:598
    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