In what seems like another lifetime, I learnt to program in Fortran on an ageing UNIVAC 1100 model 70 at the University of Wollongong whilst studying for my Bachelor of Computer Engineering degree. The UNIVAC had 1 Megaword of RAM (quite a lot back then) and filled several rooms in the computing centre that few people every actually went into. You couldn't actually interface directly with the mainframe. You had the choice of submitting your programs to be run as batches via punch cards or tape, or you could use one of the flickering monochrome text-only terminals scattered about the campus. These terminals connected via 9600bps serial RS232 connections to one of three Perkin-Elmer mini computers operating as terminal servers.
It could easily be argued that the Perkin-Elmers were nearly as capable as the Univac, however the Univac had oodles more storage thanks to its offline tape drives. These operated by migrating data from the expensive washing machine sized 20MB Hard Disk Drives to tape which would be removed by the operating and placed into tape storage. Files unused for 30 days were automatically moved offline files and marked with an asterisk on your file list. If you wanted the file, there was a command to request it and the operator would receive a message to load tape XYZ. He would scurry off, find the tape, mount it and your file would be restored like magic. Once restored you received a message your file was available. Naturally, it was a source of amusement for students to save meaningless files, let them age offline and then restore them one at a time just to keep the operator nice and busy. Sometimes we would coordinate our activities to really keep him busy.
The UNIVAC was a very important mainframe back in its day. The University rented time to the local Government and external companies including BHP. As such (and also due to its temperamental nature) there was an operator/programmer on duty 24x7 in shifts of three. It goes without saying that the dog watch (midnight to 8am) was the most boring shift to work and the one generally worked by the most junior person. There was an Urban Legend floating around at the time that one of the operator/programmers was bumped from afternoon shift to dogwatch and was less than impressed with the arrangement. Bored easily and since the only excitement that ever happened during dogwatch was when something broke, he decided to try and break something with software. He wrote a program to seek the HDD heads at varying frequencies attempting to find its resonant frequency. He found it, and sent the washing machine size HDD vibrating and bucking for several hours to see if it would crash. It didn't, however he found out that at frequencies around the resonant frequency it would 'move' in different directions. Working out the particular frequencies required to move the HDD unit in different directions, he wrote a program to link those frequencies to directional keys on the console keyboard. He could then run this program and move the HDD unit around the computer room (the HDD was connected via a long cable bundle). After a few nights amusing himself with his HDD 'robot' and failing to cause a crash, he gave up on it. However, a few weeks later, something really broke which required calling in an external engineer at around 3am. Then engineer arrived onsite more than a little peeved at being called out so early and made a few derogatory comments to the operator about his skills and intelligence, so after the engineer had finished his work, the operator loaded up his little program and had the HDD 'attack' the engineer. When the day shift arrived they found the engineer had locked himself in the tape storage room sobbing hysterically. When they asked the operator what had happened he replied "I don't know. He started screaming that the HDD was attacking him."
Nearly three hundred terminals around campus existed in three clusters (corresponding to the three Perkin-Elmers). There was a cluster for the Library, Science and Mathematics. Engineers had to use one of these, however usually they were full. We complained about this and a small cluster of thirty terminals and four printers was made available for engineers. A old WOLF front-end terminal server was rolled out to manage this cluster. The WOLF was so old its control program was loaded via paper tape. In appearance it was a two foot square cube with blinking lights on one side and a pile of 25 pin RS232 ports on the other. Normally this would be placed in a secure location, however it was placed in the same room as the terminals plonked right next to one of the terminals! There was also a clearly labeled 'Control Port' directly above the other RS232 ports. Conveniently, there was also a 'programmers manual' in a pocket on the back of the WOLF. Seriously? What were these guys thinking putting this combination in the hands of engineering students? This is like leaving toddlers unsupervised in a toy store. All we had to do was sit down at the terminal next to the WOLF, unplug the terminal server port corresponding to the terminal number, plug it into the 'control port', pick up the programming manual and... play! A side effect was that it was a great way to 'reserve' a terminal - you simply left it plugged into the control terminal and others would just think it wasn't working as they couldn't log in. Those of us in the know would just sit down and plug the terminal into the correct port.
At first it was just harmless pranks. Make messages pop up on terminals telling people their account was suspended or shutting down the terminal where some young fickle thing of rare feminine beauty was sitting and then offer your assistance to help them fix the problem, exchange phone numbers etc. Soon, however, we learnt you could do SO much more. The WOLF did a lot more than act as a simple terminal server. It handled security flags for the UNIVAC. In essence, the WOLF asked the UNIVAC what security a user had and then translated that to terminal numbers and then informed the UNIVAC what security flags the terminal had as a result - the UNIVAC trusted the WOLF implicitly. It was a simple matter to reset terminal based security flags to whatever you wanted. It didn't stop there, however. You could reset these flags for ANY terminal - not just those handled by the WOLF! The only terminal you couldn't do this for was the control terminal in the computer room used by the operator/programmer on duty.
For amusement, you could stroll into the cluster an hour before an assignment was due, sit down at the control terminal and type ']B' which would shutdown the entire cluster accompanied with a chorus of thirty screams. After the mass exodus took place with people rushing to other clusters in the vain hope of finding a free terminal there, you could then type '320R' which would bring the cluster back on-line.
There was one real use we put our WOLF knowledge to and that was the annoying sixty second timeout for terminal use. If there was no keypress in sixty seconds, the WOLF would log you out and you would lose whatever you were working on. Sometimes (like just before assignments were due) the UNIVAC would be so busy it would take longer than sixty seconds to respond to a line of input. The 'UNIVAC twitch' was a developed impulse to hit the spacebar at around fifty second intervals to stop this from happening. However, with a simple modification to the control program of the WOLF, this was no longer necessary.
There were several members of our group that played around with the WOLF to see what it could do and we would compare notes and share 'war stories' of things we had done with it. One member of the group found a way to elevate the permissions of a program running on the UNIVAC to do the same thing - it was quite an achievement. We reported our findings to the computer centre and they acknowledged the issue and essentially dismissed us for the simple reason than it would only ever affect students and the control terminal would never be affected; it could shutdown any offending program and then reset the security flags.
One member of our group (who shall remain anonymous) decided to test this premise and exploit the fact that the control terminal could only shutdown one program at a time. He created two programs named RHOOD and FTUCK (UNIVAC filenames were limited to five characters). Both programmes essentially did the same thing and each program contained the code for the other. Upon executing, RHOOD would reset all security flags for everything everywhere to zero - meaning nothing would work except the control terminal and then check for the existence of FTUCK. If FTUCK was not running, it would send the message "Alas Friar Tuck, thou art assailed. I come to thine aid!" and respawn FTUCK. FTUCK in turn, would do the same thing for RHOOD. He wrote the program under a 'borrowed' account and ran it.
It was like turning out a light. The UNIVAC was down for a week.
The following Monday we came in to find the UNIVAC was up and running. A team had worked the whole weekend on an orderly shutdown and restart - something that had never been down since the UNIVAC had been commissioned ten years earlier. Nobody knew the process and no one was sure if it would ever have come back to 'life' again properly. Fortunately, it did.
We had a visit from the manager of the computer centre to one of our lectures to make a general announcement. It just happened to be a subject that every one in our group took (except one). He explained what had happened and how with a little too much detail for us to be comfortable with, the he said "We know the UNIVAC security isn't good. By exploiting it, you aren't proving very much. Now we have a pretty good idea of who you are. If we ever can prove it, the the least we can do is expel you." and with that he left. Our activities after this were much soberer than before - with one minor exception...
Most terminal clusters had printers attached to them, however the quality of the output on these 9-pin dot matrix printers left much to be desired. The get really good quality output, you sent the print job to the high quality (for the day) line printer in the computer centre. This central printer was hidden away and would merrily print jobs with the banner of the owner of the job as the first page. You sent the print jobs in and picked up your jobs the next day from a pigeon hole corresponding to the last two digits of your user id. My id was 8515682 - so my printouts would be in pigeon hole marked 80-84.
The line printer worked on a simple principle: It had a fast rotating platen with every printable character on it in order from ABC on down. Behind the platen was a row of 132 separate hammers that would strike the platen at the exact moment the correct character passed in front of it. The hammers would strike in seemingly random order until the entire line had been printer - so it appeared as though the printer produced a line at a time. This all happened very quickly with a peculiar by product: the printer sounded musical. Hitting a tightly stretched metal platen with a hammer would produce a musical tone with the pitch according to which hammer or combinations of hammers had fired at that precise moment. Somebody, somewhere had produced a document that mapped musical notes to characters printed on the line printer. One of the members of our group wrote a surprisingly short fortran program to take musical notation and send the text output to the printer to play music. He chose the 1812 overture which has explosions and cymbal clashes it it. For the symbol clashes he substitute a series of form feeds (these were so fast the line printer sounded like it was screaming) and for the explosions he substituting a line of 'ABCDEFG....' which meant all 132 hammers would fire at once with a huge 'bang'. Then without too much thinking, he ran the program.
Next day when he went in to pick up the printout, there was a single torn page in the pigeon hole with a note from the computer centre manager reading 'Please see me'. To say the least, the manager was not amused and presented him with four boxes of printout (each box containing about 2000 pages). By chance, three more of us were waiting outside to see the outcome of the meeting, so we each carried a box of printer paper.
Even in 1985, the Univac was getting on and needed to be replaced by a Unix system. Professor Reinfelds and his grad students developed a method for porting the Perkin-Elmer minicomputers to Unix. This was such a dramatic breakthrough that he formed the Wollongong group and went private, taking his methodology (and grad students) with him for greener pa$ture$. However, the University was left with three perfectly functioning Unix based minicomputers.
The non-portable operations of the Univac were migrated to a Univac emulation on a UNISYS 2200 minicomputer. Academics, staff and students were moved to the three Perkin-Elmers and a couple of Pyramind Nile 9000. Sometime in 1989, the Univac was switched off for the last time, the constituent parts sold for scrap and the computing centre (now renamed the Information Technology Centre) gained several new offices from the vast area occupied by the Univac.
