The requirements for the replacement system of the CYBER 74 were 256 MB SecDed (single error correction and double error detection) memory at a minimum and more and faster I/O-channels in order to take advantage of new and faster disk units with higher I/O transfer speeds. When the new level source code arrived we found in some comment lines in the PP-code for "bootstrapping" the system, that Control Data worked 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 details under non-disclosure conditions.
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"), that was installed at Aerospatiale in Toulouse, in France. We went there with two sets of four magnetic tapes with all the sample jobs and required data on it. One set of the tapes was in our luggage, that took a touristic route for a day when we had to change planes in Paris. The other set of tapes was in our carry-on luggage, but the French security police at the Charles de Gaulle airport insisted in X-raying the tapes in a non-magnetic safe system. On arrival in Toulouse and finding that our back-up tape set was missing, our priority one was to verify whether the tapes could be read at all. Fortunately that was the case.
On Saturday and Sunday, we were allowed to make use of the CYBER 170-835 system which was installed in the for us impressive computer center of Aerospatiale. Apart from the French CDC engineer that supported us, nobody else was around in that center. Four large mainframes, many rows of disk units and a large number of printers and card readers were installed in a room that was part of an airplane construction building. The NOS/BE system was heavily modified by the French. We all did, but they had gone much further. All (error) messsages on the console, compiler output and so on were replaced by their French equivalent. Fortunately, our French colleagues were less good in understanding how the complex code worked that parsed the command input at the console, thus the input was (fortunately) still in English. This allowed us to operate the system in a normal fashion.
Operator console Cyber 170 series (Photo courtesy Fredy Ferrari, Fides, CH)
The French engineer hardly spoke English. Moreover, it lasted only a couple of sentences after asking to speak a little slower before he picked up speed again and flushed us with a stream of French words. They had new computer systems (835, 855), disk units (844, 885) and printers (e.g., 580). In French, the (for us) complex way of counting required a lot of decryption processing. Especially when numbers are close (cinq cent quatre-vingt cinq) and all had eigths and five in them. Did he talk about a disk unit or was it a mainframe that worked quit well? Even worse, he mentioned many times the word "pupitreur", a term which we could not find in our French-Dutch dictionary. It took us two days before we finally figured out that he had talked about operators. "Pupitre" turned out to be a word for "desk".....
Our benchmark consisted of twelve sample jobs that represented the heavy I/O- and CPU-work at our Laboratory and for our Defense 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". 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 the result of a divide by zero (RXi Xj/Xk) differed from the way microcode at the new CYBER 170-835 worked. Just to get any results for the jobs, we did not require 100% accuracy of the job results, we changed the program and set pi equal to 3.14.
The results of the benchmarks, which comprised different I/O and PP-configurations, and included some simulated predictions, was an advice to install a CYBER 170-835. On April 7, 1983, the rental agreement for a CYBER 170-835 was signed.
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-bits 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 PP’s, each ring having a clock speed of 250 nsec (major cycle). The "native" PP’s used 16 Kwords by 16 bits of memory.
After modifications to and isolation of the pipes of the water cooling system, the CYBER 170-835 bays were moved in. Installation and acceptatance testing were carefully planned. The whole operation went very smoothly, that the CYBER went into operation one day ahead of schedule.
The disk configuration was extended to four 844-41 disk units and four 885 disk units with two HDA’s each. A HDA contained 692 Mbyte. (885 units are visible at the left of the picture). To distribute the load and to increase availability, the twelve disk packs were controlled by three disk controllers; each disk packs was accessed by two different controllers. The PP’s were fast enough to change from 2-fold interlaced (consecutive information blocks are written onto alternate disk blocks, which gave the disk controller/PP processing time enough to handle the information during the skipping of 'alternate' block and minimised the risk that a full disk revolution of 18.3 ms had to be waited for; this allowed for the highest throughput possible at that time) to full tracking (just consecutive disk blocks) which gave an impressive increase in 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) 6250 bpi tapes. The latter gave a large capacity increase, especially for backup dump tapes. The speed of the tape unit was 200 inch per second (ips), which was an improvement over the old '150 ips'. The only drawback was that the units had so many safety features that no manual tricks were feasable as the air loop pressure would drop (the air loops handled start/stop differences between the capstan and the reels). As our customers were sometimes very 'inventive' with magnetic tapes, certain measurements recorded on tape required all the tricks available to the operator, especially with recordings made by submarines of the Royal Netherlands Navy. Unaware of knowledge of computers, the conscripts did a fast forward of a couple of meters, added a 'blinker' (aluminium sticker on the tape that was spotted by a light as a reflective marker and that either indicated the beginning or the end of tape). Then he would start a new series of measurements. That saved 'magnetic tape'.
It should be remarked that our friends of the
Royal Netherlands Navy
were quit inventive with respect of handling computer materials.
In 1990, we received a papertape that was winded in the form of an eight, as if it
was the anchor chain!
The memory of the CYBER 170-835 was split into two: NOS/BE could use 256 MB directly and 256 MB was set aside as UEM (extended) memory.
Batch jobs now could use 200000B words maximum and during the non-offioe hours and weekends 377000B words (492 KB resp. 980 KB). We changed the system in such a way that jobs did not abort when the memory limit was decreased in the morning. For interactive work, the memory limit was set to 100000B woorden (246 KB). During office hours, an interactive user was only allowed 15 seconds CPU-time per interactive step; batch users were allowed 8 minutes of CPU-time at maximum.
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 of the ACCOUNT card program a lot. The magic number "42" was invented by the lazy Systems Programming people. As they figured out that they did not want to change the ACCOUNT cards in all their card jobs, they used 42 in order to cause the verification number of their project number to become equal to the former Physisch Laboratorium 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 institutes 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.
A project team was formed to supply the users with much more user friendly plot facilities. New routines were designed to allow the assigment of colors and different line thicknesses to certain pens (in the back, these were mapped to pre-arranged physical pens and color schemes), one could choose between ballpoint or ink, normal paper or 'velum'. Scaling and "clipping" were other new functions that were offered.
The main design problem 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 be used by the 1966 and 1977 versions of the Fortran languge.