Conference azur::mcc

    Bryan,
    
    See one of my previous notes...  MCC *does* in fact support V6.1;
    however, there are a couple of gotchas...  First of all, you will need
     to preserve the CMA libraries *before* you upgrade... Copy them to a
    subdirectory, ie:  COPY/LOG SYS$LIBRARY:CMA$* new_disk:[new_dir]; if
    you've already upgraded from V5.5-2  to V6.0, you've probably done
    this...  so hold on to them;  Secondly, you have to live with a stack
    dump everytime you type, MAN/ENT...  It works fine, but it points to
    what it thinks in an incompatible CMA library.  MAN/ENT/INT=DECW works
    fine, without a hitch...
    
    I haven't dug into it much, just upgrade a week or so ago, however, I
    suspect it has something to do with a pointer to the dictionary or one
    of those foolish META files...smile.
    
    Someone asked me to put pressure on the CSC to get a patch out... pls.
    feel free to take the initiative...smile.
    
    /Mic
    
    PS, Once you've upgraded to V6.1 do you plan to go to 2gb of Memory???
    (smile)
    

    Mic,
    
    We will be hapy to get a patch together when we are given one that has
    gone through the patch process.  We have received some images that were
    as a result of a CLD,.. but they have glitches as well when it comes to
    compiling mibs.  I would suggest escalting this through engineering,
    and just maybe we will get usable images in a dec standard format.
    
    meg

    So,  With some work, DECmcc will run on V6.1, but that is not exactly
    what I was getting at. When Netview was announced on OSF/1, We (DEC)
    said we would support MCC on V6.1 of VMS.  Have we announced that we
    now support MCC on V6.1 and is it in the SPD?
    
    Regards,
    Bryan
      

To my knowledge, the SPD has not been changed since release.

    This note and 6083 both discuss problems with MCC, VMS 6.1 and the CMA
    libraries.  What exactly is the issue with the libraries?  The notes
    discuss a workaround but don't mention the source of the problem.
    
    I've got a customer who just upgraded his cluster to 6.1, didn't do
    anything in particular with the libraries or logicals and things seem
    to run OK.  He is wanting to upgrade another cluster and wonders if he
    should worry about the CMA problem
    
    Any information would be appreciated.
    
    Regards, Gary

    	The CMA library is a shareable image with a transfer vector.
    
    	The purpose of the transfer vector is to ensure that an old image
    linked against the shareable image will still run, even though the
    routine sizes and offsets in the shareable image have changed. This
    provides a guarantee of upward compatibility. Upward compatibility also
    requires that for any particular routine the type, number and order of
    arguments remain the same. The only changes that can be made in 
    such a shareable image are bug fixes or optimisations of the code in 
    existing routines, adding additional optional arguments to existing 
    routines, and adding new routines.
    
    	MCC was built with a field test BL10 of the CMA library. Field test
    versions guarantee nothing about upward compatibility, but a released
    version of CMA didn't exist at the time.
    
    	We are looking at providing a new version of MCC which will use a
    released version of CMA. A version of MCC linked against a released
    version of CMA will run "for ever". The current version of MCC linked
    against BL10 of CMA might work most of the time with a released version
    of CMA, but nothing can be guaranteed.

    Thanks for the information in .6 - it helps.  
    
    I'd like to follow-up with a question;  what kinds of things will a
    customer see when they bump into the CMA problem or what sequences of
    events will lead to the problem presenting itself.  
    
    Unfortunately, when implementing the work arounds that have been 
    identified in the notes files and from the CSC, the MIB compiler
    breaks.    
    
    Thanks, Gary