[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

83.0. "QUESTION - MIR routines" by TENERE::FLAUW () Mon Mar 26 1990 10:04

    
    
    I encountered the following problem with the MIR routines : 
    
    A private repository is created in an AM context using code similar to
    the example of the SRM paragraph 10.12. It works perfectly well. 
    
    If I take that same piece of code creating the repository and make it a
    stand-alone program (no INIT, PROBE and LOG) linked with the kernel
    shareable image, I got an access violation in the
    MCC$MIR_CREATE_REPOSITORY routine. 
    
    I thought that one of the big advantages of having the kernel being a
    shareable image was that *all* MCC routines will be callable from
    external applications. It doesn't seem to be true for MIR routines. 
    
    Am I missing something or is it a bug ? 
    
    Thanks and regards,
    
    Marc.    
T.RTitleUserPersonal
Name
DateLines
83.1Yes, there is a bug somewherePETE::BURGESSMon Mar 26 1990 20:0610
    Yes, *all* MCC routines are available in the mcc$kernel_shr image.
    
    So there is definitely a bug either on my side of the interface or
    on your side.   
    
    I'd like to recreate your problem on my system.  Could you send
    me a small source program with the significant code?  
    
    Pete Burgess
    
83.2QARedTENERE::FLAUWTue Mar 27 1990 08:3310
    
    Peter,
    
    I have Qared it as QAR 70 in mcc_int database.
    
    The pointer to the source file is given in the QAR.
    
    Thanks and regards,
    
    Marc.
83.3Missing lib$initialize psectPETE::BURGESSTue Mar 27 1990 21:0719
    The forthcoming SRM eco on using callable mcc will present
    the full story on building executable images. The information which you
    were missing is that today (ie it's temporary) the executable must contain 
    a special object module (mcc$kernel_init.obj) which contains a
    lib$initialize psect contribution.  Before the executable's main
    routine is called, lib$initialize will call the mcc$kernel_initialize
    routine to initialize the multi-threading environment and prepare the
    current context as a thread.
    
    Because callable mcc has not yet been completely announced (ie SRM
    update), the object module was not included in the ut1.0.0 kit.
    
    
    I hope to provide toolkit developers with everything for the
    eft update kit.
    
    /Pete Burgess
    
    
83.4Thanks, Pete.TENERE::FLAUWWed Mar 28 1990 05:156
    
    Thanks, Pete. I will be waiting for EFT update.
    
    Best regards,
    
    Marc.
83.5more MIR questionsATPS::RAMANAshok Raman, 381-0007, ZKO3-3/Z34Fri Aug 31 1990 20:4812
    I have been looking into using the MIR and have a few fundamental
    questions - 
    
      -	Does it make sense to create a repository in an AM ?
    
      - Where would one create it ? For 10.12 SRM examples, wouldn't
    repeated executions return 'Repository failed-to-create--already-exists'
    kind of message.
    
    Thanks for the help,
    Ashok
    
83.6Create it wherever it makes senseTOOK::GUERTINWherever you go, there you are.Fri Sep 07 1990 19:1539
    AM's often need attributes, entity instances, etc, to be network-wide. 
    If this is the case, and they cannot directly support it, they need to
    use the mcc_dns routines.  If the information is system-wide (or
    cluster-wide if they are in a cluster environment and define the
    location of the repository as the common disk) then they can use the
    MIR routines.  MIR repositories are generally defined once for the
    lifetime of the product.  The caller defines a unique repository name
    and calls mcc_mir_create_repository() which in turn computes a unique
    number (unique per system) called the repository-id.  The number is
    used as an "index" by the MIR routines to identify the repository. 
    Repository names are (more or less) permanent and get stored in the
    MCC_MIR_DIRECTORY.DAT file.  Repository locations also get saved across
    MCC image activations and are stored in the MCC_MIR_ATTRIBUTE.DAT file. 
    After you have created a repository, all that is needed is to do a
    mcc_mir_get_repository_id() which translates the unique name into the
    repository-id.
    
    One algorithm commonly used is:
    
      stat = mcc_mir_get_repository_id( ... );
      if (stat == MCC_S_NOREPOSEXIST)
          stat = mcc_mir_create_repository( ... );
    
    or something like that.
    
    Also, I believe that the mcc_mir_create_repository() when it fails with
    MCC_S_REPOSEXIST ALWAYS updates and returns the repository-id of the
    repository name which it found.  This is because it does a
    mcc_mir_get_repository_id() call to check for existence before trying
    to create it.  So you should be able to just do...
    
     stat = mcc_mir_create_repository( ... )
     if ((stat == MCC_S_NORMAL) || (stat == MCC_S_REPOSEXIST))
        /* do normal processing */
    
    But I'll need to check on the latter.
    
    -Matt.