[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

2569.0. "backwards compatibility????" by COL01::LUNT () Mon Mar 16 1992 11:13

Hello,

	Recenlty our customer asked us why old access modules do
not work with the latest DECmcc Kernel. Example: We upgraded from
V1.1 to T1.2.4 and the Translan module no longer works. Example: there
is a new Base system, T1.2.5, but with this version the ELM AM and
TSAM that work with T1.2.4 do not work with it. And what is with
self-written access modules. Must they be rewritten to work with
every new DECmcc Kernel? Also, one cannot upgrade to the latest
DECmcc Kernel to gain the benefits, because we loose the access module
functionality(ELM for example).

	Is there a reason why the DECmcc architecture is not
backwards compatible? Is this a trend that is expected to continue?
I cannot understand how to successfully sell this product, when each
time a new DECmcc Kernel is announced and all the access modules
have to be rewritten. This philosphy does not correspond with the
normal Digital Philosophy that software be backwards compatible in
order to protect customer investments. 

best regards,

Julie Ann
T.RTitleUserPersonal
Name
DateLines
2569.1It couldn't be avoidedTOOK::GUERTINMenagerie Control CenterMon Mar 16 1992 13:1211
    In general, DECmcc allows MMs to run on next minor releases.  For V1.2,
    however, there were mandatory changes to the code (such as the use of
    DECthreads), which caused backward compatibility problems. 
    
    So, DECmcc V1.2 being incompatible with previously written MMs is an
    exception to the rule.  We don't expect it to happen again (but can't
    guarantee it).
    
    From an engineering trade-off viewpoint it is the better of two evils.
    
    -Matt.
2569.2Not always a big changeTOOK::MINTZErik Mintz, DECmcc Development, dtn 226-5033Mon Mar 16 1992 14:0112
Also note that for many modules, the V1.1 -> V1.2 change is a re-compile
and re-link without major code changes.  Users of thread services are,
unfortunately, required to make some code changes due to a change
in the underlying threads package.

As to the recent incompatabilities between baselevels, some of the
internal groups are using undocumented interfaces, which they require
for tighter integration.  Those are subject to change because they
are currently under development.

-- Erik