Computerhistorie: Datacommunicatie 1986 – 1989

 

Datacommunicatie (1986 – 1989)

Dubbele gateways: DECnet – TCP/IP – XNS

In mei 1988 werd door het FEL zowel een CDC Network Device Interface (NDI) geïnstalleerd evenals een DEC microVAX2000 onder Ultrix (Unix variant). Deze NDI staat als Gateway DI oftewel GDI op het onderstaande FELLAN configuratieschema ingetekend. De NDI “sprak” zowel XNS (CDCnet) als TCP/IP; de VAX2000 DECnet en TCP/IP. Deze gateways waren aangeschaft om zowel de VAXen als de CYBER te kunnen laten communiceren met de grafische systemen die gebaseerd waren op SUN systemen.

FELLAN (maart 1988)
FELLAN (maart 1988) – met de XNS/CDCNet, DECnet en TCP/IP backbone en de twee gateways

Door SMS werd echter een nog belangrijker applicatie bedacht: het gezamenlijk gebruik door alle machinelijnen van de snelle centrale CDC 585 printer die 2000 regels per minuut kon printen. Het versturen via twee gateways van af te drukken bestanden via een keten aan protocolstacks DECnet – TCP/IP – XNS – NOS/VE – CDCnet werd op een unieke en slimme wijze gerealiseerd. De bestanden werden met een VMS (netwerk) COPY-opdracht via DECnet verstuurd naar de Ultrix-gateway. Deze ontdekte dat de file bedoeld was voor een ander UNIX-achtig systeem en kopieerde de file via een FTP-opdracht naar dat UNIX-systeem (aan de Cyber-zijde). De FTP-opdracht werd aan de CYBER kant verwerkt als een ftp-batchjob. Daarbij maakten wij gebruikt van een interessante NOS/VE optie: login- en logout-profiles. Prologs en epilogs riepen automatisch een aantal commando’s aan die respectievelijk aan het begin en het einde van een job uitgevoerd werden. Ook voor ontvangen ftp-opdrachten werkte dit proces. Door een af te drukken file in een speciale “catalog” op te slaan konden de in de logout-profile (“epilog”) aangeroepen procedures de ontvangen uitvoerfiles met de juiste filters en parameters in de print-uitvoerqueue zetten. In de filenaam waren de gebruikersnaam (voor de printbanner pagina), de formscode (type papier) en de uitvoerfilenamen op slimme wijze versleuteld.

Het grootste probleem werd gevormd door de DEC Ultrix-implementatie, die in eerste instantie niet geheel transparant werkte voor niet-DEC TCP/IP implementaties. Dollartekens werden weggefilterd uit de filenaam en carriage returns/line feed (CR/LF) combinaties werden verwijderd (“stream-mode”). Enkele patches zorgden voor een unieke situatie, die veel bewondering van collega’s oogstte: één gateway was al moeilijk genoeg, doch die knutselaars in Den Haag gebruikten zeer kosteneffectief één centraal systeem waarop alle dure I/O-apparatuur geconcentreerd was (plotter en printers) voor alle op het LAN aangesloten systemen via een dubbele gateway.

PCLAN

In 1987 en 1988 werden er door groep 2.6 twee toen zeer “zware” Compaq 386 PC’s als servers aangeschaft waarop Novell-software geïnstalleerd werd. Op 28 juni 1988 werd in een colloquium een introductie gegeven van de mogelijkheden voor de gebruikers van de Novell-systemen. Ingegaan werd op de services die het netwerk voor de gebruikers ging bieden: file access, remote file access, remote login en remote resources vanaf de IBM/PCs, later ook Compaqs die in grote getale op de werkplekken verschenen. In de presentatie werd in een matrix getoond dat alle systemen op TNO locatie Waalsdorp op dat moment bestanden met elkaar uit konden wisselen via het FELLAN. PC’s vormden echter de uitzondering. Dat was opvallend omdat het FELLAN in eerste instantie bedoeld was voor PC file services!
Eind 1988 werden de dagelijkse beheerstaken als lastig ervaren en werd door groep 2.6 gepoogd het beheer van deze systemen over te dragen aan de groepen Computers&Instrumenten (C&I)en SysteemManagement & Support (SMS). Begin 1989 vonden daarover gesprekken plaats tussen Directie, SMS, C&I en de groep 2.6. Nu hadden C&I en SMS noch capaciteit, noch affiniteit om service te verlenen op systemen waarover geen kennis beschikbaar was en die (nog) slecht beheersbaar ingericht waren. Zo werd er geconstateerd dat beide PC servers totaal anders ingericht waren qua diskindeling, locatie van softwarepakketten en dergelijke waardoor het verlenen van service en ondersteuning moeizaam zou zijn. Uiteindelijk werd medio 1989 de knoop doorgehakt: SMS nam het beheer van de Novell servers, ‘het PCLAN’, onder condities over.

Het uitgebreide ISO/OSI model

Het achterliggende idee hiervoor was qua concept al eerder bedacht tijdens een afstudeerproject waarin het ISO/OSI Basic Reference Model voor communicatie bestudeerd werd. Het betrof het idee van Luiijf en Overbeek, dat ook binnen besturingssystemen de zeven lagen van het model te onderscheiden zijn en dat het in principe niet uitmaakt of nu een netwerk aangestuurd wordt of bijvoorbeeld een door twee systemen gedeelde schijf of ander geheugen voor gegevenstransport. Deze gedachte -feitelijk het schrappen van één regel tekst ‘dit is alleen voor telecommunicatie‘ in de OSI standaard- leverde nieuwe ideeën op met betrekking tot mogelijke toepassingen. Het achterliggende model werd zowel op de Control Data ECODU- en VIM-conferenties, tijdens het nationale SURFnet-congres, en tijdens de Digital DECUS-conferentie begin 1989 gepubliceerd en gepropageerd.

FEL-TNO’s Uniform ISO/OSI BRM: wat doen daar jullie in Den Haag?

Het concretiseren van de ideeën achter het door “Uniform Open Systems Model” gaf soms aanleiding tot langdurige uitleg aan supportmedewerkers van computerleveranciers. Verliep het oplossen van de bovengenoemde dubbele gateway problemen bij zowel DEC als CDC soms moeizamer dan verwacht, nog moeizamer was het een CDC-medewerker over te halen tot het opsturen van een correctie in het ftp-daemon programma op de CYBER onder NOS/VE. Wij hadden uitgevonden, dat het mogelijk was om vanaf een PC, met behulp van DEC’s Pathworks-software, een bestand via het DECnet te kopiëren naar de magneetbandbestand op het NOS/VE-systeem. Door in de “prolog” van de gebruiker de bestandsnaam “tape” te koppelen aan een magneetbandaanvraag werd tijdens de ftp “put”-opdracht een magneetbandaanvraag geeffectueerd en werd de aangeboden data op de magneetband geschreven. In plaats van een “close”-opdracht gebruikte het ftp-programma echter een “close-unload” waardoor de magneetband na iedere ‘put’ teruggespoeld en ontladen werd in plaats van aan het einde van de interactieve ftp-sessie. Omdat gebruikers in de ftp-sessie meer PC-files van de PC op magneetband wilden kunnen archiveren zonder dat de operators steeds weer een paar knoppen op de magneetbandeenheid moesten indrukken, moest dus de NOS/VE systeemsoftware aangepast worden.
Waarschijnlijk is FEL-TNO daarmee de enige plaats ter wereld geweest waar ooit een 200 ips, 6250 bpi tape-unit feitelijk rechtstreeks (via een netwerk, twee gateways en DEC Pathworks) vanuit een PC aangestuurd werd. Het werkte echter tot volle tevredenheid van de FEL-TNO computergebruikers, die anders handmatig zo’n dertig opdrachten per weg te schrijven bestand op drie verschillende systemen hadden moeten uitvoeren.
 

Arpanet

FEL-TNO ging rond 1985 uitmaken van een van selectief gezelschap aan international defensieresearchinstituten die, gesponsord door (D)ARPA, toegang kregen tot het ARPANET, dat in de jaren ’90 het Internet zou worden. De International Collaboration Board (ICB) bestond onder andere uit het RSRE (later DRA) en University College London (UCL) in het VK, Shape Technical Centre (STC) en later TNO in Den Haag, defensieresearch in Duitsland (nu Fraunhofer in Wachtberg), Italië, Noorwegen en Denemarken. De ICB stond onder voorzitterschap van Prof. Peter T. Kirstein (UCL). De ICB besprak de gezamenlijke infrastructuur, de planning van gelijktijdige upgrades van de BBN Butterfly ‘routers’. Later kwamen daar gezamenlijke proeven bij van de eerste voice-over-IP pogingen, netwerkbeveiligingsdiscussies, Internet-protocolontwikkelingen en performancemetingen tussen de verschillende instellingen. TNO ontving voor dit werk een B-klasse adres.
De ICB was tot opheffing rond midden jaren ’90 ook de domeinverantwoordelijke voor het .INT domein. Pogingen om de EU in internet te interesseren en hun eu.int te geven mislukten. NAVO bleef met nato.int de enige .int gebruiker.
Ten tijde van de eerste golfoorlog werd op een vrijdagmiddag geconstateerd dat steeds meer systemen onder navo.int niet meer bereikbaar waren. Pas na enige tijd werd duidelijk dat bij STC een SUN werkstation uitgefaseerd was die de primaire DNS verantwoordelijke was voor nato.int zonder dat iemand nagedacht had over de mogelijke consequenties. De secundaire DNS-server stond bij DRA in Malvern, VK. Omdat die server al lange tijd niets meer van de primaire server gehoord had, werden de adres-entries gedropt. Met eerst heel veel internationaal gepuzzel en daarna kunst en vliegwerk gedurende een weekeinde konden de nato.int diensten weer bereikbaar worden gemaakt.
Meer over deze Internetpionierstijd is te vinden in een Interview over de ontwikkeling van internet in Nederland geschreven Peter Olsthoorn.