DataMuseum.dk

Presents historical artifacts from the history of:

Rational R1000/400

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about Rational R1000/400

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - download

⟦0ce489bb7⟧ TextFile

    Length: 1850 (0x73a)
    Types: TextFile
    Notes: R1k Text-file segment

Derivation

└─⟦8527c1e9b⟧ Bits:30000544 8mm tape, Rational 1000, Arrival backup of disks in PAM's R1000
    └─ ⟦5a81ac88f⟧ »Space Info Vol 1« 
        └─⟦11c89d1fe⟧ 
            └─⟦this⟧ 

TextFile

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.