Conference azur::mcc

    The SRM does not, as you have astutely noticed, define the storage
    details for the MIR. This permits implementations to vary in their
    details.
    
    However, the reason for describing the four "categories" of data in
    the MIR was to allow for different implementations of each, taking into
    account their different requirements. DECmcc makes use of the different
    characteristics for each of the categories in the storage mechanisms
    chosen.
    
    For the class data, this needs to be ubiquitous (ie. available
    everywhere) and is used a lot by many management modules, so the access
    requirements dictate rapid access. Hence we chose to replicate the
    class data on every system running DECmcc, and store it in a series
    of closely linked files (for example, one contains the dictionary
    meta-data, and another the dictionary data itself). On VMS, these are
    stored in RMS files.
    
    For the instance data, this needs to be defined across the network,
    changed infrequently (typically when new systems or devices are added to
    the network) but available universally. We chose to use DECdns as the
    storage mechanism for DECmcc's instance data.
    
    For the historical data, this is (currently) defined as being stored
    on a per-domain basis. Hence, in VMS RMS flat files are employed for
    the historical data; however, on Ultrix, SQL access will be used.
    Obviously, the historian's export function will put the data in Rdb.
    [Also, as the historical data is structured according to the Entity
    Model it is a prime candidate for using an object oriented database
    in the future. In addition, we might consider deploying an appropriate
    distributed database technology - currently you need to be on the
    same system where the domain's data is stored to get at the historical
    data.]
    
    For the miscellaneous data, that is clearly defined according to the
    specific needs of the module that needs it.  Currently, standard
    files (such as RMS on VMS) seem to be commonly used.
    
    
    So.....when you ask "is it possible to distribute the MIR", there is no
    simple answer. The MIR is really a conceptual repository, as opposed to
    a single database - each of it's components is subject to different
    storage/access requirements, and is hence implemented differently.
    We already, in DECmcc v1.0, support distributed data in the sense that
    we use DECdns.  In future versions, you should expect that we will
    "get better" features that address distributed data in DECmcc.
    
    Colin

    The MCC/Ultrix historical data MIR uses Ultrix/SQL which can be
    distributed.  In fact, multiple hosts can all share a single database
    if desired.

re .1

I'm confused:  I thought the goal of MCC was to allow us to write portable code.
How can we write portable code if the MCC is implemented differently on each
platform?

We need to support the following platforms:  alpha, VAX/VMS, ULTRIX/VAX, OSF,
UTRLIX/MIPS.

I need to understand the following in a portable manor:

  (1)  How to implement indexed (ISAM files).  Do we need to write our
       own B-trees using fseek()?

  (2)  How to implement concurency control?  Do we need to do this too
       using locks?

  (3)  How to store objects in the MIR.  I understand how to store
       relations (in the relational database sense) or records (in the
       context of a hierarchical database) but I don't understand
       how to store objects that include methods.

Where can I find documentation on the implementation of the MIR on the
above platforms?

                       Sieg

    I will leave most of this to Jim Swist, but what you should know
    is that the mcc ultrix platform (not currently available outside the
    development group) will have the same set of MIR routines, with
    the difference in their implementation hidden from the user of the
    routines. Under ultrix we are using ingris (sp?). As to locks you are
    not the first to ask for them. There is currently a proposal for an
    ECO being written that will make the locking routines within the kernel
    available as callable routines.
    
    hope this helps
    Jim can you add more?
    

    RE:.3
    
    We're veering off the subject of this note a bit, but the answer to
    most of your questions is to use the mcc_mir_... routines (read the
    SRM).  
    
    The MIR actually consists of three separate interfaces.  It is an
    architectural concept which encompasses all stored data that MCC knows
    about.  The three interfaces are the Dictionary routines, which define
    Class data, the MCC DNS routines which define network-wide Instance
    (and some attribute) data, and the mcc_mir_... routines which currently
    only define local data, and historical attribute data (and some
    instance data).
    
    These routines are intended to make the data storage mechanism / IO
    subsystem platform independent -- ie. hidden from the caller.  They are
    more restrictive than a relational database, because you cannot declare
    transactions, commits, rollbacks explicitly.  And they are NOT a true
    object-oriented database (no inheritance, for example).  If your data
    storage requirements are simple, then chances are you can use the
    mcc_mir_... routines, if they are complex, you may need to write your
    own routines.  Writing your own routines is an acceptable solution if
    you have complex data storage requirements.  But as you mentioned, you
    have to make sure that YOU implement thread synchronization, and ASTs
    are a no-no, which can be tough when trying to use software which does
    IO (typically locks and semaphores are used).  I believe all this is
    discussed in the SRM.
    
    I believe we plan to support all of the platforms you have mentioned.
    
    What it boils down to is this: The MIR may be implemented differently
    on different platforms, but the interface into the routines are
    platform independent.  If this does not make sense to you, you should
    discuss this with the CMA folks.  Maybe they can explain it better than
    I can.
    
    -Matt.