Conference azur::mcc

    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.
    

    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

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.

    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.

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.

    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
    				:-)

>    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

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
	

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.

>> 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.                                                         

    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
    

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.

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.

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.