|
|
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 - metrics - 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.