|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - download
Length: 1850 (0x73a) Types: TextFile Notes: R1k Text-file segment
└─⟦8527c1e9b⟧ Bits:30000544 8mm tape, Rational 1000, Arrival backup of disks in PAM's R1000 └─ ⟦5a81ac88f⟧ »Space Info Vol 1« └─⟦11c89d1fe⟧ └─⟦this⟧
Runtime compatibility is NOT supported directly in D1. If the spec and load view are not spec-load compatible, the application will not load even if the client does not call the incompatible declaration. Is is possible to disable compatibility checking entirely, allowing a run-time compatible subsystem to load and execute. If the subsystem is spec-load incompatible, one will likely get the exception Operand_Class_Error as before. Comments from ANNE on the Exercises : --------------------------- 1. p 84 : using import/export restrictions : several "students" forgot to control the units ! A good idea would be to put a warning message in step 2 ("construct the subsystem-based mail application"). 2. p 139 : non-upward compatible changes. As you suggested on the phone, we had to give the spec-views as clients of the spec-view we just created, in the CMVC.IMPORT command. This was not obvious, since the import from the supplier view in the client view is not done explicitely (but via <inherit ipmorts> in the CMVC.MAKE_SPEC_VIEW command). It is really a pity,the user has to know about the referencers for a given view and even worse, about the order in which to give the client views , in the CMVC.IMPORT command. 3. p 279 : setting up primary and secondary subsystems : it should be mentionned somewhere that the model used to create a given subsystem has to exist on the target machine before transfering that subsystem. To the question " Does it make any difference how the subsystems are transferred ?" , my answer would be : NO if the tranfer is on ANOTHER MACHINE (in the same location, ie same pathname), because then you keep the same links to the units ; YES if you transfer in a world with a different name , then you would have to build again the application from bottom-up in the target world.