Conference azur::mcc

    It all depends on the data model of the stuff you're storing.
    
    The MIR is a fake entity-oriented database layered on top of flat
    files.   It also provides time-based storage and retrieval semantics
    for entity instances that come and go or attributes whose values need
    to be stored over time.
    
    If your storage needs are entity instance based (i.e. the instance is
    the 'key' to the data) and your entity hierarchy is non-trivial, you
    will find it considerable work to map this to a flat or relational data
    model and will probably find the MIR to be a better deal.
    
    A counter example would be a case where your data is keyed by the value
    of a characteristic or reference attribute and not by an instance
    identifier.  For example, if you have a reference attribute which is
    the building in which the entity is located, and you wish to keep
    additional data about the building, then this is a private data
    application.  (Now of course you could make the buildings into entities
    at which point you might go back to using the MIR).  Get it?
    
    The other obvious reason for using private data is for communication
    with native database applications outside of MCC.
    about the building

    
    I have a question related to the implementation of the MCC$MIR... 
    callable interface routines for accessing MIR database from a
    program, as described in the DECmcc SRM.
    
    Have these routines already been implemented?  If not, what's 
    the schedule?
    
    Muhammad

    Jim, in .1 described the MIR very accurately (I couldn't have done a
    better job myself).  Yes, the routines are implemented.  However, the
    Instance and Attribute repositories are not distributed, that is to say
    the repositories are on a per cluster (or node) basis.  This means that
    AMs, if they use the current MCC$MIR_ routines, can not have MCC manage
    the storage and retrieval of network-wide identifiers on their behalf. 
    AMs therefore generally find the MIR routines of little use for
    storage/retrieval of their "orphaned" attributes.
    
    We are using DNS to store and retrieve network-wide attributes (include
    identifier attributes) for our own MMs.  However, this has some
    disadvantages as well, in particular, the information is
    non-historical.  This is fine for AMs, but may cause problems for FMs
    which can deal with historical data.  We are currently looking at the
    best way to incorporate the MCC DNS routines into the SRM and possibly
    into the existing MIR routines.
    
    So the question really is, "What kind of Entity data are you
    storing?"  If the answer is that you are storing entity data for
    entities which are on a per cluster/node basis, then perhaps the
    existing MIR routines are right for you.  If the entities are global
    (network-wide), then the existing MIR routines are probably the wrong 
    solution.
    
    RE:.0
    Note that according to the SRM you can store you own Entity information
    in whatever form you wish.  You can use Global Sections (on VAXes), or
    RMS files, or even static structures.   It's up to you, but, you MUST
    follow the Good Neighbor rules.  For example, you cannot "block" the CPU
    by executing code which causes MCC to wait for I/O.  The primary reason
    we did not use Rdb is because whenever Rdb is called, it waits for I/O
    (as opposed to RMS, which can be called asynchoronously).
    
    -Matt.
    

    
    RE: .-1
    
    Matt,
    
    DECtrade uses DNS to store network-wide attributes, which are
    shared by all the nodes in a non-clustered environment.  I was
    hoping that by switching to MIR routines, MCC would worry about
    storage and retrieval of these attributes rather than DECtrade.
    
    From what you said in .-1, it appears that unless MIR becomes 
    distributed, it is of limited use in such an environment.  How 
    close are you in incorporating DNS routines into MCC?  Will the 
    implementation be in the form as framework routines, similar to 
    what you have done for VMS $QIO and RMS services?
    
    Muhammad
    
    

    there are already mcc$dns routines. Depending upon what you are
    trying to do they might be useful. Kathy Jo Nelson (took::nelson)
    should be able to help you understand what is available.