[TNO-logo]
Museum logo

De CDC 6400:
"het ponskaarten-tijdperk"


De CDC 6400 (64 KW-uitvoering). Op de voorgrond het console.
Rechts de twee CDC 844-21 schijfeenheden en daarachter CDC 659-magneetbandeenheden.

Een Control Data 6400 systeem werd in mei 1974 geïnstalleerd in de computerruimte van het toenmalige Physisch Laboratorium. Het Control Data 6600-systeem werd in 1964 ontwikkeld als "supercomputer" door Seymour R.Cray (architect) en James E.Thornton (detailed design). De Control Data 6400 werd in 1965 op de markt gebracht als een eenvoudiger en circa 2.5 maal tragere versie van de 6600. De Control Data 6400 werd voor zijn tweede levensperiode verhuurd aan het Laboratorium.

Het systeem was - voor die tijd - zeer snel en omvatte ook twee tape-units, een kaartlezer - die 600 kaarten per minuut kon lezen - en een kettingprinter. De architectuur van de genoemde 6000 series computers werd nog al eens gebruikt als model voor studies op het gebied van Petri-nets en optimalisatietechnieken.

Practical jokes met ponskaarten

In die tijd moesten de gebruikers hun bak of stapel kaarten inleveren bij de balie-operator. (zie ook: alles over ponskaarten). Die pakte een stapel kaarten, klopte deze met een speciale techniek (hand-los) aan tot een net pakketm, zette deze vervolgens in de inleesbaan, zette de lezer aan, en gaf vervolgens de stapel of bak weer terug. De balie-operator verzorgde ook de print- en plotuitvoer die in een "ruif" gelegd werd. Omdat een aantal ongeduldige gebruikers graag op het afscheuren van hun uitvoer wilden wachten, was de balie ook een "sociale plaats" voor het uitwisselen van nieuwtjes en dergelijke.

Eén van de operators loerde op een kans om een ‘practical joke’ uit te halen met een van de gebruikers. Een groot pak ponskaarten werd alvast verzameld uit de afvalbakken in de ponskamer. En ja hoor, nadat hij zijn kaartenbak had afgegeven raakte de gebruiker in gesprek en lette even niet goed op. In plaats van zijn programma werd een even groot pak afvalkaarten in de bak geplaatst en met de woorden "je programma draait, deze kaarten kunnen wel weg, hé ?" werd de bak op zijn kop gehouden en lag de grond bezaaid met ponskaarten. Het lijdend voorwerp stond wel even te slikken.....

In die tijd werden er ook ponskaarten gemaakt met een afscheurbare (controle)strook. Onder andere de Postgiro maakte daar gebruik van. Om deze korte ponskaarten (51-koloms) te kunnen lezen was er een uitklapbare aanslag op de kaartlezer. Werd dit gebruikt met de standaard 80-koloms ponskaarten dan verfrommelden die daarop spectaculair.... Ook hier kwam de afvalbak wel eens te hulp om een gebruiker witjes te laten wegtrekken.

Als systeemsoftware was naast het Scope 3.4 operating systeem, vertalers voor FTN4 (Fortran), ALGOL 60, BASIC, COBOL, SIMSCRIPT, PERT/TIME, SIMULA, APEX en APT IV Automatic Programmed Tools (voor mechanisch construeren oftewel MCAD) aanwezig. Daarnaast werd geprobeerd om een vertaler voor PROSIM, een simulatietaal die ontwikkeld werd door de Technische Hogeschool Delft, aan het werken te krijgen.

Architectuur van de Control Data 6400 rekeneenheid

De Control Data 6400 bestond uit een centrale verwerkingseenheid en tien peripheral processors (PP’s). Deze hulpprocessoren verzorgden alle hulptaken in het systeem zoals de gegevenspresentatie op het systeemconsole (twee ronde 15"-elektronenbuizen), datatransport naar de schijf- en magneetbandbesturingseenheden en alle overige hulpoperaties. Tot wel enkele honderden PP-programma’s per seconde werden parallel uitgevoerd. Parallelle processing is dus een "oud vak" op TNO-FEL.

Door velen wordt de Control Data 6600-architectuur aangemerkt als het eerste Reduced Instruction Set Computer (RISC).

Het systeem had 8 adresregisters (A-registers) gekoppeld aan 8* 60-bits gegevensregisters (X-registers). Het laden van een nieuwe (adres)waarde in vijf van de A-registers (A1-A5) had een "load" vanuit het hoofdgeheugen naar een van de corresponderende X-registers (X1-X5) tot gevolg, terwijl een nieuwe adreswaarde in het A6 of A7-register een "store" van het overeenkomstige X-register naar het geheugen tot gevolg had. Voor indexering en eenvoudige integers beschikte het systeem over 8* B-registers. Het B0 register had hardwarematig de vaste waarde 0. Dit omdat anders een aantal elementaire berekeningen en registeroperaties niet mogelijk zouden zijn. Voorts kende het systeem een beperkte instructieset van circa 60 instructies.

Iedere PP had een eigen geheugen tot zijn beschikking (4096 woorden van 12 bits). Ook de PP’s hadden een beperkte instructieset. Gegevens konden alleen in de "accumulator" of het geheugen bewaard worden. Interlocking van de parallelverwerking was softwarematig geregeld. Een PP-programma zette een "completion bit" of wachtte op het vrijkomen van een "interlock bit" in het centrale geheugen. Feitelijk was er in het systeem slechts één peripheral processing eenheid die door alle "PP’s" (in een barrel) cyclisch "time-shared" gebruikt werd. Hierdoor was interlocking een "unieke" gebeurtenis waarbij verschillende PP-programma’s elkaar niet in de weg konden zitten.

Het kwam wel eens voor dat twee of meer verschillende PP-programma’s ieder in een andere volgorde enkele "interlocking kanalen" aanvroegen. Eens in de vele honderden draaiuren kon het systeem dan in een deadlock komen. Voor de systeemprogrammeurs het moment om drie of vier listings van zo’n drie tot vierhonderd pagina’s naast elkaar te leggen en te bestuderen. Door ervaring konden dit soort problemen vaak in een uur of twee opgelost worden. Overigens werd deze software interlock-techniek eind 80-er jaren door een grote computerleverancier gebracht als nieuwe (!) techniek die symmetrische multi-processing mogelijk maakte, de zogenaamde "spin-lock".

Het centrale geheugen bestond uit circa 65000 woorden kerngeheugen van 60 bits zonder enige vorm van parity- of SecDed-bescherming (circa 480 KiloByte). Om een hogere transportsnelheid van/naar het geheugen te halen was dit onderverdeeld in 8 "banks". Door alle kleine letters en speciale tekens weg te laten (dat was voor wetenschappelijk rekenwerk in die tijd tenslotte niet nodig) konden tekens in "bytes" van 6 bits (10 per woord) opgeslagen worden. Hier lag het begin van het jaar 2000 (Y2K) oftewel millennium probleem.

In 1977 was de behoefte aan geheugen zo gegroeid, dat, na drie dagen wire-wrapping, een extra "geheugenpoot" aan de machine gezet werd. De uitbreiding tot 98 Kwoorden resulteerde voor de gebruikers in een twee keer zo groot geheugen voor de batchjobs.

De kans op foutieve berekeningen ten gevolge van het ontbreken van hardware-parity was kleiner dan die ten gevolge van defecten in de rekeneenheid of de systeemsoftware. Wekelijks was drie uur preventief onderhoud nodig. Dagen dat er vijf of zes systeemcrashes voorkwamen werden in die tijd normaal gevonden. Speciale programma’s werden geschreven om een "crash"-tape te analyseren op "bitdrops" door deze te vergelijken met de geheugeninhoud van een net fris opgestart systeem. Door uit te rekenen welk bit in welke geheugenbank faalde kon veel tijdwinst geboekt worden bij de reparatie. Om te bewaken dat de rekeneenheid (nog) goed werkte, draaiden er batchjobs mee in het systeem die continu de juiste werking van de CPU en het geheugen controleerden.

Schijven

In 1974 waren er twee schijfeenheden (CDC 844-21) met verwisselbare schijfpakketten aangesloten. Ieder pakket had een formidabele opslagcapaciteit van 712 miljoen bits bruto oftewel 100 MB. Het grootste deel van de ruimte ging op aan het operating systeem, vertalers en bibliotheken. De overige technische specificaties waren: dertig tot 165 msec positioneringstijd en een transfersnelheid van 6.8 Mbits/sec of circa 1 MB/sec.

Vrijwel ieder jaar kwam er een schijfeenheid bij om de groei van de gebruikersgegevens op te vangen. Vanaf 1975 betrof dit de "dubbel density" schijven (CDC 844-41) met 200 MB opslagruimte. Files van gebruikers die een maand lang niet gebruikt waren, werden door Operations verwijderd.
Zogenaamde "attach"-jobs waren verboden, doch werden soms door de gebruikers gemaskeerd als Fortran-programma’s. Operations had als "counter-measure" speciale programma’s die de attach-jobs konden opsporen.

Zo eens in het jaar gebeurde het dat kogellagers van een van de schijfeenheden uitliepen. Was men er snel genoeg bij, dan kon dat verholpen worden. Het gebeurde ook wel eens dat er een slijpend geluid te horen was. Dit gevolgd door een bruine rookwolk aan oxide-deeltjes die door de lees- en schrijfkoppen uit de schijf geploegd werden.

Omdat het herstellen van het schijfsysteem na een schijfcrash vier tot zes uur nam, werd een nieuwe schijfeenheid altijd aan een één dag durende acceptatietest onderworpen. Omdat de centrale processor niet hoefde te wachten tot een I/O-actie gereed was konden, meer PP’s gelijktijdig aan het werk gezet worden om de schijf te beschrijven en sequentieel of random te lezen. De ultieme test was het laten heen en weer springen van de koppen tussen eerste en de laatste "cilinder" op het schijvenpakket. Op deze wijze hebben wij eens een schijfeenheid dusdanig in de "eigen frequentie" aangesproken dat die in de loop van de nacht een meter van zijn plaats gewandeld is en door de channel-kabels weerhouden werd van verdere escapades.
De technici van Control Data waren dan ook niet altijd blij met de "TNO-testen"! Ten opzichte van collega rekencentra hadden onze schijfeenheden daarna wel een veel hogere mean-time between failure (MTBF).

Anderhalve centimeter en uitwijk

In de periode juli tot oktober 1980 was er een periode dat het CDC 6400 console een of enkele malen per dag "zwart" werd, een zogenaamde blank-screen. Het systeem draaide wel door doch de Operators konden het systeem niet meer besturen. Werd er een oscilloscoop aan het uitvoerkanaal naar het console gehangen, dan ging het probleem soms spontaan weg of resulteerde in een totale crash van het systeem. Ook traden er af en toe andere "hangs" op, die niet eenvoudig op te lossen waren. Technici van de leverancier werden opgetrommeld uit de Verenigde Staten en Zwitserland. Bijna iedere module werd systematisch omgeruild, doch het probleem bleef. Ook Systeemprogrammering probeerde crashdumps te analyseren en het probleem te analyseren. Wij stonden echter verbaasd toen de hardwarespecialist in een oktale dump een softwarefout aanwees: hij las de octale dumps als of het de krant was !

Uiteindelijk kon met de eerder genoemde acceptatiejobs voor de schijven tezamen met een iets versnelde systeemklok aangetoond worden dat de timing van de in- en uitvoerkanalen niet geheel was zoals die hoorde te zijn. Het inkorten van een enkele meterslange klokdraad met anderhalve centimeter loste het probleem voorgoed op.

Nu waren er door deze problemen vele CPU-uren verloren gegaan. Dat terwijl er twee grote spoedopdrachten liepen voor het Physisch Laboratorium: simulaties waarop de Tweede Kamer zat te wachten betreffende de verwerving van nieuwe dan wel de conversie van oude tanks en simulaties voor de Koninklijke Marine betreffende berekeningen aan een nieuw type fregat.

In overleg met Control Data Nederland mochten wij twee achtereenvolgende weekeinden van 8 tot 20 uur gebruik maken van de CDC 6600 (machinenummer 1) die bij Control Data in Rijswijk opgesteld stond. De Control Data 6600 was twee tot 2.5 maal zo snel als de Control Data 6400. Probleem was de KRONOS-operating systeemomgeving die niet aansloot op wat bij het Physisch Laboratorium TNO in gebruik was. De oplossing was het aanmaken van een eigen mini-operating systeem op twee verwisselbare schijfpakketten. Door slim gebruik te maken van de net nieuwe mogelijkheid om een operationele omgeving te "bevriezen" konden wij het systeem in Rijswijk zeer snel opbrengen. Alleen moesten enige "Equipment Status Entries (EST)" aangepast worden en moesten de "deadstart" schakelaars juist ingesteld worden omdat er in Rijswijk een ander type schijfbesturingseenheden, kanalen en tape-eenheden in gebruik waren. Daarna rekende het systeem binnen 2 minuten verder aan de bevroren rekenklussen.

"Design of a computer: The Control Data 6600" (title in 6000 console display lettering!), J.E.Thornton; Scott, Foresman and Company, 1970; Library of Congres Catalog No. 74-96462



Museum Homepage