Conference azur::mcc

The difference between the PMs is that the iconic map goes in this 
instance to the dictionary, where the FCL uses the parse tables. My
guess is you rebuilt the tables but didn't copy them to the mcc_system
directory. Please remember also that mcc_system is a search list
and will be searched according to the ordering listed, frist found is
the one used.

Hello,

We copy the MCC_PTB_PARSER.DAt from SYS$LOGIN directory to the MCC_SYSTEM
directory who is the same as MCC_COMMON.
The sympton explained in the first note remains......

Another idea ???

Regards

    The file is supposed to be MCC_PTB_PARSER.BPT not .DAT !
                                              ^^^
    
    -Matt.

    	Thanks for your answer it was really this MCC_PTB_PARSER.BPT that was
    not copied in the MCC_SYSTEM directory. Now all is working.
    
        But I have still a question about that. Is there a way to add a
    reference attribute to an existing global entity without having to
    redefine in the MSL file all the already existing reference attributes ?
    Is there a full documentation about MSL ?
    
    Regards.

Without modifying the dictionary and parse tables to know about the
new attributes you will not be able to use them. MSL it self is
documented in the system reference manual, with additional information
in the toolkit documentation, toolkit reference manual.

    Thanks, but where is it possible to find this SRM manual ? Our
    customer asked us to modify all the references attributes of the access
    modules. For the NODE4, NODE5, Ethernet and Bridge access module I
    could not find the MSL source files. They are not in the BMS kit. Is it
    possible to get them mainly to be sure that for each symbol we use we
    define the right code number and not an already existing one. For the TCPIP
    access module the MSL sources are provided.
    
    We need a very quick answer.
    

	RE .0

>>>    Thanks, but where is it possible to find this SRM manual ? Our

	See note 5.26 for the bookreader version.

	Order number AA-PD5LA-TE Vol 1
		     AA-PE55A-TE VOL 2


	JCE

I hope you got the mail I sent you off line for updating the node4 info
you sent me. If not please contact me and I will send it again

In general you don't need the source to create the procedures you are
looking for. The reference attributes for ALL classes are supposed to
be the same, if not the registration process should be kicking them out.
To find out what they are you can use dap and do a show command. This will
list you all of information for a specific entity class. Next to each
attribute you will find the associated code. You now need to delete the
existing attributes, and then write a small msl file to "AUGMENT CLASS xxx",
to get your new stuff in there. You should be able to write one msl that
you can use to augment each class you want updated, and reissue the
augment command for each of the classes to be modified.

If you need more assistance please call. 

>> The reference attributes for ALL classes are supposed to
>> be the same, if not the registration process should be kicking them out.

Jill,
 
    I don't think the above is true.  Last I heard the Registration FM
only requires the datatype of reference attributes to be latin1string.  
It doesn't do any validation.  At one time it was discussed that the reference
attributes would be architected, but this never happened.  It appears this 
way because we all used the same .MS include file to save time.

/Jim

Jim,

I didn't mean the registration FM, as you stated it doesn't care at all.
But, I was under the impression that (and I will check with Steve when he 
gets back) that the registration process (the paper one) would be checking
for consistency; maybe I was just confused with the partition codes and
names having to be consistent only.