Control Data 3170



My first computer. Control Data 3170. 64 K words of memory. A "word" of memory contained 24 bits of data and a parity bit (the 25.th). We did not have bytes at that time, each word was divided into 4 characters, containing 6 bits each. CPU cycle time 1,750 micro seconds, i.e. 0,57 MHz, with Floating point and enhanced BDP instruction set. Console display and typewriter. 7(+1 spare) 841 disks, each 32Mchars. Disks were removable. 2 x 604 tape transports (7 track, 200/556/800 bpi), later replaced with 659 tape transports (9 track 1600/6250 cpi). 405 punched card reader. 501 printer (800 lpm?), later replaced with a 512 printer (1200 lpm). Paper tape reader (RC) and punch (not used). 2550 communication unit (the yellow cabinet on the floor) for remote batch processing. Installed at Studentsamskipnaden in 1972, running administrative routines for the University bookshop, student lodging, internal accounting, payroll, etc. Job assignment: Systems Analyst. Mainly COBOL and FORTRAN applications. Data mostly stored in sequential (disk or tape) files, some index-sequential files, and one special random access database-file.
	The electronic circuit boards employes discrete components, i.e. transistors, resistors, capacitors, aso. The two left circuits were taken from the printer controller, the larger to the right comes from the disk controller and contains 6 IC (intergrated circuits) each with 8 pairs of legs.
	Each cabinet (behind the disk drives - see top picture) contains a core memory stack with neccessary control logic, each 16K words of memory. 1 word = 24 bits, 1 character = 6 bits. 16K words = 64K characters. 1qp = 512 words 1K words = 1024 words = 2qp The name "core memory" comes from the fact that the memory was built up by ferrite core rings. These were manually produced in the far East, were girls were sowing the core mats by hand.
	Detail of the above core stack. The ferrite core is clearly visible in the picture as small brown rings, each has 4 electric leads passing through the ring for storing and reading data. 1 ferrite core ring = 1 bit of data.
	Input to the computer was mostly thru usage of punched cards. A card has 80 columns, i.e. up to 80 characters could be punched on a card. Each column has 12 rows, the lower 10 are numbered 0 - 9. By punching different hole combinations, different characters could be represented. E.g. letter "D" has holes in rows top and 4.
	Output from the computer were mostly produced on paper. The printer was mechanical, either a drum printer (501), or a chain printer (512): a printer slug is pictured here. The whole character set was mounted on a chain of slugs, this chain quickly rotated in front of the paper while a row of hammers on the other side of the paper hit the correct character at the right time to produce printing on the paper. The 512 printer was able to print up to 1200 lines per minute.
	Other input and/or output media were magnetic tape. A full 2400 ft. tape could store up to 80 Mb data at 6250 cpi. Tape width is 1/2" = 12,7mm. The pictured tape is a high-quality 1200 ft. tape. The tapes were mostly used for backup purposes. Notice the yellow ring. This is the "write protect" ring, and was inserted on the back of the reel when the tape was rewritten. Removing the ring protected the tape from being (accidentally) over written. CDISK I wrote CDISK to copy an entire disk to tape, including a bootstrap loader program to reload the data to a (blank) disk. This was mainly used to provide a quick way to restore system production in case of a system disk crash.
	The magnetic tape reading / recording head. This is a 7 track tape head, 6 tracks of data and 1 track parity check. Data could be recorded in 200, 556, or 800 bpi. 9 track tapes succeeded, with much higher density (1600cpi or 6250cpi).
	Paper-tape was much less used as input (or output) medium. Mostly because it very easily got damaged. However, we did have a paper-tape reader (RC Danish make) and a standard CDC paper punch.
	The operating system was MASTER. Pictured here are the quick reference manuals of machine instruction codes (Assembly language COMPASS), and the job control language MASTER instant manual. `$JOB,account,jobname,minutes $SCHED,CORE=qpmemory,604=tapes,841=disks $*DEF(O,,LGO,owner,filename,ed) $XX,LGO ]]` (columns 1 and 2 with rows 7 and 8 holes punch) MASTER was multitasked and had virtual memory, but memory management was primitive. Entire programs (tasks) had to be swapped out to disk to free memory.
ECODU 19 Amsterdam MASTER integrity and security	This is a presentation given at ECODU 19 in Amsterdam. It was never published in the proceeding for security reasons. It is nearly 30 years ago this presentation was given, so the security risk today is about nil. Wonder if there are any MASTER systems still running? I take the chance now to publish it... It is interesting to note that the techniques described here are actually one of the first documented hacker attempts to break into a computer system: compromize system information. disturb production or... destroy the system and data. however, the purpose was to "wake up" the vendor to improve and secure system against abuse. ECODU = European COntrol Data User group. Used to have annual meetings at various places in Europe.
OLP	OLP overlay linking processor My first assignment at the Studentsamskipnaden was as a student summer job. They had problemtswith a FORTRAN program that was overflowing memory limit. This problem could be overcome by the OVERLAY technique, but this would require considerable reprogramming of the application. OVELAYs required that no modules in the overlay could be called from the main program area. You could only call the overlay. However, code in the overlay may call modules in the main area. The application required calls in both directions. OLP made use of OVERLAYs, but solved the linking of module calls from main to overlay at runtime. The solution patched all binaries, inserted a binary runtime linking module tailored at the application for maximum performance.
JOB composer	JOB Composer My last project at the Studentsamskipnaden. In an attempt to make a compact and efficient interactive batch system, I wrote the JOB Composer. It consumed 4qp (2K words) memory and was multi-threaded. The purpose was to replace the punched card, to be able to submit jobs and inspect job results. This experiment was carried out at the end of my carrier at Studentsamskipnaden, and was not pursued further as a product. However, the JOB Composer was actually used in Austria at the University in Wien with very good feedback. It was coded in assembly (COMPASS), but made use of pseudo-code to document and assist in coding. The pseudo-code looked much like SIMULA. It was interesting to see that during development and debugging, that functional errors discovered often were present in the pseudo-code aswell as the assembly code! Time moves on, everybody converted to CYBER* systems (or other vendors), were interactive systems were much better suited and implemented.*
Ref.manuals	Cobol manual Fortran manual Compass manual See also CD3000 document archieve.
CYBER many years later a Cyber emulator running on an ordinary PC brought back memories from the 1970 to the end of the Control Data era.	CDC CYBER computer systems installed at various places where I had several large and smaller projects and developments. NSB - system analyst: *GETVSN* a tape management system. NC - developing *COCO* Condeep Construction management and control batch system. NTH - system analyst running *PLATO* educational system. LFK, SELMER, UIT minor projects.
CYBER computersystems today is a saga, they have all(?) been shut down. Unless some secret organization has kept it running for unknown reason? However, nostalgic people - like Tom Hunter - have written an emulator running the Cyber hardware, and provided the solution with neccessary system and deadstart files including the PLATO system. PLATO is now named CYBIS in the emulator.
Image created in 2023.