Conference azur::mcc

1185.0. "PROBLEM: Default Flag not always passed" by COOKIE::KITTELL (Richard - Architected Info Mgmt) Tue Jun 25 1991 18:33

V1.1 SSB

I know this sounds impossible, but FCL isn't always encoding the default
flag in ILV for a SET operation, depending on the order of the
attributes specified.

If the command is

SET BL CART AA0000 SIDE 0 desc = "Test text", readonly

the ILV is

[  0 ] (
    [  1 ] (
        [  62 ] (
            [  1 ]             03
            [  2 ]             54 65 73 74 20 74 65 78 74  -- Test text
            [  3 ]             00
            )
        [  67 ] (
            [  1 ]             01
            [  2 ] (
                [  5 ]
                )
            [  3 ]             00
            )
        )
    )

and all is as it should be, but if the order of the attributes on the
command line is reversed

SET BL CART AA0000 SIDE 0 readonly, desc = "Test text"

[  0 ] (
    [  1 ] (
        [  67 ] (
            [  1 ]             01
            [  2 ]             00
            [  3 ]             00
            )
        [  62 ] (
            [  1 ]             03
            [  2 ]             54 65 73 74 20 74 65 78 74  -- Test text
            [  3 ]             00
            )
        )
    )

FCL has now encoded the actual default value (False) into the ILV stream.
As long as the PM and the entity implementation agree on the default value,
the two ILV stream give the same results. But it is a curiosity nonetheless.

MSL for the two attributes is:

         ATTRIBUTE Description = 62 : Latin1String
           (* Free text string that can be used to describe the media,
              its use, or its contents. The value of this attribute does
              not influence the operation of the Media Library. *)
           SYMBOL = ATTR_DESCR,
           DEFAULT = ""
         END ATTRIBUTE Description;

        ATTRIBUTE ReadOnly = 67 : Boolean
           (* Used to control whether the Media Library is to allow
              writes to the Media. *)
           SYMBOL = ATTR_READONLY,
           DEFAULT = False
         END ATTRIBUTE ReadOnly;

    
    Right now, there is a bug in FCL (Jill has mentioned this one before)
    where sometimes it includes the displayed default value instead of
    encoding the "Implementation Default" value that is the architected
    approach for DECmcc V1.1.
    
    That was a change from DECmcc V1.0, where the Director encoded the
    actual value included in the dictionary (such as Default = False) and
    the AM told the entity that that is what it wanted.
    
    The fix apparently slips under some conditions (which I don't
    understand entirely).  Which for V1.1 is a bug (it wasn't supposed to 
    pass down the values).
    
    However, the new Entity Model is out, and the section about
    Director specified defaults has been clarified or changed (I don't have 
    an old copy handy).
    
    And now, the behavior that is a bug for 1.1 (encoding the actual value)
    is definitely the preferred behavior according to the new entity model.
    
    So its sort of six of one, half a dozen of the other right now, and
    we'll figure out which mode of operation is really a bug for V1.2.
    
    -Jim Carey
    
    

    I talked to Jim about this.
    
    The REAL entity model (v1.0) ha the corrected text - this was fixed at
    the last minute (thanks Mark S.)
    
    As documented in the SRM, when the user does not specify the value,
    the flag default is sent down, rather than the default value itself.
    Thus, the only use (I can think of) for the Director to know the
    default is to show it to the user to let them know what value will
    likely be chosen by the agent if the user does not supply the value.
    
    Colin

There are a number of cases as stated by Jim, and they get a bit confusing,
but suffice it to say that in your case my guess is that the one's you are
getting the flag for are the ones that have defaults without specifying
a default value (only the flag) in the dictionary.

Hopefully this will be fixed in V1.2 (it actually didn't make it onto the
fix list, so I will see what i can do to get it in).

jill