[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

1448.0. "Query: Wildcard Instance on Create?" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Wed Sep 04 1991 16:21

        Does anyone have any technical or philosophical objections to
        allowing a wildcarded instance on a create?

        We've got some situations where we want to allow the name of
        an instance to be selected by the instance's parent, instead
        of being specified in the request. It seems like there are
        two ways of accomplishing this via MCC:

          1. Supply a wildcard for the instance name:

              $ MCC>Create BranchLibrary x Cartridge *

                 BranchLibrary x Cartridge AA1001 created successfully

          2. Use a reserved instance name to do the same thing. The
             difference is that MCC *thinks* it sees an instance name,
             the managed object just doesn't use it that way:

              $ MCC>Create BranchLibrary x Cartridge MLS$Generate

                 BranchLibrary x Cartridge AA1001 created successfully


        I've tried the wildcard method with both FCL and the Iconic
        PM, and the Create is accepted just fine. But I'm asking just
        to see if it works because it is supposed to, or I just lucked
        out and it may go away some day.

        If it is supported, can a Create have multiple responses just
        like other directives with a wildcarded target? If so, I can
        put a count argument on the Create and create multiple
        instances with the same attribute values but with different
        instance names.

        Thanks,

        Richard
T.RTitleUserPersonal
Name
DateLines
1448.1It will probably work, however,...TOOK::GUERTINDon't fight fire with flamesThu Sep 05 1991 11:4327
    The only thing I can think of for restricting the feature in the
    future:
    
    I had always believed that conceptually the wildcard represented
    EVERY object, as opposed to ANY object.  I believe that you
    want a way to represent *any* object.  For example, in VMS:
    
    $ DIRECTORY *
    
    means show me EVERY file specification, not show me ANY file
    specification.  True or false:  You want the Create command to
    generate a unique name for the user, and therefore need some kind
    of placeholder to indicate to the Service Provider that the
    Service Provider should define the name.  If my understanding of
    the wildcard character is correct, then specifying a wildcard on
    a Create means, "Create every possible entity".  At first glance
    this may sound absurd.  However there are some child entities
    which have instances of numbers which can range from 1 to 8, for
    example (port-like objects?).  In a case like this, it may be
    reasonable for the user to create all of them at one time. So how
    would he do it?  Wildcard?  We should NOT have wildcard on Create
    convey two different concepts, it does unrecoverable damage to the
    user's brain cells.  If we use wildcard on Create to represent
    ANY, then we should not let it represent EVERY.
    
    -Matt.
    
1448.2TOOK::STRUTTManagement - the one word oxymoronThu Sep 05 1991 13:2521
    I believe that use of a wildcard on a create to mean: the service
    provider will choose a name, is inappropriate, and unecessary
    overloading the semantics of "*".
    
    OSI management has the concept of names being assigned by the agent
    rather than by the manager. We need to add this concept into EMA/MCC,
    and therefore we need to have some way of specifying this desired
    behaviour at the user interface.  I don't think * is right - neither
    do I think that MSL$Generate is intuitive.
    
    Anyone have any user-interface suggestions for how the user should
    request instance name assignment by the agent on a Create?
    
    
    As for a create having multiple responses - hmmmm, seems dubious.
    Again, OSI management does not permit this.  Maybe what is needed is
    the primitive Create as we have it now which does not allow multiple
    response, but adding a new action directive which accomplishes what you 
    want.
    
    Colin
1448.3what is the parent expected to do and know?TOOK::KOHLSRuth KohlsThu Sep 05 1991 13:578
It might possibly shed some light on this ought to be done if you could 
explain how the instances' parent knows what to do--how many children
to create of what kind, and how is the number and kind of child instances
changed?  This particular create directive appears to cause the parent to run 
an initialization script, instead of having the create directive issued by an 
initialization script.

Ruth K.
1448.42 cents from a non-UI person...TOOK::GUERTINDon't fight fire with flamesThu Sep 05 1991 14:2912
    RE:.2
    
    Colin, In essence, what you describe probably would require a new Verb.
    For example, Generate, Produce, Make, Beget, etc.  Generate implies an
    algorithmic process takes place.  For example, several non-DEC
    implementations Generate new UIDs (they do not Create them).  Produce
    implies something is constructed (i.e., results in a Product). And so
    on.  Without knowing more about the intention of a Create whose
    Instance is defined by the Service Provider, any one of these might
    make sense.  Looks like this needs a Mega-Architect type to resolve :-)
    
    -Matt.
1448.5Create NextCOOKIE::KITTELLRichard - Architected Info MgmtThu Sep 05 1991 15:2322
Thanks for the replies. Matt makes a useful distinction between the ANY 
and ALL interpretations of *. 

It turns out we don't need to Create more than one instance. We have
a Generate verb specified already for multiples, I just thought maybe we could
get rid of it if Create would do it all. Considering Colin's comment about
OSI not supporting multiple Create replies, we'll keep Generate.

So it sounds like there is reasonable justification for having the 
agent/MOM/parent supply the name of a created instance. And good reasons to
not use * to do it.

Ruth, on any of the creates the parent is expected to authorize the creation
based on the requestor's rights. The only additional expectation for the
Create Next semantics is that the parent will select a name for the instance
from some range of valid names and unique relative to any existing
instance name, and advise what name it picked in the reply.

Create Next will only create one child. Generate takes an argument to 
indicate how many to create. Both take optional arguments that supply initial
attribute values for the created instances.
1448.6Generate, or define special meaning in the data typeCAPN::SYLORArchitect = Buzzword GeneratorFri Sep 13 1991 01:3914
    I've recommended a Generate action on the parent to create multiple
    children, with arguments either saying "how many" or some
    pattern/range.
    
    No one has yet suggested a good way to indicate "chose a name" with
    some generic symbol. My choice would be ?, but unfotunately, that's
    reserved in NCL for wildcarding. So far, I've recommened this be part
    of the data type definition. For example, if the identifier type were
    UNSIGNED, one might interprete the value 0 to mean "chose the next
    highest", just like VMS file versions.
    
    				Mark
    				High priest of arcane entity model rules
    				:-)
1448.7need something to get us throughCOOKIE::KITTELLRichard - Architected Info MgmtFri Sep 13 1991 15:3824
>    reserved in NCL for wildcarding. So far, I've recommened this be part
>    of the data type definition. For example, if the identifier type were
 
Indeed, that works fine for the entity we need this for that has an
identifier of UNSIGNED32. And we use "generate" on the parent for creating
multiple children. So we're mostly in sync with the priesthood. (Done any
good sacrifices lately? :-) )

The sticky wicket for us remains SimpleName. I'm pretty much resigned to
reserving a string to indicate the make-me-a-name request for the
foreseeable future, and support the architected mechanism once it is defined.
So Feel the Force, Mark, and give me your preference for a SimpleName
value that we won't ever want to use for an instance id (it could still be
used for attribute values, it is special only as the target for a Create).
If we can't come up with something better in the next few weeks I'm going
to go with

 Create BranchLibrary <explicit name> Cartridge FAC$GENERATE 

where FAC is MLS (for Media Library Services) or some more general
facility like EMA, DEC, ???

Richard
1448.8Some suggestionsBLUMON::SYLORArchitect = Buzzword GeneratorFri Sep 27 1991 20:1824
Well, I'm back.

There's no gospel here. We need to try out a few ideas and see what works best.

My preference is to do the easiest thing for generating a *single* entity with
a simple name as an instance identifier. I.e., Use "" to signal, look agent,
YOU pick a name.

If you want to create a *bunch* of objects, all with similar names, I like 
a solution that the SNA Gateway guys thought up. Use a "pattern" - like

GENERATE Branch Lib <your name here> Number Range=75..125, Prefix=HorseCart

would generate something like
	Cartridge HorseCart075
	Cartridge HorseCart076
	...
	Cartridge HorseCart125

Of course *you* get to define the algorithm for generating names, it
can be as simple, or as complex as you like.

			Mark
	
1448.9Null name it isCOOKIE::KITTELLRichard - Architected Info MgmtMon Sep 30 1991 12:497
Thanks Mark, I hadn't even thought of a null name, and assumed it was invalid.
But I just tried it from FCL on my prototype, and the proto quite happily
created an instance with a null name (lesson there for those of you who
might want to *prevent* null instance names).

We'll use Generate for multiple instances, and null name for a single.
1448.10Yes, but then you got a PM presentation problem...RIVAGE::LAVILLATTue Oct 01 1991 08:0349
>> We'll use Generate for multiple instances, and null name for a single.

We (PNMP) are interrested in this discussion since we have similar problems.
We would like also to use this "null instance" for create, but...

I tried with my own proto a : CREATE OS x TEST "" that substitute the "" by
something, "toto" for example.

The problem is that both FCL and IM PM seems to forgot to look at the out_entity
when they display the response, which is confusing for the user, since he has
no way to know what was the actual name given to the created entity !

Here is an FCL output, where in fact "" was substituted by "toto" :

MCC> show os a t toto
Using default ALL IDENTIFIERS

OSI_SYSTEM LOCAL_NS:.a TESTOBJ "toto"
AT 1991-10-01-09:50:41 Identifiers

No such entity: OSI_SYSTEM LOCAL_NS:.a TESTOBJ "toto"
                         Unknown Entity = OSI_SYSTEM LOCAL_NS:.a TESTOBJ "toto"
,
MCC> cre os a t ""
                    
OSI_SYSTEM LOCAL_NS:.a TESTOBJ               <-  ### Wrong out_entity ###
AT 1991-10-01-09:50:57

Entity successfully created.
MCC> show os a t ""
Using default ALL IDENTIFIERS
%MCC-E-INV_IN_ENTITY, software error: invalid in_entity (input entity) parameter
MCC> show os a t toto
Using default ALL IDENTIFIERS

OSI_SYSTEM LOCAL_NS:.a TESTOBJ "toto"
AT 1991-10-01-09:56:43 Identifiers

Examination of attributes shows:
                            Objectclass = "121243605013101

                                   ToId = "121243605012143


Any comments ?

Regards.

Pierre.                                                         
1448.11AM problem?COOKIE::KITTELLRichard - Architected Info MgmtTue Oct 01 1991 17:2912
    Pierre,
    
    Are you saying that the access module is returning a non-null instance
    name in the out_entity of the create call, and the PM isn't specifying
    it?
    
    I would think it more likely that the AM doesn't anticipate having an
    out_entity different from the in_entity, so it doesn't update the
    out_entity with the name of the created instance. Could that be?
    
    Richard
    
1448.12Probably not.TENERE::LAVILLATWed Oct 02 1991 06:2524
re: -1.

>    
>    Are you saying that the access module is returning a non-null instance
>    name in the out_entity of the create call, and the PM isn't specifying
>    it?

Yes.

>    I would think it more likely that the AM doesn't anticipate having an
>    out_entity different from the in_entity, so it doesn't update the
>    out_entity with the name of the created instance. Could that be?
>    

In fact my AM is not supposed to handle this, I just made my tests using some
deposit under dbx (I am using MCC T1.2.2 on MIPS Ultrix). 

Anyway I am quite sure I did not made any mistake : I did this test many times
under both FCL and IMPM, checking at the end of the call the values of the
in_entity and out_entity using mcc_aes_dump.

Regards.

Pierre.
1448.13that is strangeTOOK::CALLANDERMCC = My Constant CompanionTue Oct 08 1991 12:475
I know that the fcl looks at the out_e, because domain FM uses out
entity to let you know what entity level is returning the problem.
If you could run your command again with the fcl log bit set to 8
and send me the dump I would be interested in seeing what is going on.

1448.14Forget it !!! Sorry...TENERE::LAVILLATFri Oct 11 1991 11:0716
Sorry I was completely wrong !!!

What happen in fact is that I did a deposit (via mcc_aes routines) a value in
the out_entity parameter, but did not realized that my code was overwritting
this value at the end of the call !

In fact this works perfectly well : you can have an out_entity value different
from the in_entity value during a CREATE directive. The out_entity is
correctly displayed by FCL at the end of the call.

Thanks and regards

Pierre.