Conference azur::mcc

1939.0. "Changes for developers in V1.2" by FOUR62::LICAUSE (Al Licause (338-5661)) Fri Dec 13 1991 09:18

Recently Doug McPherson sent out a memo indicating that the TRANSLAN_AM
will not work with T1.2.  I asked several questions regarding these changes
and expressed concerns if such changes would have to be made with each new
release of DECmcc.

It appears that these changes that needed to be made to the TRANSLAN_AM
and any other AM's would be a one time only deal, for the most part.
But the response was very good and worth posting:


================================================================================
From:	SAMUIL::MCPHERSON "Scientific progress goes 'Boink!'  12-Dec-1991 0835" 12-DEC-1991 09:10:12.77
To:	DUCAT2::LICAUSE
CC:	MCPHERSON
Subj:	RE: I: Reminder:  Translan AM V1.0 will NOT work with DECmcc V1.2.

Al, 

The changes that will be required for 1.1 modules to go to 1.2 should be
pretty a much 'one-shot' deal.   There were massive internal restructurings
that the MCC Kernel *had* to go through to get to 1.2. 
The MCC kernel had to go through substantial internal changes for several
reaons:
	- it was ported to RISC/Ultrix 
	- the internal threads package had to be changed to use the CMA threads
	  package (one of our contributions to OSF/DCE). 
	- some kernel routines (e.g. mcc_ea routines) had to be fixed to be
	  SRM-compliant

Since we've take then hit for all of this in this release, I wouldn't expect
that there be much more required in the way of MM changes in future releases.  
However, in the interest of fairness: MCC is very analogous to a "managenent
operating system", so please don't expect any more from DECmcc than you would
from an Operating System (e.g. VMS) in the area of code changes in subsequesnt
releases.

MCC was initially designed and developed to run on VAX-VMS, so the porting
process to RISC/Ultrix was painful. However by now, most of the RISC/Ultrix
port has even been "back-ported" to VMS, with some improvements in efficiency.  
Also, the exercise has meant that some pieces of the platform had to be changed
to support existece on multiple platforms more readily.   

The OSF threads package that we used for 1.2 behaves differently from the
original threads pakage in that it allows thread pre-emption (something not
allowed in previous versions.  This means that MM code that is using threads
must apply locks (mutexes) around data structures and other routines to make
certain that if they do get pre-empted, data remains intact.   So, if a MM
developer decided NOT to make changes in that area, their code would work
'somewhat', but it certainly wouldn't be very reliable.

Inevitably, these changes will mean some changes must be applied to the
Management modules, but believe it or not: great pains were taken to minimize
the impact on MM developers (i.e. 'it could be much worse').   So the extent
to which MM developers will need to change their code for the 1.2 environment
will depend on the extent to which they 1) use threads, 2) use mcc_ea routines.  
The changes could probably be as simple as adding in a few #ifdef's to
accomodate the MM working in either 1.2 or 1.1 environment.

For more info on this, read the NOTED::MCC conference.  There's a discussion
going on now about this topic.

regards, 
/doug