Conference azur::mcc

4231.0. "MCC support for multiple versions of an AM" by ENABLE::glantz (Mike @TAY 227-4299 TP Eng Littleton) Thu Dec 10 1992 13:17

I'm posting this info for the record, so that others who are trying to
do this can see one way it's been done.

One of the requirements for our product is that the user be able to run
multiple versions on the same system at the same time (in different
processes). One of the components of our product is a DECmcc access
module (and its associated entities and help).

The mechanism which we've adopted (and which has been tested reviewed
with one of the MCC devos) is this:

We create a directory tree specific to each version of our product
(let's call this SYS$COMMON:[XYZ010] for versions 1.0 of our product).
In each of these trees, we create a [.MCC] subdirectory, which will
contain all of the version-specific MCC databases.

We copy the dictionary database files (MCC_FDICTIONARY.BPT,
MCC_FDICTIONARY.DAT), the dispatch table (MCC_DISPATCH_TABLE.DAT), and
the help sources (MCC_*.HELP) from MCC_COMMON to this directory. We
also copy the help libraries (MCC_CHARACTER_CELL_HELP.HLB,
MCC_DECWINDOWS_HELP.HLB) from SYS$HELP to this directory. We copy our
own help sources to this directory.

We define/process MCC_SYSTEM to be
MCC_SPECIFIC,SYS$COMMON:[XYZ010.MCC],MCC_COMMON.

We $ manage/tool/dict to load our stuff into the dictionary (MCC_SYSTEM
provides the pointer to our local copies of the databases).

We $ manage/ent to enroll our AM (ditto).

We $ manage/tool/help to merge our help (we set default to our local
directory to do this).

Now, all of this works fine, but it has a couple of problems. The most
serious problem is that if any other layered product gets installed at
some later time into the normal MCC areas (in MCC_COMMON), it will not
be seen by anyone who has pointed MCC_SYSTEM at our product's local
copies of the MCC databases. We would need to reinstall our product (as
described above). What makes this especially tricky is that the
documents describing this come with *our* product, and would not
necessarily be read or remembered at the time the other product is
being installed, which is when the problem would occur.

The second problem is sort of a nit: while we can *merge* our help
files into the help libraries without having to redefine SYS$HELP, a
user needs to redefine SYS$HELP to
SYS$COMMON:[XYZ010.MCC],SYS$SYSROOT:[SYSHLP] in order to *access* these
help files.

In general, it would be useful to us (and other products with this
requirement) if MCC provided explicit support for multiple versions of
a given product. This support would be to solve the problems described
in the previous two paragraphs (we'll be submitting product
requirements to this effect).