Museet / Regnecentralen / RC4000 / Meteorologisk Institut
En beretning
Jørgen Heesche har postet følgende på en af SSLUG's mailinglister:
I anledning af at DDHF (http://www.datamuseum.dk/) inviterer til
foredragsaften om dansk computerhistorie har jeg fået lyst til at
fortælle lidt om RC4000 på Danmarks Meteorologiske Institut (DMI).
RC4000 blev i 1960'erne udviklet på RegneCentralen. RC4000 var en
multiprogrammerings-maskine, som kunne køre parallelle processer.
Operativsystemet var bygget op om en kerne kaldet monitoren, som
indeholdt procedurer til multiprogrammering, håndtering af ydre
enheder osv.
Monitoren havde også et effektivt message-system, således at de
parallelle processer kunne "tale med hinanden" ved hjælp af procedurer
som 'send message', 'wait answer' og 'wait event'.
DMI installerede en RC4000 i 1970 med det formål at automatisere
det manuelle arbejde i vejrtjenesten. DMI var (og er stadig) koblet på
et verdensomspændende netværk til distribution af meteorologiske
bulletiner. Dengang var nettet et fjernskrivernet, og DMI havde fast
opkoblede linier til Tyskland, England og Sverige, samt faste linier til
danske flyvepladser.
Meteorologiske observationer foretages hver 3. time
samtidigt over hele verden. 8 gange i døgnet tikkede fjernskriverne
således i ca. halvanden til to timer, og producerede lange baner papir
med bulletiner. Når en bulletin var slut, blev den straks revet af
fjernskriveren og bragt hen til en indprikker, som prikkede (plottede)
observationerne ind på store kort. Observationerne var skrevet i en
simpel talkode, som en indprikker efter kort tids indøvning nemt kunne
læse (dekode) og indprikke med specialtegn for vejrfænomenerne.
RC4000 var med sit multiprogrammeringssystem meget velegnet til denne
opgave. Fjernskriverlinierne blev forbundet til kanaler i en
telemultiplexer. Herfra "strømmede" data ind i systemet via såkaldte
datastrømme, som blev administreret af en process, datastrømmonitoren,
som adviserede dekoderprocessen om nye data i en given datastrøm. Efter
dekodning blev data sendt ad andre datastrømme til plotteprocessen og
databasen. Databasen ville man nok ikke i dag kalde en database, men
datasøgningen var dog rimelig hurtig, idet filerne var
indeks-sekventielle med hash-keys.
Denne databehandling skete 'real time'; de meteorologiske data
kunne ses på plotteren i samme øjeblik de indløb fra en fjernskriverlinie.
Plotteren (eller plotterne, der var 2) var noget af et særsyn, de hed
Kingmatic og kom fra Kongsberg våbenbrik i Norge, hvor sådanne plottere
anvendtes i et CAD/CAM system til skibsbygning. Dette system er
beskrevet in pdf-fil her:
http://heim.ifi.uio.no/~trygver/2003/HiNC/hinc-18final.pdf
Denne beskrivelse er selfølgelig ikke interessant i meteorologisk
sammenhæng, men set computerhistorisk viser den, at Norge også var godt
med for 50 år siden. Kingmatic plotteren omtales således:
Kongsberg Våpenfabrikk later marketed ESSI for the control of flame
cutters and other machine tools as well as the "Kingmatic", a very large
and highly accurate flatbed plotter for shipbuilding and many other
industries.
Og det var sandelig en meget stor plotter. På
http://www.kongsberg.kommune.no/kultur/gater/data/startside_hendelser.htm
kan man læse flg.:
1968 KV leverer verden største tegnemaskin, Kingmatic, med tegneareal
2600x3700 mm.
Så store var DMI's plottere nu ikke. Jeg kender ikke målene, men ved at
dele disse tal med 2, rammer man sikkert nogenlunde rigtigt, og det er
da også en anselig størrelse.
På langsiderne var der en høj afskærmning, og på tværs af bordet var
der en stor bjælke som kunne køre hen over bordpladen drevet af tandhjul
og store tandstænger skjult af afskærmningen. Penholderen kørte langs
bjælken. På den måde kunne pennen bevæges i alle retninger i et
retvinklet koordinatsystem. Bordpladen var en glasplade med mange fine
huller; kortblanketten kunne således holdes på plads ved suget fra en
Nilfisk støvsuger. Plotteren havde 4 meget kraftige ben, og var i det
hele taget noget af en sværvægter.
Plotteren tegnede som ovenfor nævnt meget nøjagtigt, men på grund af det
svære gods skulle den benyttes lidt varsomt: retningsændringer på over
45 grader var forbudt. Vi designede selv de meteorologiske tegn på
ternet papir og kunne nemt undgå de skarpe vinkler ved at skære
hjørnerne af med ekstra plotterstep.
Et udsnit af et vejrkort kan ses på
http://www.datamuseum.dk/site_dk/rc/NIB/kap11.shtml
Programmerne til behandling af de meteorologiske data blev kodet i
maskinkode med assembleren SLANG (Symbolic Language). Man kunne godt
have brugt Algol, men da programmerne var resistente i memory, og der
ikke var noget swap-system, gjaldt det om at spare plads:
ferritkerne-lageret var kun 2 gange 64 K ord (et ord = 24 bit).
En artikel på DDHF fortæller at DMI anvendte RC4000 som 'talknuser';
det er forsåvidt rigtigt: der kørte en lille simpel numerisk prognose,
som dog ikke kan stå mål med, hvad man mange år senere kunne opnå med en
Univac 1100: en vektor-processor med 16 CPU'er.
RC4000-systemet var som nævnt et 'Multiprogramming System' med en kerne
og et operativsystem som en skal uden på, dvs. baseret på det samme
grundprincip som UNIX, der blev udviklet kort tid senere. RC4000 blev
bootet ved at lægge en hulstrimmel i strimmellæseren RC2000. Den første
instruktion på strimmelen var 'Autoload Word', og så tog, om man så må
sige, det ene ord det andet, og RC4000 var i gang. Operativsystemet
's' meldte sig på konsollen (en ombygget elektrisk skrivemaskine),
og blev straks med en replace-kommando udskiftet med systemet 'm', som
var specielt udviklet til DMI. Der var nu oprettet en process, som
fyldte hele core storage (memory), bortset fra den del monitoren optog.
En process i RC4000 var en sammenhængende fast del af memory. I en
process kunne man afvikle programmer, men hvis processen var et
operativsystem kunne der også oprettes en ny process i en del af dens
memory-område; på den måde kunne man have processer i et hierarki:
Parent process --> Child processer osv. Ved opstart af 'm' blev der
oprettet to andre processer, 'x' og 'z', som også var operativsystemer,
og hvortil der var adgang fra to andre konsoller. 'z' blev brugt af
meteorologen i vejrtjenesten. Andre brugere skiftedes til at bruge 'x'.
Disse processer var interne processer. De ydre enheder: baggrundslager,
båndstationer, printer osv. havde man adgang til gennem externe
processer. Til alle processer var der process-beskrivelser i monitoren.
Ved x-konsollen kunne en bruger oprette en process af en vis størrelse.
Jeg kan ikke lige huske kommandoen, men der skulle angives en størrelse
f.eks. 'size 10' (10 K ord). I denne process blev file-processoren,
FP, loadet. FP svarede til en shell i UNIX, dog ikke helt så avanceret.
Man kunne f.eks. taste
r = algol
begin
< noget algol kode>
end
Algol-programmet blev nu compileret til noten r, og kunne, hvis
compileringen gik godt, startes blot ved at taste
r
Det var selvfølgelig ikke smart at gøre som ovenfor, kildeteksten blev
ikke bevaret. Det var bedre (på en Flexowriter) at hulle en strimmel med
det hele på. På en sådan jobstrimmel kunne man udnytte FP's
test-faciliteter. F. eks.:
r = algol
< kildetekst >
if OK
r
Programmet r blev kun startet, hvis OK var sand. OK var en default
variabel i FP.
Et nyt algolprogram var selvfølgelig ikke fejlfri fra starten og skulle
derfor editeres. Det skete med editoren 'edit'. Det kunne man gøre
sådan, hvis kildeteksten var indlæst til noten r:
s = edit r
< edit-kommandoer>
if OK
(
t = algol s
if OK
t
)
Jeg kan ikke huske, hvordan kildeteksten blev indlæst til noten r, men
måske kunne det gøres med 'edit'.
Bemærk at jeg hele tiden taler om noter, En note var en temporær fil,
som forsvandt når en process blev nedlagt. Disklager (pladelager) var
også en begrænset resource, den samlede størrelse var 18 M ord. Når en
algol-tekst var editeret, blev der hullet en ny hulstrimmel.
Som tidligere nævnt havde RC4000 ikke et swap-system, et program skulle derfor loades i sin helhed. Men det var kun gældende for assembler(slang)-programmer, algolprogrammer kunne loades delvist. Et algolprogram var segmenteret med en segmentstørelse svarende til et segment (en blok) på baggrundslageret. Det var således nok, at der var plads i memory til nogle få segmenter. Hvis der under programafviklingen blev brug for koden i et segment, der ikke var loadet, blev dette blot indlæst til memory og et af de brugte segmenter blev overskrevet. Denne segmentudskiftning blev styret af et running-system, som var fast loadet når programmet kørte.
På http://www.datamuseum.dk/ er der mange gode artikler om RC4000. Jeg kan anbefale flg.:
|
