[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

2699.0. "Maintaining 2 different dictionaries simultanesouls" by MICROW::LANG () Mon Apr 06 1992 17:01

    
    	Our product has the requirement of maintaining 2 versions
    	of the product on the same system simultaneously.  This will
    	cause a problem if the dictionaries are different between 
    	the 2 versions.  Is there a recommended way for handing
    	this?
    
    	I thought we could copy the dictionary and parse files
    	to a separate directory, as described in creating a DECmcc's
    	developor's dictionary, but I think that would cause problems
    	for other MM's which aren't defined by the environment
    	variable MCC_SYS_LOCATION.
    
    		thanks
    				Bonnie
T.RTitleUserPersonal
Name
DateLines
2699.1MCC_SYS_LOCATION is OK, but watch for other problemsTOOK::MINTZErik Mintz, DECmcc Development, dtn 226-5033Mon Apr 06 1992 17:3122
>    	Our product has the requirement of maintaining 2 versions
>    	of the product on the same system simultaneously.  This will
>    	cause a problem if the dictionaries are different between 
>    	the 2 versions.  Is there a recommended way for handing
>    	this?

If you are talking about field test versions, this is not recommended
at all.  Depending on which version, you may have event pool incompatabilities
and private MIR problems in addition to dictionary problems.
    
>    	I thought we could copy the dictionary and parse files
>    	to a separate directory, as described in creating a DECmcc's
>    	developor's dictionary, but I think that would cause problems
>    	for other MM's which aren't defined by the environment
>    	variable MCC_SYS_LOCATION.

This is exactly what MCC_SYS_LOCATION is for.  As long as MCC_SYS_LOCATION
is defined by everyone invoking a PM, it will be inherited by each
MM process created from that PM process.

-- Erik

2699.2more clarificationMICROW::LANGMon Apr 06 1992 19:5431
    >       Our product has the requirement of maintaining 2 versions
    >       of the product on the same system simultaneously.

                The product ACMS for UNIX product (or whatever it
                is called when released) needs to support multiple
                versions of the ACMS for UNIX product. (Both on UNIX
                and VMS.)  So, our customer could have ACMS for UNIX 1.0
                and ACMS for UNIX 1.1 installed on the same system, and
                require to be able to run them both without dependencies
		or interference

		So... could we take our .com files, help files, script
		files and instead of putting them in /usr/mcc/mcc_system,
		as described in the development guide, put them in 
		another directory like /usr/pdir/acms_010/mcc_system.
		Then mv all the dictionary and parse files over there?
		We would still put the exe in /usr/mcc/mmexe.
		If our customer wanted to use 2 different AM's, one
		being the ACMS for UNIX and some other that has the
		information defined in /usr/mcc/mcc_system, wouldn't
		there be a problem?  (That second AM wouldn't find its
		data?)

		For VMS would we redefine the logical MCC_SYSTEMM to
		be a search path including the default directory and
		the ACMS for UNIX directory?

			thanks,

				Bonnie
2699.3you can mix and match MMs not kernelsTOOK::CALLANDERMCC = My Constant CompanionMon Apr 27 1992 22:568
    it sounds like you want one version of mcc running but multiple
    versions of your MM (meaning a need for multiple versions of the common
    dictionary files). IF you are running with the same mcc kernel (base
    system version) then you shouldn't have incompatibilities with the
    event manager and other system services, but if you want differing
    versions of MCC then you will have problems regardless of what you do
    with your logicals (environment variables).