2018 sees the fortieth anniversary of my first job. It was in IT – and I never left! To ‘celebrate’ I have delved into my mental history books to illustrate the forty year journey…
I was quite bright as a child. Bright enough to be advanced a whole year which meant that I attended grammar school aged 10. Not really the subject of this blog, but I would not recommend that to anyone. Kids develop physically and mentally at different rates. Let them grow up with their peers. Anyway, at age 14 I was advanced again to take my maths ‘O’ level, allowing me to do additional maths along with my other 8 subjects.
This was the mid 1970s, where the nearest we came to computing was a picture of Charles Babbage on the wall of the maths classroom. Whilst we might have wondered about the possibilities that this great man could present to us, the maths teacher instructed us in the use of slide rules and logarithm tables!
After my ‘O’ levels I went on to ‘A’ level studies, at exactly the same time that the comprehensive system was introduced. I ended up in a college previously run by nuns, who clearly had no experience of dealing with teenage boys, and by and large the teachers were in the same boat. I quietly rebelled (it was the era of punk!), discovering beer, pool and many other distractions. I was still happy dealing with my maths ‘A’ level, but physics and chemistry were boring. Originally, I only took chemistry at ‘A’ level because I was good at maths and could remember the periodic table!
So, I stopped attending. When a letter arrived at home saying I had not been in college for several weeks (these days that alert happens within minutes of the opening bell on the first day of absence), it wasn’t strictly true. I had not been to registration, chemistry, physics and some other pointless class such as business studies, but I had been to maths. Never missed!
The inevitable happened, I dropped out (but not until Easter as I was legally still too young to leave full time education), and I had to get a job. It wasn’t easy in the late seventies, but after a couple of interviews I landed a dream role as trainee in the computer department at a local brewery. I didn’t know it at the time, but attached to the brewery was a pub with a pool table, so those distractions at college eventually came in very handy.
It was August 1978, and the first few days were very exciting. The department consisted of just five people. A manager / programmer, an operator, two punch operators, and a girl who I was to replace. The manager, along with several other brewery employees, took a test to evaluate aptitude in computing. Computing was very new. He came top and was therefore given the job. Not sure what else happened, but it quickly became clear that as soon as I was up to speed he would leave his programming days far behind.
The punch operators were chatty but had a quite mundane job. One of them would type in orders from a sheet. The other would do exactly the same in ‘verify’ mode to identify any errors. After that they would use one of two machines, a sorter or a collator. The collator worked on the principle of two decks of punched cards in the same order, and the machine would collate them. The sorter was a much more complicated beast. It sorted on column, and it would take several passes of the entire deck to get the cards in the right order for processing. If you ever wonder what one of these looked like, the exact same machine appeared in the spy spoof ‘Our Man Flint’, in which a single card was used to identify that Flint was the man! The operator would take these cards and put them in to the Univac 9200 system, along with another deck that was the compiled and linked program, and it would either punch out a third deck or produce a report on one of the noisiest and most lethal printers you could ever imagine. Leave a catch unfastened and the print bar could take your finger off.
The girl that I was to replace did all of these jobs, but she had no interest in programming; that was to be my role.
The Univac 9200 was a single stream device, in that it could execute one program at a time, based on card input. Progress was displayed on a series of lights. The original binary method, I became proficient in binary and hexadecimal without even realising it. The processing could be labour intensive. One job began with someone extracting last month’s sales records for each pub by hand, and adding it to a deck with this month’s records. The machine did what it needed to do to collate the sales records, and then punched card output had to be manually filed back against each pub. It took hours, and when I became a fully-fledged programmer, on a different machine, it was one of the first programs to be truly automated.
A couple of weeks into my employment I was introduced to the Assembler programming language. When I say ‘introduced’, I really mean that it was a passing wave from across the street. My tutor, the manager / programmer, showed me about six instructions, and said that I wouldn’t need any more. If I did, then I could look them up in a book (no, there was no Google!)
My first programming task was to create a simple sales report. The method will seem incredible to anyone who has never experienced this. I used a coding pad. It was a pad of paper with each sheet divided into several lines of 80 columns each. I had to code the program on the pad and then hand it to the punch operators to punch and verify. Ambiguity was a major problem. I learnt to meticulously put a line through my zeroes, top and tail my capital I, and ensure that my Z was distinguishable from my 2. Lower case Ls were a particular problem! The only difference between this deck and the order cards was that mine were ‘interpreted’, which meant that the detail of the card was printed along the top. The cards came back, and I put them through the most precious card deck that we had. The compile and link deck. If this got destroyed there was no more programming. We had a copy, but even so, handling those precious cards was a great responsibility.
The compile often found errors, both syntactically or because I had not been clear in my instructions to the punch operators, and then I had a choice. Should I recreate the cards in error and file them back into the correct place in the program deck? Or should I use the tiny plastic squares and hand punch to manually alter the cards to correct the errors. This was generally quicker, but if you were not careful with the plastic stickers you could cause the second biggest disaster in the department; the wreck. The wreck could happen on any of the machines, and when it did, as indicated by a grinding, high-pitched squeal, flashing lights and the sound of machinery coming to a sudden halt, your whole day was forever altered. First of all you had to open the machine. This was not like lifting a lid on a printer, this was more like taking apart an early combustion engine. There were parts that were red hot, others that were filthy with oil and grease. Somewhere in the depths of this essentially mechanical beast was one, or usually several, torn cards that were way beyond repair. The sticky squares could get into the most awkward positions, and the flimsy cards would somehow jam themselves into the deepest reaches of the card reader.
However, after a time you could assess the damage. If it was a compiled program deck you could get the copy, ensure that you made another copy, and start again. If it was customer or sales records, this was more problematic. You had to interpret the damaged cards, and often give a best guess as to what they should say! As previously explained, cards had 80 columns. They also had 10 rows. The hand punch had numbers 0 to 9, so you also had to remember the combination for 10, 11, 12 and other hexadecimal representations.
A wreck was the second worst disaster. The worst was to drop a box of cards. The punch room was at one side of the brewery yard. The computer room, with its huge air conditioning units and frosted windows, was in the main office building. In between was a working brewery yard. It was cobbled, and frequently filled with rolling barrels. You were generally required to carry several boxes of cards at a time, and when it rained the cobbles became very slippery. Each box contained several hundred cards. The cardboard boxes had lids, so this would often save you, but if you dropped a metal box there were cards everywhere. To make matters worse, the entrance to the brewery yard from the street was under a bridge, which became a huge wind tunnel at the slightest breeze. Some days, not that it happened very often, it was like an episode of the Crystal Maze trying to recapture every single card. Then, of course, they had to be sorted all over again, after you had dried them!
I digress! Once the program was compiled and linked, error-free, I could test it with the help of my printed version produced at the time of compilation, and the lights on the console. These were either on or off! No colours, no shades, it was black and white. The combination showed the hexadecimal instruction, and details of any inputs or derived fields that I was using. All by using sixteen lights. The manual nature of the process meant that I could at least step through it instruction by instruction, which actually meant that I could get through a debugging session quite quickly. The lights became second nature, and the step by step process allowed me to quickly identify bugs. This must have been the foundation for many future toolsets, including the Microfocus COBOL Workbench, but I am still several years from that! There were a few teething troubles with my program; it wasn’t easy to control dangerous printers back in those days, but I got it to work.
So, my first program went into production. This involved making a copy of the source deck and the executable deck and storing them for future reference or in case of disaster. As expected, my boss quickly decided that I was now the programmer, as much more challenging projects came into the IT department.
