[TNO-logo]
Museum logo

The period 1986 - 1990
Datacommunication and the PC local area network

On June 28, 1988, the System Management and Support (SMS) group formally introduced the users the possibilities of the Novell-systems by means of a colloquium. 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 only exception were the Novell PC servers. This was remarkable as the FELLAN was initially meant to support PC file services first!

Double gateways: DECnet - TCP/IP - XNS

Just a little earlier, in May 1988, the Laboratory installed a CDC Network Device Interface (NDI) as well as a DEC micro VAX2000 running under the Ultrix operating system (an UNIX derivative). This NDI can be found as not yet installed Gateway device interface (GDI) on the FELLAN configuration schematic per March 1988.
The first one "talked and understood" with the XNS (CDCnet) and TCP/IP, the latter with DECnet and TCP/IP. These gateways were bought in order to allow communication on the one hand between the VAXes and graphical systems based on SUNs (UNIX; TCP/IP), and on the other hand exchanging the CYBER information with the same SUN systems.

SMS designed a much more inventive application: the usage by all systems of the fast, 2000 lines/minute central CDC 585 printer. The transfer using two gateways in a row of print files from DECnet (VAXes under VAX/VMS and PDP11's under RSX) used the protocol sequence DECnet - TCP/IP - XNS - NOS/VE - y. This required an 'on-the-border' use of all the possibilities that the systems involved offered. At the VAX/VMS systems, a special way op the COPY-command was used to copy the print-files by the way of DECnet to the Ultrix-gateway system. The Ultrix gateway in its term determined what files were meant to be forwarded to a "UNIX"-like system (which actually meant a TCP/IP based system) and copied the file using a FTP-put command to the "UNIX"-system. The FTP-command was interpreted by the CYBER NOS/VE operating system as a ftp batch job.

The NOS/VE operating system featured an interesting option for users of the system. It supported the so-called login- and logout-profiles ("prolog" and "epilog"), which were sets of commands that were invoked at the start or end of the job respectively. Different prologs and epilogs were invoked depending upon the job phase: system prolog, accounting prolog, job-class prolog, user prolog. In reverse sequence, the system invoked the epilog. By putting the print files in a special files-to-be-printed directory (catalog), the logout-profile ("epilog") of the ftp batch job invoked procedures that forwarded the received file(s) to the appropriate output queue with the right parameters. The filename used in the ftp transfer contained, in a coded form, the user name, the forms code and the output file name. These were then 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 transfered to non-DEC TCP/IP implementations. Dollar-signs were removed from the filename as well as Carriage Returns and LineFeeds were removed from the byte stream ("stream-mode"). A couple of patches solved these non-transparent gateway problems. Many of our international collegues 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. A double-gateway solution was a very high class one! Those 'guys' in The Hague used only one cost effective system for controlling all the expensive and human intensive I/O-equipment (plotter and printers) by using one double-gateway in between.

The expanded ISO/OSI model

The idea behind these inventive solutions came from the concept that we developed when a student was working on his final papers at the Laboratory. He studied the ISO/OSI-communication model bestudeerd. 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 lead to many new ways of playing around in a seamless environment where most collegues just invented the first ways to communicate using an Ethernet. This concept was presented both at Control Data ECODU and VIM user conferences, during a SURFnet congres and during the Digital DECUS-conference in the beginning of 1989.

What are you doing there in The Hague?

One practical example of our "Uniform Open Systems Model" required a long telephone call 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-systeem. In the "prolog" of the user, 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, the ftp-program used a "close-unload". After each "put", 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 hudge 200 ips, 6250 bpi tape unit was driven almost directly from a PC using a network, two gateways, and Pathworks. After receiving a patch for the required corrections, many PC users at the Laboratory had their PC measurement data automatically back-up. Otherwise thirty commands had been necessary at three different systems to have the same result.

PCLAN

In 1987 and 1988, group 2.6 (System engineering) bought two (then "heavy" and expensive) Compaq 386 PC's that were running Novell server software. End of 1988, this group regarded the daily maintenance tasks cumbersome. They tried to dump these tasks to the computer infrastructure management and support groups C&I and SMS. These refused as the knowledge about the software, documentation, education and procedures were lacking. In the beginning of 1989, the management of the Laboratory tried to resolve the situation. One investigation showed that both servers had another 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".



Museum logo