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 585printer. 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 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".