Data communication (1986 – 1989)
Double gateways: DECnet – TCP/IP – XNS
In May 1988, the laboratory installed both a CDC Network Device Interface (NDI) and a DEC micro VAX2000 under Ultrix (Unix variant). This NDI is listed as Gateway DI or GDI on the FELLAN configuration scheme below. The NDI “spoke” both XNS at the CDCnet side and TCP/IP; the VAX2000 both DECnet and TCP/IP. These gateways were purchased to enable both the VAXes and the CYBER to communicate with the graphical systems based on SUN systems.
The group System Management and Support developed a much more inventive application of the two gateways: the access of all systems to the fast, 2000 lines/minute, central CDC 585 line printer. The transfer used the sequence of two gateways (DECnet – TCP/IP – XNS – NOS/VE) to move the print files from DECnet (VAXes under VAX/VMS and PDP11’s under RSX) to the printer.
At the DEC systems, a (network) COPY-command was used to copy the print-files via DECnet to the Ultrix-gateway system. Using the TCP/IP address of CDCnet, the MicroVAX 2000 discovered that the file was meant for another UNIX-like system and copied the file via an FTP command to that UNIX system (at the Cyber side). The FTP command was subsequently processed at the CYBER NOS/VE side as an ftp batch job. At that side we used an interesting operating system option to accomplish what we intended to do: login and logout profiles (“prolog” and “epilog”). Prologs and epilogs allowed a number of commands to be executed at the beginning and the end of a job respectively. This process also worked for received ftp jobs. By placing a file to be printed a special “catalog”, the procedures invoked by the logout profile (“epilog”) transferred the uploaded files to the correct print output queue. The username (for the print banner page), the paper type code (with lines or blanc) and the output filenames were encoded in the filename transmitted by the DEC system. These parameters were decoded by the NOS/VE SCL-procedures.
The largest problem to get this all working was caused by the Ultrix-implementation. This system was not completely transparent for data being transferred to non-DEC TCP/IP implementations. Dollar-signs were removed from the filename. Moreover, Carriage Returns and LineFeeds were removed from the byte stream (“stream-mode”). A couple of special patches by DEC solved these non-transparent gateway problems. Many of our international colleagues regarded our network solution as a very innovative solution. A single gateway was for many of them a large step into the direction of seamless integration of systems. A double-gateway solution was a very high-class one! Those ‘guys’ in The Hague used only one main system to monitor and control all the expensive and human intensive I/O-equipment (plotter and printers) by means of a double gateway.
In 1987 and 1988, group 2.6 (System Engineering) bought two (then “powerful” and expensive) Compaq 386 PC’s that were running Novell server software. On June 28, 1988, the laboratory users of the computer services were introduced to the possibilities of the Novell-systems. The services that the Novell network the users offered were discussed and demonstrated: file access, remote file access, remote login and remote resources were reviewed. In the presentation, it was shown that all systems, connected to the FELLAN, could exchange files by way of the FELLAN with other operating systems (NOS/BE, NOS/VE, VAX/VMS, RSX). The two Novell PC servers were the only exception. This was remarkable as the FELLAN was initially meant to support PC file services first!
End of 1988, the System Engineering group regarded the daily maintenance tasks cumbersome. They tried to dump these tasks to the computer infrastructure management and support groups Computers&Instruments, and System Management&Support. These refused as the knowledge about the software, documentation, education and procedures were lacking. At the beginning of 1989, the management of the Laboratory tried to resolve the situation. One investigation showed that both servers had different disk partitioning, standard utilities and applications were installed at other locations and so on. Management of the system would require a lot of resources. Finally, in the mid of 1989, SMS reluctantly took the responsibility for the Novell servers, “the PCLAN”.
The expanded ISO/OSI model
The idea behind the inventive double gateway solution described above came from the concept that we developed when a student was working on his master’s study at the Laboratory. He studied the ISO/OSI-communication model. We developed the idea that the model should not be used exclusively for describing layered communication protocols. Instead, the same layers could be found in operating systems. In principle, it should not matter whether data is communicated across a network, whether data is shared between two systems using a shared disk or that a magnetic tape is used to move data from one system to another. This conceptual idea led to many new playful services in a seamless environment where most colleagues just invented the first ways to communicate using a local area network based on Ethernet. This state-of-mind concept was presented both at Control Data ECODU and VIM user conferences, during a SURFnet congress and during the Digital DECUS-conference at the beginning of 1989.
What are you doing in The Hague?
Playing with our “FEL-TNO Uniform Open Systems Model” required long telephone calls with the support desks of various computer vendors. Took the solution to our double gateway problems long to solve, it took much more effort to convince the CDC software support desk to correct the ftp-daemon under NOS/VE. Using DEC’s Pathworks-software and the double-gateway, we intended to copy on a PC file by means of DECnet, to a file called “TAPE” on the NOS/VE-system. In the “user prolog”, TAPE was coupled to a REQUEST_MAGNETIC_TAPE command for a specific magnetic tape. As soon as the FTP (file transfer) “put”-command came along, a request for the magnetic tape was issued on the console. Rather than a “close”-command at the end of the program, the ftp-program used a “close-unload”. After each “put” -appending a data file at the end of the tape- the tape was rewound and unloaded. This required a lot of manual intervention by operators. We intended to use this feature to archive a number of data files on the PC in an automatic way.
Probably, the Laboratory was the only place in the world where a huge 200 ips, 6250 bpi tape unit was driven almost directly from a PC using a network, two gateways, and DEC Pathworks. After receiving a patch for the required corrections, many PC users at the Laboratory had their PC measurement data automatically backup. Otherwise, thirty commands had been necessary at three different systems to obtain the same result.
FEL-TNO became around 1985 member of a selective group of international defence research institutes which, sponsored by (D)ARPA, gained access to the ARPANET. The Arpanet became the Internet in the 1990s. The International Collaboration Board (ICB) consisted of the RSRE (later DRA) and University College London (UCL) in the UK, Shape Technical Center (STC) and later TNO in The Hague, defence research in Germany (now Fraunhofer in Wachtberg), Italy, Norway and Denmark. The ICB was chaired by Prof. dr. Peter T. Kirstein (UCL). The ICB discussed the joint infrastructure, the planning of simultaneous upgrades of the BBN Butterfly ‘routers’. Later there were joint tests of the first voice-over-IP attempts, network security discussions, Internet protocol developments and performance measurements between the various institutions. TNO received a B-class address for this work.
The ICB was also the domain responsible for the .INT domain until the mid-90’s. Attempts to interest the EU in the Internet and provide them eu.int failed. NATO remained the only .int user with nato.int.
On a Friday afternoon during the first Gulf War, NATO observed that increasingly fewer computer systems could be reached under navo.int. It took a while before it became clear that a SUN workstation had been phased out at STC. That system, however, was the primary DNS server for nato.int. Nobody had thought about the possible consequences when decommissioning the system. The secondary DNS server was at DRA in Malvern, UK. Because that server had not heard from the primary server for a long time, DNS entries were dropped one by one. With first a lot of international puzzling and then fiddling during a weekend, a new primary nato.int DNS service was configured.