Computerhistorie: Ponskaartentijdperk CDC 6400

 

De CDC 6400: het ponskaartentijdperk (1974 – 1978)

In mei 1974 werd een Control Data 6400 systeem in de computerruimte van het toenmalige Physisch Laboratorium TNO geïnstalleerd. Seymour R.Cray (architect) en James E.Thornton (gedetailleerd ontwerp) ontwierpen in 1966 het Control Data 6600-systeem als “supercomputer”. 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.

De Control Data 6400 werd in 1965 op de markt gebracht als een eenvoudiger en circa 2.5 maal tragere versie van de 6600. Een dergelijke machine 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.
In december 1974, werd een Control Data System 17 minicomputer met een CDC 6400-kanaalinterface aan de configuratie toegevoegd.

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 (losvast in de hand) aan tot een net pakket, zette de stapel kaarten vervolgens op de inleesbaan, zette vervolgens de motor van de lezer aan, en gaf na het lezen vervolgens de stapel kaarten weer terug aan de programmeur. De balie-operator verzorgde ook de print- en plotuitvoer die in een “ruif” gelegd werd. Omdat 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 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. Ouderen herinneren zich die kaarten nog van de Postgiro. 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. Ook draaide de assembler voor Digital General NOVA minicomputers, 16-bit machines met 32k woorden,  op de Control Data 6400.

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. Door velen werd de Control Data 6600-architectuur aangemerkt als het eerste Reduced Instruction Set Computer (RISC).

Het systeem had acht 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 het corresponderende X-register (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. Dat 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 overigens wel voor dat door programmeerfouten twee of meer verschillende PP-programma’s ieder in een andere volgorde enkele “interlocking kanalen” aanvroegen. Eens in de vele honderden draaiuren (dagen tot weken) 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 programmeerfouten vaak in een uur of twee opgelost worden. Overigens werd deze software interlock-techniek eind 80-er jaren door Digital Equipment Corporation, een andere grote computerleverancier, gebracht als nieuwe techniek die symmetrische multi-processing mogelijk maakte, de zogenaamde “spin-lock”.

Het centrale geheugen bestond uit circa 65.000 woorden kerngeheugen van 60 bits zonder enige vorm van parity- of SecDed-bescherming (circa 480 KiloByte). Een “bank” bestond uit 5 blokken van 12 bits tezamen 4k 60 bit woorden. Om een hogere transportsnelheid van/naar het geheugen te halen, werden de banks  “interleaved” geklokt. Met interleave factor van 8 van de CDC 6400 werd 8* 4k woorden oftewel 32 kWoorden aangestuurd. Noot: de CDC 6600 werd alleen geleverd in een 64 of 128 kWoorden uitvoering; een interleave factor 16 respectievelijk 32. 

Door alle kleine letters en speciale tekens weg te laten (dat was voor wetenschappelijk rekenwerk in die tijd tenslotte niet nodig) konden tekens in 6 bits “bytes” (10 stuks per woord) opgeslagen worden. Hier lag het begin van het jaar 2000 (Y2K) oftewel millennium probleem.

In 1977 was de behoefte aan geheugen bij TNO 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 effectief in een twee keer zo groot geheugen voor de batchjobs. Het besturingssysteem vereiste tenslotte ook een vast stuk geheugen.

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 had de machine 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’ dumptape te analyseren op ‘bitdrops’ door deze te vergelijken met een dump van de geheugeninhoud van een net fris opgestart systeem. Visuele analyse van de vergelijking maakte een snelle herkenning van bitdrops in elk volgend achtste woord mogelijk. Daarmee was het mogelijk om het defecte geheugenblok of stuurlogica aan te wijzen. Daarmee kon veel tijdwinst geboekt worden bij de reparatie, vooral wanneer de fout af en toe optrad.
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 door regelmatig kleine berekeningen uitvoeren. Bij een storing ging de job knipperend hangen met een storingsbericht voor de operator. 

Schijfopslag

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 die suggereerden dat bestanden effectief gebruikt werden waren verboden, doch werden soms door de gebruikers gemaskeerd als Fortran-programma’s. Operations had als “counter-measure” speciale programma’s die dergelijke 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 in de computerruimte te horen was. Dat werd 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 parallel aan het werk gezet worden om de schijf te beschrijven en sequentieel of op random wijze 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 was en alleen 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 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, maar de operators konden het systeem niet meer besturen en controleren. Werd er een oscilloscoop aan het uitvoerkanaal van de machine 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 onverklaarbare “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 octale dump een softwarefout aanwees: hij las de octale dumps als of het de krant was!
Uiteindelijk kon met de eerder genoemde ‘schijfmishandeljobs’ 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 systeem wachtte op de klok van ‘extended memory’ dat wij niet hadden. 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 TNO: 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 geheel 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 van het besturingssysteem 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 andere typen schijfbesturingseenheden, kanalen en tape-eenheden in gebruik waren. Na het intokkelen van de bootstrap-schakelaars en een druk op de deadstartknop, rekende het systeem binnen 2 minuten verder aan de op de TNO machine bevroren rekenklussen.

Anekdote: minirok-perikelen

In 1978 kwam er een nieuwe printer die sneller was, minder “dansende” letters opleverde en minder geluid maakte. Ook had de nieuwe 580-printer een automatische “tafel” waar de uitvoer netjes opgevouwen werd. Zoals gebruikelijk werd er op het “floorplan” met een schaalmodel geschoven totdat de juiste plaats bepaald was. Vooraf werden gaten gezaagd in de tegels van de verhoogde computervloer en werden de elektrische en signaalkabels voorbereid. Er was echter iets over het hoofd gezien: het deurtje van de nieuwe printer draaide de andere kant uit dan die van de oude printer.
Omdat ze computers razend interessant vond, viel een van de secretaresses regelmatig in als operatrice. Nu hield zij ook van hippe minirokken. De in die tijd voornamelijk mannelijke Laboratorium-bevolking, waaronder vele militair gedetacheerden, ook. Nu is het uit de printer halen van de uitvoer ergonomisch gezien een minder geslaagd type werk voor iemand met een minirok. Om het snel groeiende “sociale gebeuren” bij de balie te beteugelen werd ijlings besloten de printer 90 graden te draaien. Het gezicht op de printer vanaf het console verbeterde aanzienlijk.

Systeemprogrammatuur

Het Scope 3.4 operating systeem, later herdoopt in Network Operating System/Batch Environment oftewel NOS/BE, werd tezamen met de vertalers in de vorm van broncode op een stapel magneetbanden aangeleverd. Voor Systeemprogrammering op het Physisch Laboratorium TNO was het een soort sport om nieuwe versies (“levels”) voor het besturingssysteem als “eerste in de wereld” in productie te hebben. Naast het voordeel van de nieuwe mogelijkheden waar de gebruikers vaak om zaten te springen was er het nadeel dat systeemfouten veelal pas in “het veld” in een operationele omgeving gevonden werden. De veelzijdigheid van problemen en systeemfouten die hierdoor om een vaak snelle oplossing vroegen betekende dat er veel ervaring opgedaan werd om een fout snel te analyseren, een hypothese te stellen, een oplossing te genereren en deze tijdens het “happy hour” voor systeemprogrammering (systeemtijd van 17.30 tot 18.30 uur) te verifiëren en definitief te installeren.
Probleem was dat het Laboratorium net als alle collega-rekencentra in Nederland gekozen voor de zogenaamde 63 character set. Control Data testte in Amerika alleen systemen met de 64 character set. Niet goed ontwikkelde code of code van hun “nieuwe” programmeurs die geen rekening hield met de 63-set leverde bij bijna iedere nieuwe release één of meer fouten op, die wij op het Physisch Laboratorium corrigeerden en met veel misbaar “wereldkundig” maakten via het Problem Reporting System-mechanisme (PSR). Iedere twee weken werd een setje microfiches met alle wereldwijd verzamelde klachten – en oplossingen – door Control Data aan alle rekencentra in de wereld toegestuurd. Bij ieder release-level was het spannend of de door ons gevonden fouten als eerste gemeld waren of dat onze collega van de Universiteit van Arizona met de eer ging strijken.

 

Door het Laboratorium aangemelde softwareproblemen
(site code PLTN)

Jaar	Ingezonden klachten	Met code (opgelost door TNO zelf)	Jaar	Ingezonden klachten	Met code (opgelost door TNO zelf)
1975	67	31	1983	69	48
1976	56	48	1984	36	20
1977	56	45	1985	231	54
1978	70	44	1986	216	21
1979	134	49	1987	252	14
1980	86	75	1988	201	4
1981	63	51	1989	136	0
1982	69	29	1990	78	0

 
Naast correcties voor systeemfouten, werd veel aanvullende code zelf ontwikkeld. Ook werd veel code zelf geschreven om de werkzaamheden van de operator aan het console te verlichten. Daar waar het standaard NOS/BE operating systeem het samenspel van twee of drie schermen vereiste om een commando in te typen, brachten wij alle benodigde informatie op één schermbeeld tezamen. Ook werd in een aantal operatorcommando’s het intypen van de volledige 7-tekens lange jobnaam vervangen door het intypen van de twee of driecijferige ‘ordinal’ of werd de jobnaam automatisch aangevuld. Het Laboratorium liep wat dit betreft ver vooruit op wat later de ergonomische werkplek zou gaan heten.

Anekdote: “de Directeur keek vreemd op..”

De sectie Programmeren van de Computergroep schreef en onderhield verschillende programma’s voor de Krijgsmacht. Voor oefeningen van de communicatiecentra van de Koninklijke Landmacht was een programma geschreven om random trigrammen op te leveren, die aan een aantal specifieke eisen moesten voldoen. Om het werk van de dienstplichtigen die de verbindingen tot stand moesten brengen interessant te houden, werden de “random”-parameters zo gevarieerd dat er een zo groot mogelijke hoeveelheid “drieletterwoorden” in de aan de opdrachtgever opgeleverde lijsten voorkwamen. De dienstplichtige soldaten waardeerden dat hooglijk, totdat een generaal op inspectie was in de communicatiebunker. “Nieuw trigram!” “K..T“… De generaal: “Op rapport!” “Maar Generaal, in deze lijst staat K..T, ziet u wel.” Waarop de Directeur van het Physisch Laboratorium een brief van de Generaal ontving met dank voor de tijdig geleverde lijst met trigrammen en tevens de opdracht om de lijsten met trigrammen minder random aan te maken. In de brief werden door de opdrachtgever met name de drieletter woorden “k..t” en “l..l” letterlijk genoemd als trigrammen die voortaan gefilterd moesten worden. Waarschijnlijk is dit de enige opdrachtspecificatie ooit aan TNO geweest waarin de klant drieletterwoorden specificeerde! Overigens was het daarna voor de programmeur een sport om nieuwe vergelijkbare trigrammen rijkelijk ‘random’ in de lijsten te zetten voor zijn klanten, “de dienstplichtigen”.
 
Terug Volgende