Conference azur::mcc

    The error messages you are getting are consistent with having the two
    MIR master repository files out of synch with each other.  If you look
    in MCC_SYSTEM: for MCC_MIR_DIRECTORY.DAT and MCC_MIR_ATTRIBUTE.DAT you
    will probably see the two files have different creation dates, and
    perhaps even different version numbers (God forbid they should be in
    two different directories!).  Even if they do not, chances are that
    something happened to one or both of the files.  How the wrong file(s)
    got there is worth investigating.  However, for the short term, if you
    find the right pair of files they should be moved back.  If you cannot
    find the right pair, there are two options.  1) copy empty files from
    the developers kit, or restore them from the bms kit. 2) with the V1.1
    DAP, there was code which know how to clean up the MIR master
    repositories (by deleting the records which were inconsistent), you
    just had to run it and it would do validation as part of its startup.
    Re-populating empty MIR master repositories is usually very simple,
    most management modules which use them simply recreate the entries
    as part of their startup.  You may want to re-run the IVP to make sure
    that the repository entries are properly recreated.
    
    Let me know if this helps.
    
    -Matt.

Oeps, f�utje (Ay Ay Ay, a big error) !!!

- I upgraded DECmcc from version V1.1 to T1.2.4.
- I updated the developers directory by copying and renaming the
  mcc_dev_fdictionary.dat and mcc_dev_fdictionary.bpt from the examples.mcc
  directory.
- I > FORGOT < to copy and rename the mcc_dev_mir_directory.dat and the
  mcc_dev_mir_attribute.dat into the developers directory.

This means that DECmcc was using the old (V1.1) mcc_mir_directory.dat and the
mcc_mir_attribute.dat. 

Thanks for your reply, It works fine now.

A happy developer......

It worked for a while but now I'm facing a real strange behavior of my code.

To explain, first a piece of stripped AM code:

do_directive()
{
   /* read contents of in_p */
   status = mcc_ilv_get_param_begin(...)

   /* find id_code */
   status = mcc_ilv_fnd_id(...)

   /* create descriptor for attribute */
   status = mcc_desframe_create_descriptor(...)

   /* get attribute with found id_code from in_p */
   status = mcc_ilv_get(...)

   /* create descriptor for private instance repository name */
   ....  /* see .0 */

   /* check if private instance repository exists */
   status = mcc_mir_get_repository_id(...)   /* see .0 */

   /* create repository if repository doesn't exist */
   if(status == MCC_S_NOREPOSEXIST)
      {
         /* create repository */
      }

   /* check if instance is in existing private instance repository */
   else
      {
         /* check for instance */
      }

printf("status = %d\n",status);

    /* instance doesn't exist */
    if(instance_exists == FALSE)
      {
	 /* create instance and generate success reply */
      }
     else
      {
         /* generate duplicate entry reply */
      }
}

This code with the printf() works just fine, but if I remove the (unnecessary)
printf() it generates an ACCVIO:

> %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=973C200E, PC
> =000E8AEC, PSL=03C00008
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> module name     routine name                     line       rel PC    abs PC
> 
>                                                            000E8AEC  000E8AEC
>                 /* number of lines deleted */
>                                                            001C4584  001C4584
>                                                            000C6E9A  000C6E9A
> MCC_MAIN        main                             8258      00000208  00001E3C
>                                                            000056F7  000056F7
> MCC_KERNEL_INIT MCC_KERNEL_INITIALIZE             163      00000027  0000572B
>                                                            000056D2  000056D2

If I go into the debugger everything goes fine until I reach the mcc system 
routine mcc_mir_get_repository_id() then the debugger responds with the message:

> %DEBUG-I-DYNIMGSET,
 setting image MCC_KERNEL_SHR
> %DEBUG-I-DYNMODSET, setting module MIR_COMMON
> %SYSTEM-F-ACCVIO, access violation, reason mask=01, 
> virtual address=97200002, PC=000E8AEC, PSL=03C0000
> break on unhandled exception at MIR_COMMON\mir_desc_mcc_copy\%LINE 8725+8
>
> %DEBUG-W-SRCLINNOT, source lines not available for module MIR_COMMON

What does this all mean ?
For the other mcc system routines it displays the following messages:

> stepped to MCC_PABX__CREATE\do_directive\%LINE 9764
>   9764:      if(status == MCC_S_NORMAL)
> stepped to MCC_PABX__CREATE\do_directive\%LINE 9765
>   9765:           status = mcc_ilv_get(&ctx, char_attr_dsc, &MCC_K_NULL_PTR);
    and continue with next step !!!!

Can somebody help me ?? I'm just getting a little confused !

Regards, Paul Goes.

    Are you sure ALL the fields in the descriptor are initialized
    correctly?
    
    -Matt.

Before you placed reply .4 I found out that the descriptor did not contain
right values for all fields. This was caused by the way I created the
descriptor.

I declared the descriptor variable:

MCC_T_Descriptor              pabx_inst_rep_name_dsc;

and created the descriptor:

pabx_inst_rep_name_dsc.mcc_a_pointer = pointer_to_name_string;
pabx_inst_rep_name_dsc.mcc_w_curlen = strlen(pointer_to_name_string);

This does not initialize all fields in the right way, but in the 
SRM (still for DECmcc v1.1) it is stated that for the argument 
repository_name for the routine mcc_mir_get_repository_id( ) only
the mcc_w_curlen field and the mcc_a_pointer field are checked in
the descriptor. This is correct for v1.1 but not for t1.2.4 anymore.

Now I create the descriptor using the mcc_desframe_create_descriptor() routine.

It works fine now !!!

I hope it stays fine !?!

Thanks for your replies Matt !

Regards, Paul Goes

  fwiw ...

  If you take a look at the Example FM (included with the DECmcc toolkit
  v1.2) -- there is a set of MIR routines which do all the 'dirty work'
  for you.

  The files to look at are:

	'mcc_example_fm_library.c'
  and	'mcc_example.h'.

  Examples for the use of these routines are throughout the rest of the 
  Example FM Source code.

  The routines have a simpler interface to the MIR and take care of the
  problems you have been describing regarding 'is the MIR already created'.

  Also, these routine perform all the ILV encoding and decoding for you
  transparently...providing you use the simple MCC datatypes.

  Please take a look at these - and use them if you like.  We would appreciate
  any feedback you may have.

  Keith Roberts
  DECmcc Toolkit Team


                    Example FM Library MIR routines

 *  exlib_mir_open                - Opens a connection to a MIR         *
 *  exlib_mir_create_instance     - Creates a MIR Instance              *
 *  exlib_mir_select_instance     - Selects an existing MIR Instance    *
 *  exlib_mir_put_attribute       - Puts an attribute in the MIR        *
 *  exlib_mir_get_attribute       - Gets an attribute from the MIR      *
 *  exlib_mir_set_attributes      - Process In-P & Update MIR Attrs     *
 *  exlib_mir_close               - Close the connection to the MIR     *
 *  exlib_mir_cancel              - Cancel the connection to the MIR    *
 *  exlib_mir_set_time_stamp   +  - Set Time Stamp for Write Attr data  *
 *  exlib_mir_set_time_range   +  - Set Time Range for Read Attr data   *
 *  exlib_mir_get_time_stamp   +  - Get the Attr record Time Stamp      *
 *  exlib_mir_next_time        +  - Get next Attr record for Time Range *
 *  exlib_mir_next_instance    +  - Get next Wildcarded Instance        *

                               +  These routines are only stubbed in 

  While it was not the intent, the SRM does imply in the description of the
  mcc_mir_get_repository_id routine that it is valid to send in a garbage
  descriptor with only the mcc_w_curlen and mcc_a_pointer fields set.  The
  intent was that only those two fields were validated by that routine.  In
  any case, the SRM will be QAR'ed on the basis that it implies that invalid
  descriptors are legal.

  It is ALWAYS illegal to pass an ill-formed MCC descriptor to a DECmcc routine.
  There are cases where fields are written by a kernel routine or where a field
  of the descriptor is completely irrelevant to a routine.  These cases should
  be documented in the description of that routine in the SRM.  As a general
  rule, all fields of a descriptor must be initialized.  A descriptor where the
  maxstrlen field is garbage and the curlen field is set will be valid only
  when the random data in the maxstrlen field is greater than or equal to the
  curlen field.  The maxstrlen field indicates how much memory is allocated for
  the buffer pointer to by the mcc_a_pointer field.  The curlen field tells
  how much data is currently in that buffer.  The curlen field alone does not
  provide enough information.

  In the case cited earlier, it is likely that a bogus mcc_l_dt field caused
  the problems.  The mcc_mir_get_repository_id routine uses (but does not
  validate) the mcc_l_dt field.

  								- Dave