Conference azur::mcc

    VIA PATH is not currently used (V1.2, V1.3).  It will be used in the
    release after V1.3 (what we have been calling MCC V2.0).  As specified
    (but not very clearly) in the SRM, the qualifier is placed in the IN_Q
    parameter of the MCC call, where is it is take out and interpreted by
    the IM/Dispatcher, and used to re-route MCC calls to remote management
    modules.   Even if it isn't removed from the IN_Q, the qualifier is
    only useful to the IM/Dispatcher for interpretation. It is safe to
    ignore this qualifier, it is also safe to not worry about copying it
    into another MCC call.
    
    -Matt.
    

Matt,

Thank you very much for the answer. Whould you, please, clarify couple thing:

    > ... the qualifier is placed in the IN_Q parameter of the MCC call

by which component? If our module is called by another FM, may this FM place
VIA PATH qualifier into IN_Q? If yes, does it mean that it supposed to be
proccesed and removed by IM/Dispatcher before passing control to our module?

    > It is safe to ignore this qualifier

but not to reject it, right?

BTW, what is the path and how it supposed to be specified?

Best regards,
Gene.

P.S. Any light on VIA PORT?

    To continue on the VIA PATH discussion.
    
    Generally, the component is the PM.  It will be valid (again, we are
    talking about a two releases in the future) for ANY Management Module,
    PM, FM, or AM to specify the VIA PATH qualifier.  If you can think of a
    clever reason for an FM to plop a MCC Director name into the VIA PATH
    qualifier, good for you!  (What is it?)  As the Service Provider of an
    MCC Call, you will not see it, period.  You can look all you want, but
    you won't find it.  It's your time, your money, ...  The point is that
    when you make an mcc_call_xxx, the IM/Dispatcher will grab the VIA PATH
    qualifier right away and the Management Module on the other side of the
    call will never know the VIA PATH was specified.  Think of it as being
    similar to the NCP TELL functionality.
    
    Details about the purpose and use of the VIA PATH qualifier will be
    described in the MCC V2.0 documentation along with the rest of the
    Distributed MCC functionality, which is still being written.
    
    -Matt.

Matt,

Thank you very much for the answer.

>   If you can think of a
>   clever reason for an FM to plop a MCC Director name into the VIA PATH
>   qualifier, good for you!  (What is it?)

Of course I can not, because I don't know what it is and that is the reason
why I have posted this note.

>   As the Service Provider of an MCC Call, you will not see it, period.

Great.

>   You can look all you want, but you won't find it. 
>   It's your time, your money, ...  The point is that    

The point has been, that I din't know what is that, and what to do with it.
For current implementation it is a piece of cake to find it: just look into
IN_Q.

After your explanation, I understand, that if VIA PATH qualifier somehow would
manage to sneak into IN_Q parameter delivered to our module (which not supposed
to happen), the best thing to deal with it is to reject it with proper exception
returned.

Thank you very much indeed,
Gene

    Gene,
    
    I think I now understand your persistence about what to do with this
    parameter.  From you last reply I take it that you are not simply
    doing an mcc_ilv_fnd_id() call to search for just the qualifiers that
    you are interested in.  If you are going to the trouble of analysing
    each possible qualifier (which is a perfectly reasonable thing to do)
    then returning an exception in this case makes sense to me.  Sorry if
    I over-emphasized my point.  Most implementations I have seen either
    ignore (drop), or propagate qualifiers they don't know what to do
    with. I have not seen a consistent use of how to treat qualifiers that
    do not get processed by the MM.  Although technically, I guess they
    should return exceptions.
    
    -Matt.
    
MCC> register node4 .haynes syn =haynes, via port 1

Node4 LOCAL_NS:.haynes
AT  2-OCT-1992 11:16:52

Registration successful.
MCC> director node4 haynes, by user=doesnotexist, by password=nosuchpassword

Node4 HAYNES
AT  2-OCT-1992 11:30:21

Directory successful.
                        Registered Name = LOCAL_NS:.haynes
                                   Name = HAYNES
                                Address = 4.314
MCC> sho domain *, via port x
Using default ALL IDENTIFIERS

Domain LOCAL_NS:.eu.by.byl.q18h
AT  2-OCT-1992 11:19:01 Identifiers

Examination of attributes shows
                             DomainName = LOCAL_NS:.eu.by.byl.q18h

Domain LOCAL_NS:.pca_test
AT  2-OCT-1992 11:19:01 Identifiers

Examination of attributes shows
                             DomainName = LOCAL_NS:.pca_test
MCC> sho domain pca_test rule *, via port x
Using default ALL IDENTIFIERS

Domain LOCAL_NS:.pca_test Rule *
AT  2-OCT-1992 11:19:26 Identifiers

This request cannot use the 'Via Port' qualifier
               Unsupported Qualifier Id = Via Port
MCC>

Aha!

It is nice to know that sometimes persistence pays off. Thank you, Matt.

>   From you last reply I take it that you are not simply
>   doing an mcc_ilv_fnd_id() call to search for just the qualifiers that
>   you are interested in.  If you are going to the trouble of analysing
>   each possible qualifier (which is a perfectly reasonable thing to do)
    !!!!

Exactly! And the Design Framework Prototype does the same!

Also according to SRM for some of the mcc_call parameters it is explicitly
stated that they should be validated. For some it it stated that they should
be validated only if the module is going to use them. In any case no explanation
is given what kind of validation should be performed. If for some of the
parameters it is quite obvious what is it, for some, and IN_Q is among them, it 
is far from being obvious.

Sorry, it has been my implicit assumption, that everyone does the validation
of all parameters.

You have reformulated basically all my questions quite succinctly:

>   Most implementations I have seen either
>   ignore (drop), or propagate qualifiers they don't know what to do
>   with. I have not seen a consistent use of how to treat qualifiers that
>   do not get processed by the MM.

i.e. what is a consistent use of the qualifiers?

Sorry, I am a little puzzled by the second part of your reply. My only
interpretation for now is, that some commands accept some of the qualifiers,
without doing anything with them, and some simply reject them.
Am I right or not?

Thank you,
Gene

    Yes.  I was demonstrating my point.  VIA PORT on a register might be
    used by the AM.  Maybe.  But it was ignore entirely (no such thing as
    Port 1 on node4 haynes).  In fact, every qualifier given in my example
    was garbage.  And they were conveniently ignore.  Except for the last
    one. Alarms refused to ignore it.  Is Alarms correct? or is the
    Registration-FM, Domain-FM, DNA4-AM, etc. correct?  I don't know.  The
    SRM is sufficiently vague on the point.  Section 4.3.5 in chapter 4
    describes the logic to use, but does not describe to the ORDER in which
    to analyze the options. For example: It's okay to recognize and
    ignore a qualifier, and it's okay to return an exception if you do not
    support it.  Well, what's the difference between ignore something and
    not supporting it? 
    
    My *guess* would be the following:
    
    1) Determine if your MM is the target of a qualifier.  For example,
       the Register command needs to do SHOWs to the AMs, so some
       qualifiers, like BY ACCOUNT, BY USER, BY PASSWORD, need to be
       passed down.
    2) If the qualifier does not affect the service offered, ignore it.
    3) If the qualifier MAY affect the service offered (for example, the
       time qualifiers), but it is not supported, return an exception.
    4) If it does affect the service offered and it is supported, then
       process it.
    
    I think step 3 is the key step.  It is up to each MM developer
    determine which qualifiers may affect the service offered.
    
    -Matt.

.7>    My *guess* would be the following:
.7>    
.7>    1) Determine if your MM is the target of a qualifier.  For example,
.7>       the Register command needs to do SHOWs to the AMs, so some
.7>       qualifiers, like BY ACCOUNT, BY USER, BY PASSWORD, need to be
.7>       passed down.
.7>    2) If the qualifier does not affect the service offered, ignore it.
.7>    3) If the qualifier MAY affect the service offered (for example, the
.7>       time qualifiers), but it is not supported, return an exception.
.7>    4) If it does affect the service offered and it is supported, then
.7>       process it.
.7>    
.7>    I think step 3 is the key step.  It is up to each MM developer
.7>    determine which qualifiers may affect the service offered.
.7>
    
    The trick here is knowing which ones apply to case 3. Back to the
    original note (.0) which refers the the tables in the SRM.  A
    management module need only worry about the qualifiers that are
    intended for the target management module. They should not worry about
    qualifiers that are handled by the PM, IM and/or dispatcher. Refer to
    table 5.1 in the SRM.

Thank you, guys.

I am afraid that the main trick here is that all this discussion is not
presented in the SRM, hence all these questions. For instance, I have had no
idea, that VIA PORT is not implemented yet and not supposed to be passed to MM.

Matt's '*guess*' is what I'd like to see in the SRM.

I only disagree with 

	2) If the qualifier does not affect the service offered, ignore it.

Let me explain. My impression is that MM should behave identically doesn't 
matter is it called by PM or by FM or AM. My experiments have shown, that 
if MM is called by MM other then PM, than anything may be put into ILV passed
through IN_Q parameter. As result, some elements of ILV may have the same ID
as recognizable qualifiers, with values which may have sence or not, and some
elements of ILV has unrecognizable ID. So just simply to ignore qualifier
doesn't look right to me.

I would probably rewrite Matt's table as follow:

Let's call all qualifiers, which may be passed to FM or AM, recognizable
qualifiers. As result the following:

	BY ACCOUNT
	BY PASSWORD
	BY USER
	VIA PORT

	and some others (sorry, I cannot provide the full list, because it
	is not clear to me yet, and hence all my questions. I hope the future
	SRM will do it for all of us).

are the recognizable qualifiers.

The qualifier

	VIA PATH

is not.

1) Determine if your MM is the target of a qualifiers. If there is at least one
   unrecognizable qualifier, return UNRECOGNIZED QUALIFIER exception.

2) If the qualifier MAY affect the service offered (for example, the
   time qualifiers), but it is not supported, return UNSUPPORTED QUALIFIER
   exception.

3) If it does affect the service offered and it is supported, then
   process it.

4) If MM needs a qualifier and it is not provided, return MISSING QUALIFIER
   exception.

BTW, Matt's example in 1)

>	For example,
>	the Register command needs to do SHOWs to the AMs, so some
>	qualifiers, like BY ACCOUNT, BY USER, BY PASSWORD, need to be
>	passed down.

I consider belongs to case 2) or 3) above.

That is my understanding now, how qualifiers should be processed. If I am
wrong, please, correct me, I am just learning. If I am right, confirmation of
this fact will be very encouraging.

Thank you very much.

Best regards,
Gene

> RE: 3837.9
>
> For instance, I have had no idea, that VIA PORT is not implemented
> yet and not supposed to be passed to MM.

	You mean "VIA PATH" wasn't implemented, right?

    Yes, VIA PATH of course.
    
    Gene

    An earlier reply in this stream seem to imply that the VIA qualifiers
    were not impelemented or used in V1.2 or V1.3.  I hate to surprise you
    but they are used very heavily in the POLYCENTER SNA Manager AM.  The
    fact that registration, grapher, and notifications drop VIA PATH, and
    VIA MANAGER (yeah that's a new one special for SNA Manager!) before
    doing their shows causes them to be nearly unusable in complex routing
    sitations with IBM systems.  I've not gotten exporter or historian to
    work yet, but I assume they'll drop the qualifiers too, making them
    also difficult to use.
    
    Sally Martin