Conference azur::mcc

    Could you also post your definition of the ADD directive. The problem
    you are encountering looks like you (or some one else in your
    dictionary) has the ADD directive defined as an ACTION directive.
    You see this is checked on input, but on output we simply look
    up the reponse/argument information and can handle the output
    of the attribute_list data (since it is defined as the arguments
    data type).
    
    Now another thing to try if you don't feel real comfortable with
    DAP is to turn on the MCC_FCL_PM_LOG to 28 and to see if the
    partition argument if value 10 on the call (this means NULL, and
    is ONLY set to NULL on ACTION directives).
    
    jill
    

Jill,

Scroll .0 a little and you'll see the definition of ADD I'm using. It is
declared as Modify.

But I set MCC_FCL_PM_LOG to 28 as you suggested and got an attribute value
of 10, so FCL is somehow thinking ADD is an Action, right? Most curious.

MCC> register pbd aug8_nite
ATTRIBUTE PARTITION: 10

RE: .3

.2 was factual except for the example given. That was from the register
problem I've been working on, sorry.

I looked at the dictionary with DAP, and the DIRECTIVE_TYPE definition of
the ADD directive has a value of 1, or MCC_K_DIR_MODIFY.

When I do the ADD command with FCL logging set to 28, I get no logging
output, the error is returned immediately:

MCC> add pbd aug8_nite containers = {a}
%MCC-E-NOENTITY,  No corresponding entity instance exists

    
    The way the parse build works, it only reads the FIRST occurrence
    of a directives definition. To save time it assumes that the each
    definition is identical (because the registry is supposed to insure
    that). The quickest way to see which definition is in your way is
    to look at the MCC_PTB_PARSER.DAT and find the first occurrence
    of ADD.
    
    

    should have read .3 first.
    
    Okay since containers is defined as a set of something, PTB doesn't
    pull the "what it's a set of" into the tables. Instead the parser
    looks that up as it is needed. You might want to check on the
    definitions of the containers argument.
    
    

For the CONTAINERS ATTRIBUTE

   Definition Name = CONSTRUCTOR_DATA_TYPE
   Type = T   Length = 11   Count = 1   Defined = TRUE   Class = S   Usage = ILV

         (
          1 = (
              1 = (
                  3 = %X        03
                )
            )         )

   Definition Name = VALUE_DATA_TYPE
   Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
   value[1] = 52

(thats DT_SET_OF)

For the argument of the ADD REQUEST

   Definition Name = VALUE_DATA_TYPE
   Type = L   Length = 4   Count = 1   Defined = TRUE   Class = S
   value[1] = 66
(thats DT_ATTRIB_LIST)

    The error that you're seeing is the infamous "no entity instance
    exists" one, which I've explained to really mean "cannot find what I
    want in the Dictionary" elsewhere in this notesfile.
    
    As Jill pointed out before, FCL goes directly to the Dictionary when
    parsing constructor datatypes rather than the parse tables.  To access
    the Dictionary, it has to build the correct dictionary spec.  It looks
    like the dictionary spec isn't correct.  The parser either builds an
    "attribute" dictionary spec (CLASS x ATTRIBUTE y) or an "argument" 
    dictionary spec (CLASS x DIRECTIVE y REQUEST y ARGUMENT z), depending
    on the directive-type of the directive.
    
    There's a few possibilities here:
    
    1) When running PTB, some other global entity was processed first,
    	and that entity defined ADD as an action directive.  This will
    	cause the parser to build the wrong dictionary spec.
    2) Your MSL is incorrect, such that the right dictionary spec cannot
    	find what it needs.  This doesn't appear to be the case.  Your
        MSL looks correct.
    3) Bug in parser/PTB, where it picking up the wrong thing to switch
     	off on, when trying to decide which dictionary spec to build.
    
    Could you please check out #1 and #2 above for your situation, and
    we will check out #3 here.
    
    Thanks,
    Christine
    

It has gotten worse. Since I've been updating the dictionary every time I
fiddle with my MSL, I thought I'd get a clean start. I did:

$ COPY MCC_COMMON:MCC_DICTIONARY.DAT MCC_DICTIONARY.DAT
$ PURGE/LOG MCC_DICTIONARY.DAT
$ COPY MCC_COMMON:MCC_DEFINITION.DAT MCC_DEFINITION.DAT
$ PURGE/LOG MCC_DEFINITION.DAT
$ COPY MCC_COMMON:MCC_DISPATCH_TABLE.DAT []
$ PURGE/LOG MCC_DISPATCH_TABLE.DAT
$ MANAGE/TOOLKIT/DICTIONARY DELETE CLASS BRIDGE
$ MANAGE/TOOLKIT/DICTIONARY DELETE CLASS NODE
$ MANAGE/TOOLKIT/DICTIONARY DELETE CLASS NODE4
$ MANAGE/TOOLKIT/DICTIONARY DELETE CLASS SAMPLE
$ MANAGE/TOOLKIT/DICTIONARY DELETE CLASS STATION

This leaves me with a "developer's dictionary" that only contains entities
I'm working with, to wit:

DAP> show

   Class (1) : COMMON 52
   Class (1) : DOMAIN 8
   Class (1) : MCC 7
   Class (1) : PBD 80

Of those, PBD is the only class that defines an ADD directive, and its type
is:

DAP> show Definition DIRECTIVE_TYPE

   Definition Name = DIRECTIVE_TYPE
   Type = BU   Length = 1   Count = 1   Defined = TRUE   Class = S
   value[1] = 1

Next I run through a build /FROM_SOURCE, which compiles the MSL, loads
the service and management defs into the dictionary, and builds the
parse table. Also, recompiles and links the AM.

MCC> enroll mcc_dhsm_am
%MCC-E-NOENTITY,  No corresponding entity instance exists

Uh, oh. Now I'm in big trouble. But at the same time, perhaps this more
cosmic symptom will be a more obvious indication of the problem?

Looking at MCC_PTB_PARSER.DAT, I notice that ENROLL is there only for:

Command:  ENROLL MCC FCL
Command:  ENROLL MCC ICONICMAP

With the help of a couple of Jill's phone calls, I'm getting ADD dispatched
to my entry point now.

The primary reason I was getting NOENTITY was because my INIT routine opens
and reads the MIR, and was getting that error. Because that all happens
before the init breakpoint gets hit, it looked like it wasn't even getting
to my MM. I'll post a note about this to alert future generations.

Jill found a bug or two as we worked on that, they're on the list.

And finally, in order to get Add to dispatch I had to change the partition
from NULL to CHAR, so the dispatch entry looks like:

        mcc_dispatch_entry -
                ADD,-
                <mcc_entity <PBD,* >>,-
                CHAR,-
                DHSM_AM__PBD_ADD