The Control Data CYBER 170-835
Benchmark “en Français”: pupitreur and pi
In October 1981, Control Data announced a new line of systems, the CYBER 170-800 series at the Control Data VIM/ECODU ‘world conference’ in Minneapolis. The first two computer models were the 825 and the 855. The Physics Laboratory TNO was looking for a model that had the performance (and costs) that should be positioned between those two systems. The reason was a very high load on the CYBER 74: A CPU load of 100% during daytime and an average load of 75-85% in the evenings and weekends while processing 500 batch jobs and 350 terminal sessions per day. In peak hours, 50 terminal sessions were active in parallel. Per month, the Cyber 74 system processed 200.000 operating system commands as part of batch jobs and 450.000 commands initiated from terminals.
A new replacement system for the CYBER 74 should have at least 256 MB SecDed memory (single error correction and double error detection) and more and faster I/O channels to take advantage of new, faster types of disk storage units with higher I/O bandwidth. When the source code for a new level of the operating system arrived we deducted from comments in the PP-code for “bootstrapping” the system, that Control Data was working on a new system with the code name S2. As that was a number between the S3 (CYBER 855) and the S1 (CYBER 825), we had reasons enough to ask for more details under non-disclosure.
In May 1982, it was agreed that we could run benchmark tests on one of the first beta-test systems of the CYBER 170-835 (“Early Bird program”), which was installed at Aérospatiale in Toulouse, in France. We went there with two sets of four magnetic tapes with all the test jobs and data sets. One set of tapes was in our suitcases that took a touristic route when we changed planes in Paris. The suitcases were delivered to the hotel a day later on Saturday evening. The other set of tapes was in our carry-on luggage. The tapes had to be screened by X-raying in a magnetic unsafe system. After arriving in Toulouse there were reasons enough to verify very quickly whether the four X-rayed magnetic tapes could be read without errors. Fortunately, that was the case.
On Saturday and Sunday, the Cyber 170-835 was fully tested at the impressive data centre of Aerospatiale. Apart from a French CDC employee and the Dutch delegation, no one else was present. Four large mainframes, many rows of disk units and a large number of printers and card readers were installed in a room separated from an aircraft production hall. The NOS/BE system was heavily modified by the French. We all did, but they had gone much further. All (error) messages on the console, compiler output and so on were spat out in French. Fortunately, our French colleagues were less good at understanding how the complex code worked that parsed command input at the console. As a result, we still could control the system in a normal fashion.
The French engineer hardly spoke English and his French verbiage could only be delayed for a few moments. Because the existing new systems (835, 855), disk units (844, 885) and printers (e.g., 580) seemed very similar in terms of French numbering. It was always a problem to decode huit cent et quatre vingt cinq and so on to a drive. Or was he discussing the mainframe system that ran so smoothly?
Even worse, in every other sentence he mentioned “pupitreur”, a term which we could not find in our French-Dutch dictionary. Only after two days, we could trace back the term to “pupitre” (lectern). Only then it became clear to us that the good man was trying to explain a few things about the system operators.
Our benchmark consisted of twelve sample jobs that represented the heavy I/O- and CPU work at our Laboratory and for our Defence customers. Apart from that, we had a set of artificial system test programs that belong to the NLR. These jobs measured the system throughput of a representative batch of jobs. This set was tuned to be a reflection of our specific operational environment on the CYBER 74.
During the benchmark at the CYBER 170-835 in Toulouse, we found an error in the systems’ microcode. A Pascal program generated an “error mode 4”: division by zero. Debugging the code, while other CPU-intensive benchmark jobs ran at the system, we figured out that the constant pi (¶) was calculated by calculating arctan(0)/4. The way “old” CYBER’s rounded divisions by zero (RXi Xj/Xk) differed from the way the microcode of the new CYBER 170-835 worked. To be able to continue the benchmark, pi was manually equated to 3.14 in the hope that the final results would be a little influenced, which later turned out to be correct.
The final report of this benchmark and the proposal to install a CYBER 170-835 was presented to the Computer Committee of TNO Defence Research (CCHDO) and the Coordination Commission Computer Facilities TNO (CCA). On 7 April 1983, a lease contract for a CYBER 170-835 was signed.
CYBER 170-835 Hardware
The CYBER 170-835 CPU had a 56 nanoseconds major clock cycle and a cache memory of 2 KByte. The memory consisted of 16 K DRAM memory chips with SecDed protection. The memory had an effective word size of 64 bits (actually 72 bits due to SECDED). The system was water-cooled, used 65 KW/h and needed (only) 2.5 hours of preventive hardware maintenance per month, a significant improvement over the four times three hours of preventive maintenance.
The architecture was particular. The hardware supported an extensive 64-bits instruction set that worked with virtual memory. It supported the emulation of up to 16 different microcodes in one single system. One of these emulations was the support for the old CYBER 60-bit instruction set and fixed memory addressing in the lowest memory part. The old operating systems NOS and NOS/BE used this absolute memory.
The 20 peripheral processors worked in four rings of 5 PPs, each ring having a clock speed of 250 nsec (major cycle). The “native” PPs used 16 K words by 16 bits of memory.
The architecture of the S2 machine was special. The hardware was based on an extensive 64-bit instruction set working with virtual, paginated memory and could emulate up to 16 microcodes in one system. One of those microcode systems supported an emulation of the ‘old’ CYBER emulation with the 60-bit instruction set. Because the old Cyber operating systems NOS and NOS/BE assumed an absolute memory, the emulated operating systems used the lower (fixed) part of the memory of the machine.
The 20 peripheral processors worked in four rings of five PPs with a clock speed of 250 nanoseconds (major cycle). The ‘native’ PPs had 16K 16-bit words.
Installation and configuration
On September 1, 1983, the CYBER 74 was dismantled. Several cables from the so-called “Christmas tree”, the interconnections between the four system bays, were cut with a cable cutter. Within half an hour it was known throughout the Laboratory that the system parts, 1700 kg per bay, would be moved to the scrap presses of Pametex. Soon, a helping hand was given by laboratory technicians who privately could use many meters of the special twisted wires that connected the CPU parts. Others brought screwdrivers and collected modules as these were a “technician’s delight” regarding packaging. For the Labs’ history, some memory blocks and hardware logic modules were saved.
After modifications to and isolation of the water cooling system, the CYBER 170-835 mainframe was rolled in. The installation and the acceptance tests went so smoothly that the system could be taken into production on September 5, a day earlier than planned. The disk configuration was now expanded to four 844-41 disk units and four 885 disk units with two head disk assemblies (HDA) of 692 Mbytes each. Each of the twelve disk units was accessible from two sides as we installed three disk control units. The PPs of the system were so fast that it was possible to switch from twofold interlaced to full-tracking operations. In the case of the twofold interlaced operation, a block of information was written on the disk, a block was skipped, and the next block was written. This left sufficient time for the controller and the PP to prepare the next block of data to be written while the ‘skipped’ block rotated under the writing and reading head. This made it less likely that the data was not ready and that a complete disk revolution of 18.3 ms had to take place before the next block could be written. Full tracking meant that successive blocks could be read or written, thus achieving a much better disk performance.
Two new magnetic tape drives were installed. These could only read the ‘old’ 800 bits per inch (bpi) tapes but could read and write 1600 bpi and new at that time 6250 bpi magnetic tapes. The latter gave a large capacity increase, especially for writing backup dump tapes. The speed of the tape unit was 200 inches per second (ips), which was an improvement over the old 150 ips units. The only drawback was that the new units no longer allowed manual intervention because the airflow that kept the magnetic tapes tensioned during the stopping or accelerating of the reels was then disrupted. As our customers were sometimes very ‘inventive’ with magnetic tapes, reading certain measurements recorded on tape required all the tricks available to the system operator. Challenging were the magnetic tape recording made aboard submarines of the Royal Netherlands Navy. Unfamiliar with computers, the conscripts did a fast forward of a couple of meters and added a ‘blinker’. A blinker was an aluminium strip that was glued on magnetic tape to indicate the beginning of the data storage structure or the end of a tape. The piece before the first blinker was the ‘leader’, a couple of metres of tape that was used to load the magnetic tape on a tape reader.
The blinker reflected light which was detected by a light detector. At the Navy, however, they added a blinker at the start of each new series of measurements to save spillage of magnetic tape.
In 1990 we received paper tapes that were coiled in ‘eights’ by a sailor from the Royal Netherlands Navy as if it was an anchor rope!
The 512 MB memory of the CYBER 170-835 was split into two: NOS/BE that used the first 256 MB directly and 256 MB was set aside as UEM (extended) memory.
Batch jobs now could use 200,000B words maximum and during the non-office hours and weekends 377000B words (492 KB resp. 980 KB). We changed the operating system in such a way that running jobs did not abort when the job memory limit was decreased in the morning. For interactive work, the memory limit was set to 100,000B words (246 KB). During office hours, an interactive user was only allowed 15 seconds of CPU time per interactive step; batch users were allowed 8 minutes of CPU time at maximum.
ACCU and ENR are in trouble by a TNO-worm
During the installation of the system, we still had to solve a problem at the computer centre of Utrecht University (ACCU). We were the first in the Netherlands with magnetic tape units that could handle 6250 bpi. During the backup (DUMPF) of files, a file description block (in Unix terms: inode table) was put on magnetic tape indicating the density of the magnetic backup tape. The new software version used by TNO had the bit “6250 bpi” at a location that had the meaning of a non-erasable and unrecoverable system file at earlier versions of the operating system.
During the period TNO had no computer service due to the replacement of systems, one of the computer users had dumped all his files on a DUMPF tape and wanted to use the ACCU computer services. After his files were loaded (LOADPF), the files could neither be backed-up nor could not be removed from the system. Because the colleagues did not have the new version of the operating system yet, they did not understand it! Telephone consultation followed. After fifteen minutes of deep thinking, the TNO system programmers came up with a solution to remove the files. The solution did require the necessary ‘patchwork’ in the system memory, basically ‘hacking’ the ACCU system remotely using a human on the telephone.
Another computer user went for computer services at the computer centre of the Energy Centre Netherlands (ECN/ENR). He also had a BACKPF tape with him but had not loaded his files yet. Because we knew the problem, spreading a second ‘worm’ could be prevented by creating a dummy file and then using the LOADPF Replace function.
In 1984, as the CYBER facilities of the Laboratory increasingly attracted external paying users, we had to change the pro forma account card content. Another reason was the management requirement to get more insight into the use of the CYBER for projects.
Based on the project and institute number, a simple secret number in the ACCOUNT card replaced the institute number for the Physics Laboratory users. The algorithm for calculating this number was: ((X2+42) modulo 89 + 10). The offset of ten caused a number range between ten and 99, a two-digit number. This simplified the assembler code for decoding the ACCOUNT card program a lot. The magic number “42” was invented by lazy Systems Programming people. As they figured out that they did not want to change the old ACCOUNT cards in all their jobs, they used 42 to cause the verification number of their project number to become equal to the former Physisch Laboratorium’s institute number “51”. Designers have that advantage, isn’t it? (by the way, the number 51 was dragged along already for over ten years as that was the institute’s number invented by IWIS-TNO).
Based on the earlier described “fast I/O”-module, each active project number was indicated by a bit in a project database. The ACCOUNT program read this database file and verified the status of the project by looking at the bit value indicating whether the project was active or not.
Computer graphics: Preview and Plotlib
The basic Calcomp plot library that was used at the Laboratory was in use since the days of the Control Data 3200 system. Much effort was required to keep the library working with Fortran 5 and the loader preset of unused memory. As we moved away from the data conversion station and went to use a Calcomp 1051 plotter controlled by a Calcomp 906 controller, the basic plot library had to be updated. The basic Calcomp library comprised some simple routines for pen selection, pen up/down and the drawing of a line and an axis. This library drove the plotter. On top of this library, another Calcomp-library with ‘top-level’ routines was available for drawing, for instance, logarithmic axes.
A project team was formed to supply the users with much more user-friendly plot facilities. New routines were designed to allow the assignment of colours and different line thicknesses to certain pens (formerly colours were mapped to pre-arranged physical pens), now one could choose between ballpoint and ink, normal paper and vellum. Scaling and clipping were other new functions that were offered.
The main design problem for the new library was to keep long-time ago developed programs running. The changes had to be minimal for the user. At the same time, the new plot library had to support programs written in the 1966 and 1977 versions of Fortran.
In 1984, performance measurements of the CYBER 170-835 showed:
- 34 interactive commands per minute.
- 40 I/O calls per second.
- 107 disk accesses per second.
- 162 interactive swaps per minute (the number of times the “Enter” was hit per minute by interactive users).
- 150 PP-programs loaded per second of which only five per second were loaded from disk. As compared to the CYBER 74 system, the number of program swaps to disk had decreased by a factor of 100.
At the beginning of 1986, 71 users of the 350 registered users were interactive busy at the same time on the Cyber system. Some 150 users were regularly active on the other central systems (DEC, PDP).
In one year, 2,500,000 sheets of computer paper were printed, a 38 cm wide path from The Hague to far beyond Paris. Operations managed (backup) about 10,000 active and 50,000 inactive files as well as 2,500 magnetic tapes.
Dual-state use with NOS/VE
In mid-1985, TNO FEL decided to explore the new virtual operating system NOS/VE (Network Operating System/Virtual Environment).
NOS/VE was an operating system based on virtual memory techniques. The virtual concept was extended to each file being accessed in a ‘virtual’ manner. The basis for NOS/VE was a joint effort by NCR and Control Data (CDC). NCR withdraw halfway as their focus shifted to other markets. NOS/VE was developed in Pascal 1 – which later became CYBIL (CYBER Implementation Language) – a systems programming derivative of Pascal.
In August 1985, NOS/VE was installed on the CYBER 170-835. Finally, we started to use the ‘native’ part of the CYBER hardware instruction set. The Laboratory was one of the first computer centres in the world to use the combination NOS/BE – NOS/VE (dual-state) in an operational system. During installation, we again stumbled into the well-known (earlier described) 63-character set problem. At the same time, NOS/VE generated ‘standard’ job names, which started with a ‘Z’. Those job names conflicted with our security enhancements to NOS/BE. Therefore, the NOS/BE-side of the dual-state interface software required a large number of adaptations and changes. As NOS/VE was delivered as binary executable code, most errors could not be patched and corrected by ourselves. The number of problem status reports (PSRs) submitted by the Laboratory increased fast.
Although we started with an operational trial period, our initial NOS/VE users required plot services on the Calcomp 1051 plotter. The Calcomp plot library resulted in very low-level control code for the plotter and was generated by a complex lower layer of software in Assembler and 60-bit word packing. Conversion to NOS/VE looked hardly doable. An idea came up as the dual-state software could start a batch job under NOS/BE, a so-called Interstate job (that ran through the multi-user feature of NOS/BE). Those jobs ran at a very high priority even delaying NOS/BE interactive users. The best ideas are born at moments of unconscious thinking. During a weekend, a simple but effective design was made: “Do not convert the basic plot library to NOS/VE at all, but just record the parameters of the calls to the basic plot library routines!” Covering the whole base set of plot instructions required only a couple of hundred lines of Fortran code. For each Fortran routine of the basic plot library, we developed a subroutine that just wrote the routine number followed by an ASCII representation of all the parameters of the subroutine call into an ASCII file. The plot close (PLTCLOSE) call added a couple of NOS/BE commands to the file and fired up the file as a batch job under NOS/BE. Under NOS/BE we wrote a simple case-driven routine. It read the ASCII file and called the real plot routines from the old Calcomp library. This solution was so simple, that the programs were written and tested in less than one day! Later some more about this ‘interpreter’.
The system software under NOS/VE
Under NOS/BE, the following system software was made available to the users:
- the editors: SUEDI and SUEDA;
- the text scanners: IDAF and SCAN;
- the text formatting program TOI5 (HTML-like macro-processor for text processing);
- the Fortran compilers and pre-processors: FTN4, F45, FTN5 (1977-standard) and FTS (Fortran structured);
- the compilers Pascal2 (until mid-1984), Pascal3, Cobol5, Compass (assembler), Basic and Algol 5;
- the source code maintenance package UPDATE;
- the packages PERT/TIME, APEX3, MPOS, SPSS, DYNAMO, BLUEPACK and INFOL;
- the libraries IMSL (mathematical libraries), CERNlib, PLTNlib (own utilities), ACCUlib, PLOTlib and PLOT 10/TCSlib (Tektronix terminal control system);
- an own developed tool to provide the users with information and help: APMED;
- the terminal screen pointer manipulation package;
- the FILMAN file manipulator (from the end of 1982)
Under NOS/VE the following software was available for the users in August 1985:
- the compilers: FTN/VE en CYBIL/VE;
- the programming environment PE;
- the UNIX-emulation environment: VX/VE (2/1987);
- the graphical packages: GKS (2/1987) and the Tektronix PLOT 10/TCS library converted to a NOS/VE library;
- the IMSL library: IMSL/VE.
- We converted the NOS/BE packages TOI and TCS ourselves.
Unplanned visits by the Firefighting department
During this period, the Laboratory built a strong relationship with the local firefighting department. The new machines sometimes required hardware updates of a printed circuit board. CDC technicians let the soldering iron smoke well, which resulted in a visit from the municipal fire-fighters department because the fire alarm of the computer room was activated. A set of firefighters fully equipped with oxygen masks, axes and other gear entering the computer room …