Computerhistorie: Control Data CYBER 74

Control Data CYBER 74

Begin 1978 werd het duidelijk dat de CDC 6400 dermate overbelast was, dat uitbreiding van de CPU-capaciteit, van de schijven en het geheugen moest plaatsvinden. Omruil van de CDC 6400 in een CDC CYBER 74 werd gepland. De grootste applicaties waren de tanksimulaties ter ondersteuning van de selectiebeslissing van Defensie voor nieuwe tanks en de ‘Wargame’-applicatie die alsmaar groeide.

De CYBER 74 hardware

De CDC CYBER 74 was een moderne versie van de Control Data 6600. Het systeem had een klokcyclus van 100 nanoseconden (10 Mhz), een ringkerngeheugen van 131 Kwoorden van 60 bits (geen parity) en tien (later 14) peripheral processors (1 msec major cycle). Het systeem werkte via de water- en luchtkoeling 63 KW per uur weg en had wekelijks drie uur preventief onderhoud nodig.
De computer was opgebouwd uit discrete componenten, naar schatting zo’n miljoen transistoren en drie miljoen weerstanden en condensatoren. Daarnaast 9 miljoen geheugenkernen en kilometers getwiste kabel.

Installatie van de CYBER 74: herinrichting van de elektriciteitsvoorzieningen
Installatie van de CYBER 74: herinrichting van de elektriciteitsvoorzieningen

 

Installatie van de CYBER 74; drie van de vier ‘bays’ zijn bedraad. De "kerstboom", een paal tussen de bays waaraan alle bedrading tussen de vier bays opgehangen werd, ontbreekt nog.
Installatie van de CYBER 74; drie van de vier ‘bays’ zijn bedraad. De “kerstboom”, een paal tussen de bays waaraan alle bedrading tussen de vier bays opgehangen werd, ontbreekt nog.

Voor de gebruikers waren een aantal beperkingen ingebouwd. Per interactieve processtap mocht maximaal tien seconden rekentijd verstookt worden. Batchjobs die langer dan 7.5 minuut CPU-tijd vergden werden alleen ‘s-nachts en in de weekeinden verwerkt. Daarbij mochten de batchjobs overdag niet meer geheugen vergen dan 140000B en ‘s-nachts 200000B woorden (369 KB resp. 429 KB). Interactief lag die grens bij 70000B woorden (215 KB).

Cyber74 - installatie van de Christmas tree
Cyber74 – installatie van de Christmas tree

Onvoorziene installatieproblemen

De installatie van de CYBER 74 in augustus 1978 vergde drie weken. Eerst werd de Control Data 6400 afgevoerd en werd de computerruimte uitgebreid met een kamer. Tijdens de ombouwperiode had het Laboratorium geen rekenfaciliteiten. Omdat iedere van de vier “poten” (bay’s) van het systeem zo’n 2000 kilo woog en na plaatsing ook nog eens extra zwaar zou worden door het koelwater, was vooraf bij de architect van het gebouw nagegaan of de constructie van het gebouw voldoende draagkracht zou hebben. Nu bleek dat geen probleem te zijn. Wel moesten speciale voorzorgen genomen worden om de systeemdelen tegen de schuine helling van de verhoogde vloer op te trekken: dikke balken tegen de buitenzijde van de gevel om de takels aan te bevestigen. Om het dagelijkse transport van de koffiekarren en dergelijke binnen het Laboratorium niet te verstoren was besloten om de delen op zondag via de lift naar boven te transporteren. Vooraf was nagegaan of het gewicht met de lift getransporteerd kon worden. Een ding was tijdens al die voorbereidingen vergeten, namelijk het bestellen van een liftmonteur die voor het zware transport een motorbeveiliging moest overbruggen. Om de delen toch naar boven te hijsen is de kabeltrommel van de lift middels handkracht vele malen rondgedraaid.

Omdat de nieuwe tapecontroller ook nieuwe ‘controlware’ nodig had, moest het zogenaamde coldstart controlwareprogramma ingelezen worden in de kaartlezer en middels een speciaal deadstartprogramma (met schakelaars gezet) naar de tapecontroller gestuurd worden. Probleem was dat dat TNO niet over een cardpunch beschikte en dat het coldstart controlwareprogramma alleen op magneetband aanwezig was. Een kip-ei probleem dus. Met veel kunst- en vogelwerk werd een coldstartdeck gefrabiceerd (“ABC”-programma) waarmee de CYBER ten slotte tot leven gewekt kon worden.

Radarinstraling

Naast de installatie van de CYBER 74 was besloten om alle apparatuur op een andere manier in de ruimte op te stellen. Onder andere werd een luchtcirculatiescheiding aangebracht tussen de “stoffige” print- en kaartleesruimte en ruimte met het console, magneetbandeenheden,  schijfeenheden, controllers en het mainframe. Het aantal schijfproblemen daalde daardoor spectaculair. Hardwareproblemen werden overigens dagelijks in de gaten gehouden middels een systeemrapportage (Cerfile; HPA).

De radargevoelige magneetbandeenheden en het CYBER 74 console. Daarachter de luchtkoeling die nog al eens lekte.
De radargevoelige magneetbandeenheden en het CYBER 74 console. Daarachter de luchtkoeling die nog al eens lekte.

In de eerste maand in de nieuwe ruimte hadden wij echter om de paar dagen te maken met een enorme hoeveelheid leesfouten op de magneetbandeenheden. Analyse toonde aan dat de problemen alleen optraden met magneetbanden van gebruikers. De backup-tapes die ‘s-avonds geschreven werden waren probleemloos. Het gekke was dat de problemen niet afkomstig waren van een specifieke magneetbandeenheid en dat vaker gebruikte magneetbanden tijdens een bepaalde verwerking slechts enkele, normale fouten vertoonden en de volgende keer enkele duizenden. Nog dieper spitten toonde aan dat de fouten – als ze optraden – dit met een frequentie van 0.1 Hz deden. De Bedrijfstechnische Stafafdeling ging het elektriciteitsnet na doch kon niets vinden. Ondertussen was het operatorconsole display-programma dusdanig gewijzigd dat tijdens magneetbandverwerking de gelogde fouten op het scherm verschenen.
Enkele weken lang trad het 10-seconden probleem niet op totdat op een vrijdagmiddag keurig iedere tien seconden een leesfout optrad. Binnen de kortste keren was het bedrijfsbureau gewaarschuwd en stonden er zeker tien mensen het fenomeen op het console te bekijken. Een tweede magneetbandeenheid werd gestart, nu werden er iedere tien seconden twee meldingen gelogd. Een van de aanwezigen keek naar buiten en ontdekte dat bij NAVO’s Shape Technical Centre (STC) een radar stond te draaien die een omwentelingssnelheid had van precies tien seconden. Een telefoontje naar STC om de radar uit te zetten resulteerde aldaar in een kwade researchmedewerker: zijn radar stoorde toch geen computers! Dit totdat hij zelf kon constateren dat de zijlus van zijn radar precies instraalde op de koppen van de recent gedraaid opgestelde magneetbandeenheden. Het aanbrengen van een stukje geaard kippengaas voor de ramen loste de problemen voorgoed op.

Overigens trad bij het LEOK na de verplaatsing van een radar eenzelfde euvel op. Volgens de eigen radardeskundigen reflecteerde een bomenrij de radarstraling naar de computerruimte. Na het verkrijgen van de kapvergunning werd een hele rij bomen gekapt. Helaas. De radarinstraling kwam bij nader inzien rechtstreeks door het dak heen! Ook hier hielp een simpele vorm van de kooi van Faraday om de computerstoringen uit de wereld te helpen.

Programmeren en de softwareomgeving

Naast Fortran’66 (FTN4), werd begin 1980 Fortran’77 (FTN5) op het Physisch Laboratorium TNO geïntroduceerd. Een nieuwe vertaler die soms betere optimalisaties vertoonde dan de oude. Het ging ook wel eens mis. Zo werd in een nieuwe release (“level”) gelijktijdig door de systeemroutine SINCOS de sinus- en de cosinus-waarde opgeleverd. Alleen werd door de slimme vertaler over het hoofd gezien dat sin(a(i)) een ander argument had dan cos(a(j)). Gevolg was een door het LEOK gesimuleerde luchtafweer met ‘torpedowerking’: de luchtafweerraketten gingen heel diep de grond in!
Het was ook de periode dat overgegaan werd van Pascal 2 naar Pascal 3. Pascal was oorspronkelijk door Niclaus Wirth ontwikkeld en geoptimaliseerd op een CDC 6400. Met enige achtergrondkennis werden door ons nieuwe opties aan de Pascal-vertaler toegevoegd. Omstreeks 1983 werd gepoogd op via een tussenstap (DIANA) een in Pascal geschreven ADA-vertaler aan de praat te krijgen. Forse ingrepen waren nodig om de vertaler aan te passen. Bij gebrek aan tijd werd dit project gestopt.

Schijven bleven volstromen. Dit ondanks de omruil in februari 1983 van drie CDC 844-41 schijfeenheden in twee CDC 885-schijfeenheden, waardoor een verdubbeling van schijfruimte plaats vond. Besloten werd oude files wekelijks van het systeem te verwijderen en op magneetband te archiveren. De gebruikers konden via een programma “het INDEX-systeem” aangeven of ze files wilden archiveren, opruimen of terugladen. De gearchiveerde informatie werd twee jaar gegarandeerd. Het INDEX-programma maakte daarbij gebruik van de net nieuwe Cyber Control Language-mogelijkheden (CCL; 1982). Cyber Control Language (CCL) was een – in UNIX-termen – soort shell-taal. Door het Physisch Laboratorium TNO werden vele extra mogelijkheden aan CCL toegevoegd om de operationele en gebruiker’s gereedschappen optimaal te kunnen gebruiken. Zaken als ‘lege’ parameters, niet af te drukken ‘security’ parameters zoals wachtwoorden en substrings werden toegevoegd. De meeste opties werden in 1980 ontwikkeld. Hiermee konden de CCL-procedures voor het Micro Development Station (MDS) gehalveerd worden qua lengte, waardoor ook nog een efficiëncywinst op de CYBER geboekt kon worden tijdens de expansie en verwerking van de CCL-procedures.

Manchester Trace Package: post-mortem dump

De Fortran-gebruikers werden door het systeem gewezen op een programmeerfout door foutmeldingen als CPU Error Modes 1, 2 of 4. Dit betekende dat een gebruiker respectievelijk buiten het programmageheugen liep, deelde door nul of een niet-bestaande instructie wilde uitvoeren. De enige manier om er achter te komen waar het probleem optrad was te kijken welke uitvoerregel als laatste geproduceerd was en in welk deel van het geheugen de fout optrad. Hierbij kon de octale dump helpen.
Gebruiksvriendelijkheid was wat anders. Reden om eens het public-domain (ook toen al) post-mortem dump analysepakket PMD genoemd van de Universiteit van Manchester aan te vragen. Nu was die Universiteit net overgeschakeld op de CYBER 205 supercomputer en was het pakket onder de naam MANTRAP en het onderhoud daarvan overgedragen aan de Universiteit van Leicester. Daar konden we het wel krijgen maar dan moesten wij zelf de aanpassingen verrichten om het onder NOS ontwikkelde pakket over te zetten naar NOS/BE. Met enige aanpassingen in de Fortran-vertaler en de Loader was dat mogelijk.
Toen wij het pakket net draaiende hadden, inclusief aanpassingen voor de veel door het Physisch Laboratorium gebruikte segmentatie-loader (SEGLOAD), kwam Control Data (CDC) uit met een nieuwe softwareversie (release). Daarin was als nieuwigheid “dynamic load” (DLL) van modulen opgenomen. Met name de Fortranbibliotheek was volledig dynamisch gemaakt (o.a. de I/O-modulen). Draaibaar maken van een pakket is relatief eenvoudig omdat daar weinig inhoudelijke kennis voor nodig is. Het aanbrengen van nieuwe zaken is echter minder eenvoudig omdat dat totale inzage in de programmastructuur vergt, zeker als de documentatie daarvan minimaal is.
Nadat het pakket ook de nieuwe dynamische routines kon herkennen in het geheugen, werd PMD in productie genomen. Dat had grote consequenties voor veel gebruikers omdat vanaf dat moment de loader zo ingesteld werd, dat het gebruik van (nog) niet geïnitialiseerde variabelen automatisch leidde tot het afbreken van het programma. Het had wel een sterke kwaliteitsverbetering en uiteindelijk minder vreemde uitkomsten tijdens de uitvoering van het programma tot gevolg.

Cyber security in 1976! 

In 1976 werd door de operating system werkgroep ECCOS van de Europese Control Data gebruikersvereniging (ECODU) besloten een beveiligingsstudie te verrichten. Het Physisch Laboratorium maakte daar deel van uit tezamen het RRZN (Hannover), LUCS (London), EPFL (Lausanne) en RUS (Stuttgart). Dit strookte met de geplande aanscherping van zowel de fysieke als de systeembeveiliging op het Laboratorium. In tien hoofdcategorieën werden zo’n 45 grote beveiligingsgaten, met name buffer overflows, in het NOS/BE systeem ontdekt waarvoor testprogrammatuur geschreven werd en oplossingen werden ontwikkeld.
De volgende fase was het uitbreiden van het standaard NOS/BE-systeem met extra beveiligingscode. Operators konden geen gevoelige delen van het geheugen meer op het console zien. Een striktere functiescheiding werd doorgevoerd. Alleen na het intypen van een wachtwoord kon het console vrijgegeven worden. Er werd een kleine, minder dan 100B grootte, PP-overlay geschreven die geheel relatief gecodeerd was zodat deze overal geladen en uitgevoerd kon worden. Dit programma werd opgeslagen als een systeempermanente file met door het systeem zelf, aan de hand van de microsecondeklok, berekende lees-, modify-, append- en write wachtwoorden. Ieder ‘rootfile’ systeemwachtwoord was daardoor anders en voor eenieder absoluut niet te achterhalen, ook niet door de systeemprogrammeurs. Het vervangen van systeemcode was alleen toegestaan indien men het speciale wachtwoord “Os0lem1o” (O-solemio) kende.
Slechts één PP-programma was in staat om de verwijzing naar de file met de beveiligingscode op te pakken, daarna kon het het permissiebit “leespermissie” in het systeemgeheugen aanzetten en vervolgens de “unlock-code”, een soort van pincode inlezen. Indien de overlay niet geladen was, dan kon het systeem geheel niet UNLOCKed worden. Hierdoor was het systeem optimaal beveiligd omdat de echte beveiligingscode op geen enkele andere manier uit te lezen was.

Nog een truc moest toegepast worden bij het testen van nieuwe beveiligingscode. Het was namelijk altijd erg lastig om wijzigingen te testen in een systeem dat optimaal (ook door de systeemprogrammeurs tegen zichzelf) beveiligd was en daardoor anders reageerde voor de ‘gevoelige’ jobs (confidentieel en geheim). Om nieuwe code te kunnen testen in een normale omgeving werd de beveiligingscode gewoon ontwikkeld en vertaald. Vervolgens werd de binaire “executable” code achter het console ingelezen in het geheugen met behulp van de door systeemprogrammering zelf sterk uitgebreide O26-console line editor (ook een PP-programma). Vervolgens werd op het andere consolescherm de octale geheugeninhoud zichtbaar gemaakt. Het was dan eenvoudig om de speciale beveiligingstesten te verschuiven door de geheugenwoorden – en daarmee de PP-code – te wijzigen. Daarna werd weer naar de O26-editor overgeschakeld en werd de gewijzigde code als tijdelijke testfile weggeschreven. Vervolgens werd de aangepaste PP-code met EDITLIB(SYSTEM) aan het systeem toegevoegd. Daarna kon de nieuwe beveiligingscode probleemloos uitgetest worden. Voldeed de code, dan werd de echte versie toegevoegd aan het systeem. Deze manier van werken bespaarde een extra vertaalslag die voor verschillende PP-programma’s wel eens meer dan een uur doorlooptijd kon vergen.

De O26 console editor had de volgende keyboard functies volgens een recent gevonden uitdraai.
Let wel, de PP van 4096 instructiewoorden voerde al deze line-editor functies uit op een file die in het centrale geheugen staat.

O26 line editor commando's
O26 line editor commando's
O26 line editor commando's

O26 line editor commando's
O26 line editor commando’s

Als voorbeeld van de beveiligingen die ingebouwd werden in PP-programma’s, gold het programma ABS waarmee het geheugen van het systeem op papier gedumpt kon worden. Standaard kon iedere gebruiker met ABS de inhoud van het systeemgedeelte van het geheugen en zijn eigen werkgeheugen op papier afdrukken. ABS werd door ons zo gewijzigd dat deze de geheugeninhoud als “nul” rapporteerde tenzij:

  • ABS aangeroepen werd door het besturingssysteem zelf (zogenaamd “control point zero”).
  • ABS aangeroepen werd vanuit een PP-programma dat alleen op het console in “unlock mode” – onbeveiligd draaien – draaien kon.
  • ABS een inherent “veilig geheugengebied” moest dumpen: het eigen geheugen van de job en de “veilige” adresgebieden in het absolute geheugen van het systeem.
  • ABS aangeroepen werd vanuit een systeemprogramma.

In 1981 namen wij het door de Universiteit van Bologna ontwikkelde Tape Security System (TSS) in gebruik nadat dit naar een nieuw releaselevel van het besturingssysteem geconverteerd was en nadat een aantal fouten opgelost en verbeteringen (met name beveiligingslogging) aangebracht waren. Voor gebruikers werd het onmogelijk om magneetbanden van anderen te lezen en/of te overschrijven, tenzij het bij de tape behorende wachtwoord bekend was.

Van een Amerikaan was, net nadat de Data Encryption Standard (DES) openbaar gemaakt was, een snelle Fortranimplementatie van DES ontvangen. Twee maanden later viel DES ineens onder de Amerikaanse exportverboden. Dat weerhield ons niet om DES te gebruiken om gevoelige gegevens te versleutelen, met name in het besturingssysteem. Begin 1984 werden er extra eisen gesteld aan de te gebruiken wachtwoorden, hetgeen door ons middels extra programmacode afgedwongen moest worden. Het INTERCOM (interactive users) password systeem moest aangepast worden. Naast de standaard passwordfile kwam er een extra file, die aan iedere accountnaam een “physical record unit” (PRU) van 64 woorden koppelde. In die PRU werden de laatst gebruikte tien éénweg-versleutelde wachtwoorden bijgehouden. Dit om het hergebruik van wachtwoorden tegen te gaan. Om PCs te weren die een a-b-c-..a schema probeerden uit te voeren om weer lange tijd van het oude wachtwoord gebruik te kunnen maken, werd de lijst met eerder gebruikte wachtwoorden als tegenmaatregel pas bij het tweede gebruik van een wachtwoord opgeschoven in de lijst. Ook werden in de PRU de tijd/datumgegevens van de laatste vijf login’s bijgehouden en tellers waarmee een gebruiker gedwongen werd na 250 log-ins of drie maanden gebruik zijn wachtwoord te wijzigen. In dat geval kon de gebruiker nog enkele malen inloggen voordat een algehele blokkade optrad (grace-login’s).
In het totaal werden zo’n drieduizend regels beveiligingscode (1.5 bak vol met ponskaarten) ontwikkeld welke ingrepen op zo’n veertig systeemprogramma’s en PP’s, alsmede op een tiental overlays van deze PP-programma’s.

Ook op hardwaregebied was het Physisch Laboratorium RVO-TNO beveiligingsbewust. In 1978 hadden wij een manier ontwikkeld om defecte schijfpakketten middels zandstralen voldoende veilig te vernietigen volgens de vigerende NAVO-normen. Bij de introductie van de nieuwe 885-schijfeenheden met head-disk assemblies (HDAs) werd door het Physisch Laboratorium op de wereldwijde gebruikersconferentie in Minneapolis het probleem gesignaleerd dat bij een defect de technici volgens de onderhoudsvoorwaarden de HDA (media plus koppen) mee zouden nemen, iets dat volgens de geldende beveiligingsrichtlijnen niet toegestaan was. Naar aanleiding van onze reactie is door Control Data een wereldwijd geldende restitutieregeling bedacht voor HDAs. Het resterende risico kon afgedekt worden door een kleine opslag op de onderhoudstarieven voor de schijven.

Loader

Na het volgen van een LOADER-cursus waarin alles van loading, linking en dynamic loading duidelijk gemaakt werd, was de kennis daar om een van de problemen die het NOS/BE operating systeem kende voorgoed uit de wereld te helpen. De “loader” is het programma dat er voor zorgt dat een ander programma geladen en opgestart kan worden, waarbij de ‘omgeving’ tevens goed ingesteld wordt.
De wijze waarop systeemcommando’s afgehandeld werden was net iets anders onder het “interactieve” NOS besturingssysteem dan onder NOS/BE. Onder NOS werd ieder volgend commando uit de zogenaamde terminal buffer gehaald en, indien niet aanwezig, werd gewacht op het intypen door de gebruiker van het volgende (sub)commando. Onder het interactieve deelsysteem van NOS/BE, INTERCOM, kon slechts één commando vooruit gegeven worden. Daarna brak het commandoproces af omdat het een einde bestand-signaal ontving. Met de opgedane kennis kon de NOS-code geactiveerd worden en met een anderhalve pagina extra assembler code werd een ergernis voor de gebruikers weggewerkt. In een later stadium is deze code door vele collega computercentra overgenomen en uiteindelijk standaard geworden in het NOS/BE systeem.

Systeemperformance : “Poolse slimheid”

Tijdens een van de ECODU-conferenties werd door een systeemprogrammeur van de Universiteit van Krakau een lezing gegeven die al na vijftien minuten geëindigd was. De normale sessietijd was een uur. Achter het toenmalige ijzeren gordijn moest men minimaal een presentatie geven om een conferentie te mogen bijwonen. Dit keer echter, zette de gepresenteerde ideeën de systeemprogrammeurs van het Physisch Laboratorium aan het denken (en aan het werk).
In het systeemgeheugen stond een tabel voor de PP-loader met pointers naar de juiste locatie van PP-programma’s op schijf of naar een locatie in het vaste deel van het centrale geheugen. In de tabel waren een aantal “bytes” gereserveerd voor verwijzing naar PP code die vooraf geladen waren in een zogenaamd extended geheugen. Extended geheugen was een dure machineuitbreiding. Iets dat noch de Pool, noch wij in ons systeem hadden. Van dat ongebruikte veld maakte hij slim gebruik om daarin de hoeveelheid aanroepen van het PP-programma te tellen. Door de tabel met een Fortran programma regelmatig uit te lezen en te vergelijken met de opgeslagen tellers van een vorige run kon je nagaan welke PP-programma’s vaak en welke in “bursts” aangeroepen werden. Binnen het zeer beperkte centrale computergeheugen werd een deel gebruikt om de essentiële (bijv. foutafhandeling schijven) en de vele malen per seconde aangeroepen PP-programma’s op te slaan. Het laden van PP code was in dat geval het rechtstreeks uitlezen van een aantal geheugenwoorden, vergde geen schijf I/O en was supersnel. Uit de tellingen bleek de standaardselectie van welke PP’s in het dure geheugen stonden voor onze omgeving verre van optimaal te zijn. Een handmatige aanpassing van het systeem leverde een 10% snelheidsverbetering van de machine op.
Toch waren de systeemprogrammeurs nog niet tevreden. Met een load van een tiental PP-programma’s per seconde van de (trage) schijf, werden er enkele extra systeemaanpassingen bedacht. Na de initiële installatie van het systeem op schijf konden wij aan de hand van de eerder genoemde PP-load tabel en andere systeemtabellen uitvinden op welke plaats de circa 3.5 cylinders (14 schijfplaten boven elkaar) aan PP-programmabibliotheek op schijf startte. De bibliotheek werd nu zodanig heringedeeld dat eerst een aantal minst gebruikte PP-programma’s op schijf geschreven werden totdat de reeds gedeeltelijk gevulde cylinder overliep. Dan werden de meest aangeroepen – niet in het computergeheugen staande – PP-programma’s zoveel mogelijk in de volgende gehele cylinder gepropt. Daarna werden de overige PP programma’s op schijf gezet. Doordat de meest gebruikte PP codes in één schijfcylinder aanwezig waren, kon het aantal kopbewegingen van de schijfeenheid aanzienlijk gereduceerd worden en was de kans groot dat een te laden PP-code binnen een halve schijfomwenteling gelezen kon worden zonder noodzaak voor enige armbeweging van de leeskop. Afhankelijk van het type werk, werd hiermee nog een 5-10% performancewinst geboekt. Het kon nog optimaler! Naast de primaire systeembibliotheek, werden later aangebrachte systeemwijzigingen met EDITLIB(SYSTEM) in een tweede schijfbibliotheek bijgehouden. Deze bibliotheek stond ook op de systeemschijf. Deze bibliotheek werd door ons middels een aantal wijzigingen in het standaard besturingssysteem op een andere schijf geschfreven (technisch gezien werd het SYS-bit verschoven). Door nogmaals dezelfde truuk uit te halen en veelgebruikte PP-programma’s die net buiten de ‘hete cylinder’ vielen te vervangen door een kopie van zichzelf, werd een tweede volle cylinder aan meest gebruikte PP-programma’s op een andere schijf geplaatst.
Het performancevoordeel was onmiddellijk merkbaar voor de gebruiker. In meer dan 95% van de gevallen kon een PP-programma direct van een van de twee systeemschijven geladen worden zonder dat dit een enkele tientallen milliseconden vergende herpositionering van de schijfkoppen noodzaakte. Dit leverde een veel gelijkmatiger interactieve responsetijd op, betekende een versnelling in de doorvoersnelheid en zorgde voor een hogere CPU-bezetting per job (het systeem hoefde minder lang op I/O te wachten).

Toch weer performanceproblemen

In 1979 was de CPU-bezetting overdag 50%. In 1980 was die opgelopen tot 60%. De bezettingsgraad over 24 uur per dag was in 1979 23%, in 1980 32% en in 1981 43%.
In de loop van 1981 bleken er dan ook, ondanks de eerder genoemde Poolse en eigen slimheden, problemen op te treden met de interactieve responstijden van de CYBER 74. Met behulp van een programma van SARA geschreven door Edo Roos Lindgreen en een Apple IIe microcomputer werden iedere vijf minuten een aantal eenvoudige interactieve commando’s afgevuurd op de CYBER. De PC mat daarbij de responsetijd en voegde deze toe aan een bestand op de CYBER. Gelijktijdig werden de responsetijden op de PC-monitor zichtbaar gemaakt voor de operators. Zodra er trage responsetijden optraden kon ingegrepen worden in de hoeveelheid batchwerk dat draaide.

Op basis van uitgebreide metingen aan de uitgebouwde CYBER met 14 PP’s en met een extra schijfbesturingseenheid kon aangetoond worden dat uitbreiding of vervanging van de CYBER absoluut noodzakelijk was. Naast de Apple IIe werden ook in het besturingssysteem zelf metingen verricht door een PP-programma dat om de tien seconden een snapshot maakte van het systeem. Dit programma dat verkregen was van het European Center for Mid-Range Weather Forecasting (ECMWF) heette User Performance Measurement (UPM).
Vier extra PP’s en een extra schijfbesturingseenheid bleken de gemiddelde interactieve responsetijd (reactie op volgende invoer in een en dezelfde toepassing) terug te brengen van 1.5 naar 0.4 seconde. De gemiddelde afhandeling van 95% van de commando’s daalde van tien seconden naar 0.5 seconden. Het systeem had hiermee dus weer enige “lucht” gekregen.

Ook de verwerking van batchjobs was nogal eens prioriteitsgevoelig. Jobs van gebruikers die twintig jobs gelijk aanboden werden nogal eens door de operator op prioriteit 0 – niet draaibaar – gezet en werden later niet snel weer opgestart. Hierdoor ging veel CPU-tijd verloren, hetzij door onnodige idle-tijd, hetzij door rerun-tijd. De gebruikers zaten onnodig lang te wachten tot de jobs uitgevoerd waren. Daarnaast werd een langere job nogal eens door de operators naar achteren in de queue gezet, een en ander vaak op basis van persoonlijke voorkeur en inzichten (volgens de meeste gebruikers dus willekeur). Veel klachten waren het gevolg. In mei 1982 werd een nieuw prioriteitsalgoritme voor het in bewerking nemen van batchjobs in gebruik genomen. De volgende intrigerende prioriteitsformule werd gebruikt bij het bepalen van de startprioriteit in de queue:

2200B – 2log(CM*(T+ß*IO) + 2log(seconden wachttijd).

De parameter ß was 2 voor gewone jobs en 0.5 voor tapejobs. De wachtrij aan batchjobs werd vervolgens op een slimme manier verouderd. Ieder zijn batchjob kwam nu eerlijk een keer aan de beurt zonder dat daar veel operatorshandelingen voor nodig waren.

Stresstesten van nieuwe operators

Het operatorconsole van het CYBER-systeem bestond uit twee ronde 15″ kathodestraalbuizen. De tekens werden door middel van R-C-netwerkjes gegenereerd, waarbij de cirkels een nogal afgeplat uiterlijk hadden. Nieuwe operators, die na een aantal weken voor het eerst alleen achter het console gelaten werden, werden onderworpen aan een stress-bestendigheidsproef. Vanaf een terminal werd het PP-programma EYE gestart, een eerste vorm van “Trojan horse“. Het PP-programma nam beide operatorconsolebeelden over, maakte het scherm leeg, toonde vervolgens twee ovalen met daarin een ‘pupil’, ‘keek’ naar links, dan naar rechts, gaf een knipoog en verdween vervolgens weer als een spook in de nacht … Collega’’s hadden zoiets natuurlijk nooit gezien … totdat de spel PP-programma’s en andere zogenaamde L-display programma’s aan de nieuwe operator getoond werden, zoals Chess, Life, Worm, Blob and a space mission programma met gevaren als ‘coffee pot blown by meteorite’.

Aderverroesting en noodkoeling

De CYBER 74 had zoals eerder gezegd waterkoeling welke de warmte van het freon-koelsysteem in de bays af moest voeren. Regelmatig moest het koelwater aangevuld worden vanwege lekkage. Op een gegeven moment gaf een bay van de CYBER 74 aan dat er koelingsproblemen waren. Gek genoeg schommelde de koelwatertemperatuur volgens de ingebouwde meter nogal hard. Het omschakelen van de koelwaterpompen hielp niet. Besloten werd om tijdens het volgende preventief onderhoud de driewegklep in de koelwatertoevoer te vervangen. Bij het losmaken van de leidingen bleek de oorzaak van het probleem. Uit kostenoverwegingen was jaren eerder besloten ijzeren buis te gebruiken voor de koelwaterleidingen. Inmiddels was er zoveel inwendige roest in de pijpen ontstaan, dat de veel dunnere koelleidingen van de CYBER 74 CPU dichtgeslibd waren: het Laboratorium was daarmee de eerste in de wereld met een computer met ‘dichtgeslibde aders’. Besloten werd na om na schoonmaak van het koelsysteem van de CYBER tijdelijk een externe ‘bloedcirculatie’ aan te leggen. De noodkoeling bestond uit een brandslang die gekoppeld was aan de koelwater invoerzijde. Aan de afvoerzijde werd het warme water via een tweede brandslang uit het raam op de binnenplaats geloosd. Dat gedurende de drie weken dat het kostte om het pijpenwerk van de koelwatervoorziening volledig te vervangen. Kort daarna viel het Laboratoriumterrein ineens onder het waterwingebied van de Haagse Duinwaterleiding.

Foto van een CDC 6600 met een voor de CYBER 74 vergelijkbare koeling. Goed zichtbaar is ook de bedrading die de CPU-delen met elkaar verbindt (foto courtesy van Ed Thelen)
Foto van een CDC 6600 met een voor de CYBER 74 vergelijkbare koeling. Goed zichtbaar is ook de bedrading die de CPU-delen met elkaar verbindt (foto courtesy van http://ed-thelen.org/comp-hist/)

Nog meer koelperikelen

Het koelsysteem van de airconditioning was ook niet altijd even betrouwbaar. Er was een periode dat de warmtewisselaar op het dak bevroor. Indien niet tijdig handmatig ingegrepen werd, dus meestal ‘s-nachts als er niemand was, dan liep de temperatuur in de computerruimte snel op tot boven de 27 C. Dan ging er gedurende dertig seconden een alarm en volgde het automatisch uitschakelen van alle spanning. Resultaat was meestal (de bekende Murphy spookte meestal ‘s-nachts) een onderbroken schrijfactie op de schijven met een beschadigd bestandssysteem tot gevolg. Het resultaat was een moeizaam herstellen van de schijven, een karwei van zo’n vier tot zes uur. Na de zoveelste langdurige herstelwerkzaamheden werd een slimme oplossing bedacht, welke ineens tijdens een slapeloze nacht opkwam. Als het systeem toch automatisch ‘plat ging’ door stroomuitschakeling was er geen enkele reden om het systeem niet vijf seconden eerder te ‘deadstarten’ (‘boot’). Dan kon er alleen maar een niet-destructieve leesactie aan de gang zijn. Een timer van enkele tientjes en anderhalf uur installatiewerk waarbij een contact gesloten kon worden parallel aan de deadstart-knop hielp de gevolgen van koelingsproblemen voorgoed uit de wereld.

Om het “restore”-proces na calamiteiten te optimaliseren werd er Fortran programmatuur geschreven die een optimale hoeveelheid magneetbandjobs voor terugladen opleverde. Beide magneetbandeenheden konden daardoor gelijktijdig gebruikt worden voor het terugladen, hetgeen een aanzienlijke tijdbesparing betekende. Tevens werden de om allerlei redenen niet van de meest recente backups terug te laden bestanden automatisch geladen vanaf de meest recente (volledige) wekelijkse backup.