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 |
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.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
2569.1 | It couldn't be avoided | TOOK::GUERTIN | Menagerie Control Center | Mon Mar 16 1992 13:12 | 11 |
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.2 | Not always a big change | TOOK::MINTZ | Erik Mintz, DECmcc Development, dtn 226-5033 | Mon Mar 16 1992 14:01 | 12 |
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 |