Conference azur::mcc

    The error message that you're seeing -- "entity instance not exist" --
    is very misleading to the user.  It actually means that the PM could not
    find what it needed in the dictionary in order to display the output.
    When this happens, there are two possibilities:
    	1) the info really isn't in the dictionary, or
        2) the ILV encoding is incorrect
    
    Looking through your ILV encoding, the culprit looks like step 4.
    For SetOf datatype, you'll have to use an ID of 1, not 0.  For
    constructed datatypes where the field id's are specified in the MSL,
    you always use 1, or start at 1.
    
    Hope this helps,
    Christine
    

    ALWAYS use 1 for MCC_L_ID of the members when dealing with SET_OF. 
    Any other id will generate an error.
    
    .. Jesuraj

    With regard to MCC_S_NOENTITY being passed all the way out to the user,
    this is a crock that needs to be fixed.   At least in the short term
    change it to say something like "needed info not in MIR or DICT"
    because the "entity" it's talking about is rarely the one in the user
    command so as Christine said, it's misleading to the grossest extent.
    
    

Thanks for the help Christine and Jesuraj, I'm getting my set of Latin1Strings
out now.

  Reading the descriptions of the Implementation and Component datatypes in
  the SRM has got me confused. Implementation says it is a SET OF Components,
  where each Component is a record with two fields, component name and
  component version.

  But Component says it is an enumeration. Both descriptions say that the
  data type of the version field should be "registered with the component
  name". Huh?

  Can someone post an MSL fragment showing the use of Implementation?

  For ILV, it looks like each attribute of type Implementation starts
  a new construct for the SET OF Components, then each Component starts
  another construct to pass the fields of the record (if it is indeed a
  record).

  Thanks for the help, we're making progress.

    For V1.0, the FCL does not support Implementation.  Component is
    minimally supported, in that it is displayed as an octet string.  It's
    unclear when full support for these two datatypes will be provided.
    
    As to confusion between the SRM descriptions, it sounds like the
    description for the Component datatype may actually be the description
    of the component name that is described in the Implementation section.
    Dave Moore is currently making updates and clarifications to the
    datatypes chapter for the next release of the SRM.  I will check with
    him on this when he gets back next week.
    
    Christine
    

Thanks again, Christine.

Just for the benefit of the next person to ask this question, here's the
MSL bits for an Implementation type that works.

    TYPE AComponentName = 1002 (VMS = 1,
                                DECmcc = 2,
                                DHSM_AM = 3,
                                PBD = 4);
    TYPE AComponent = 1003 RECORD
        Name = 1 : AComponentName;
        Version = 2 : Latin1String;
    END;
    TYPE AnImplementation = 1004 SET OF AComponent;
  
             ATTRIBUTE implementation = 5 : AnImplementation
                ACCESS = NONSETTABLE,
                DISPLAY = TRUE,
                SYMBOL = ATTR_Implementation,
                DEFAULT = NO DEFAULT,
                CATEGORIES = ( CONFIGURATION )
             END ATTRIBUTE Implementation;
 
For the ILV, you begin a new construct for the SET OF, and then for
each member of the set begin another new construct, put the two record
fields with ids of 1 and 2, and close the construct. After the last member
close the construct to complete the set.

The pseudo entity implements the attribute as:

#define VERSION_LEN 10
#define IMPLEMENTATION_COMPONENTS 4

typedef struct
{
        MCC_T_Enumeration component_id;
        char version[VERSION_LEN];
      } dt_component;

I must be getting the hang of this, because it worked the first time:

                         implementation = { (            Name = VMS,
                                                      Version = "5.3" ),
                                            (            Name = DECmcc,
                                                      Version = "T1.0.1" ),
                                            (            Name = DHSM_AM,
                                                      Version = "X1.0.0" ),
                                            (            Name = PBD,
                                                      Version = "X1.0.0" ) }

    ILV encoding/decoding of constructed data types (SET, SETOF, SEQUENCE,
    RECORDS Etc..) is a common problem. I have written some routines that do the
    the required job. I have some documents on the use of these routines.
    If you are interested, please send a mail.             
    
    Jesuraj 

    
    I am a bit confused. In some places you placed ... to signify that
    you left pieces out, but about half way through you have a call
    to mcc_desframe_create_descriptor with no arguments (after the put
    cons on the attribute list). You might want to check your cut and
    paste.
    
    On another note, I would also suggest that you add error handling
    after each call to ILV so that problems get detected earlier. And
    I know the old SRM is unclear on what "mode" you are in when you
    have just done a put param begin, I don't know if the new SRM
    is any better, but I do know that in my code I do supply the data
    type for the attribute list on the put cons. Also the level of
    indirection on the put cons for the attribute list reason code is
    incorrect, it should be a pointer to an unsigned long (&MCC_K_NULL_PTR,
    please note I am not advocating &<constant> usage though, it is
    not portable coding pratices). Also the PM expects the attribute
    list id code to be a one (1).
    
    I would be interested in knowing if you had had something working
    without the SET_OF in there. And, if you did have something working
    I would be interested in the ilv dumps of that. Define the
    MCC_FCL_PM_LOG to 8 and enter your command. This will give you the
    ilv dump information I am looking for.
    
    In an ilv dump it should look something like:
    
    [reply code] (			<-- put param begin
        [1] (				<-- put cons
    	    [attr code] (               <-- put while in list mode
    		[1] MCC_K_DT_type  
    		[2] value_of_non_contructed_attr
    		[3] reason_code
                )
    	    [attr code] (		<-- put cons while in list mode
                [1] MCC_K_DT_type
    		[3] reason_code
    		[4]  ---- this has the construction element values
    		)
    	     )
    	)
    
    
    
    

    Thanks,
    I only left out the error handling and arguments to save space in
    the note (not in the actual code).
    Someone pointed out the error to me, in mcc_ilv_put, it should be
    MCC_K_NULL_PTR instead of &MCC_K_NULL_PTR.
    Carol