Een eerste serie bezwaren geldt de functionele specificatie van de kanaalorganisatie. Deze is ontworpen met de bedoeling dat de CPU een keten commando's ter sequentiele afwerking aan een kanaal kan aanbieden. De hardware is echter slecht bruikbaar doordat:
1) als een kanaal een interruptie signaal naar de CPU zendt voordat een vorig signaal van dit kanaal door de CPU gehonoreerd is, het vorige interruptie signaal onder tafel raakt;
2) het onmogelijk is op een betrouwbare manier een commando aan te haken aan een keten, die door het kanaal in bewerking is: probeert de CPU dit, dan is onder omstandigheden niet meer betrouwbaar vast te stellen, of het kanaal dit nieuwe commando nu nog wel of juist niet meer heeft uitgevoerd. (Deze onmogelijkheid is het gevolg van het feit dat de lengte van de commandoketen is aangegeven door markering van de laatste schakel.)
3) als de uitvoering van een commando mislukt, dit feit wel gemeld wordt, maar het kanaal na deze mislukking het volgende commando in de keten gaat uitvoeren alsof er niets mislukt was.
Ten gevolge van deze tekortkomingen kan de commandoketen niet gebruikt worden zoals bedoeld was en staat het operating system voor anders vermijdmare morele haastsituaties. (Zij, die niet in operating systems thuis zijn, voelen dit waarschijnlijk als detailcritiek. Ik vind het gesignaleerde defect echter een alarmerende indicatie ten aanzien van de competentie van het ontwerpersteam: hier is geen kwestie van smaak of stijl, er is met een zinvolle bedoeling het een en ander ontworpen terwijl een simpele redenering aantoont, dat de geboden faciliteiten ontoereikend zijn.)
Een tweede serie bezwaren bestaat uit voorbeelden, dat de ontwerpers de programma's teveel belast hebben met het beheer van de componenten van de machine, in plaats van het programma het proces op een abstracter niveau te laten vastleggen, het specifieke componentenbeheer aan systeem/machine delegerend. Voorbeelden hiervan zijn de volgende.
1) Peripherieapparaten kunnen slechts bediend worden door ze te koppelen aan een kanaal en vervolgens aan dit kanaal de commando's te geven. En dat terwijl het kanaal logisch geen betekenis heeft, het peripherieapparaat wel.
2) Het rekenorgaan bevat een groot aantal registers, waarvan in de programmatext expliciet staat aangegeven, welke er in elke opdracht gebruikt worden. Dit heeft onaangename gevolgen:
2a) dat compilers met het probleem "register allocation" geconfronteerd worden, wat leidt tot een aan vertaaltijd kostbaar optimaliseringsproces
2b) dat het soort statuswisseling, dat optreedt bij subroutineaanroep en multiprogrammering onontkoombaar tijdrovend wordt door red- en herstelplichten van registerinhouden (nodig of niet!).
Hier is het ontwerp microscopisch geoptimaliseerd, terwijl je macroscopisch de prijs vele malen betalen moet:
ad 2a) de tijdrovendheid van het vertaalproces is verantwoordelijk voor de behoefte aan "onafhankelijk voorvertaalde programmaonderdelen", welker combinatie de behoefte aan een zg. linkage editor gecreeerd heeft;
ad 2b) als qua tijd de schoen begint te knellen, moet je de subroutineaanroep vervangen door een aangepaste copie van de subroutinetext, wat aanleiding geeft tot heel lange programma's, zo lang, dat hun assemblage "a major processing task" wordt (Asher Oppler, IFIP 1965). IBM wil de dan benodigde geheugens graag leveren!
3) In plaats van dat het programma informatie adresseert, moet het geheugen adresseren, hetzij in kernen, hetzij disks, tengevolge waarvan elk programma individueel belast is met een prive- organisatie van "overlay's" en transporten tussen langzaam en snel geheugen. Dit heeft vrij rampzalige consequenties:
3a) Standaardprogramma's moeten bestaan in verschillende versies, al naar behoefte aan kerngeheugen. De wens programma's van anderen te gebruiken (APT voor de 360 bv.) kan je dwingen om je installatie met minstens zoveel kerngeheugen uit te rusten. Evenzo: vergroting van het kerngeheugen geeft niet geruisloos -dwz. zonder herprogrammering- efficiencywinst.
3b) De enige manier, waarop verschillende programma's enkelvoudig in het kerngeheugen aanwezige gemeenschappelijke routines samen kunnen gebruiken eist, dat deze routines permanent in het kerngeheugen staan. Omdat je hier dan weer zuinig mee moet zijn, is de behoefte aan "system generation" geschapen, systeemaanpassing aan de "problem mix", met alle ellende van dien: het is een tijdrovend proces en bovendien wil je het niet, want je "problem mix" kan immers veranderen!
3c) Het feit dat programma's gedurende hun executie een consecutief, onverschuifbaar stuk kerngeheugen bezetten verzwaart de scheduling task onnodig en buiten proportie, het resulterende systeem blijft stroef hanteerbaar.
Kortom: inbeddingsdetails, waarvan door iets geraffineerdere hardware geabstraheerd had kunnen worden, eisen nu hun expliciete representatie in de programma's. Enerzijds verzwaart deze onnodige explicietheid de programmaopbouw, anderzijds schaadt deze premature fixering de souplesse, waarmee de installatie nu nog gebruikt kan worden.
Het ongelofelijke is, dat deze machine nu geadverteerd wordt met het "wonderful operating system", dat zoveel lasten van de schouders van de programmeur afneemt. Men verdoezelt hierbij:
a) dat een groot gedeelte van deze lasten door de hardware zijn ontstaan en in een beter ontwerp lichter of non-existent waren geweest;
b) dat dit operating system een schrikbarende overhead impliceert (maar IBM wil je graag een sneller model uit de serie leveren);
c) dat de lasten de facto niet zijn opgevangen, maar overgeheveld zijn naar de directie van het rekencentrum, die de machine moet dimensioneren en beheren;
d) dat het maken van dit operating system een opgave is gebleken, die het programmerend vermogen van de fabrikant te boven is gegaan;
e) dat het systeem een zo barokke monstruositeit is geworden, dat geen gebruiker zich meer aan aanpassing kan wagen.
Ten leste, zoals de 709-serie me altijd getroffen heeft als een wanhopige poging om tapes als back up store te gebruiken, zo treft de 360-serie me als disk units met begeleidende electronica. Het zou me niet verbazen, als de wat teleurstellende performance van de snellere modellen in feite neerkomt op het feit, dat het snellere model, zeg, vier maal zo snel op de armbeweging staat te wachten. Hoe ze uit deze vicieuze cirkel moeten komen is me niet duidelijk: deze discrepantie opvangen door multiprogrammering is van de kant van de CPU erg onaantrekkelijk, overgang op "one-head-per-track-disks" zou wel eens veel van de motivering van het huidige operating system kunnen ontzenuwen.