Share This:

So there we were; pioneers on the brave new Isle of Dogs. Shift work may have been playing havoc with our circadian rhythms but the only hardware failure that really fazed us was if the coffee machine went on the blink.

 

I watched as Canary Wharf emerged from a hole in the ground and waited for the painfully slow Docklands Light Railway to develop (replacement bus service only at weekends). The local population quickly realised that we were but the initial wave of island invaders. We were welcomed into the local pubs but left in no doubt that we were the outsiders, the arrivistes.

 

It did help that, in our number, we could call on several locals to ease any nascent tension. Dave was from Greenwich, Harry from Chalk Farm. Both were shift leaders and more than happy to pass on their technical knowledge. In fact, Harry was in the process of joining the Operations Analysis group and night shifts would soon be a distant memory for him. Harry, despite being something of a rough diamond, knew his stuff. He had recently discovered SAS analytical software and was busy producing graphs for everything that moved in the datacentre.

 

On the mainframe itself we had recently started running a product called CA-7. I knew what CA-1 was, that was our tape management system. Was CA-7 something similar? No, CA-7 was a batch job scheduler. I had no idea what this was but I soon realised that its introduction had caused more ripples than the average started task. Anyway, for now it sat there, resolutely doing nothing at all while its implementation was debated.

 

The first obstacle was that we needed training on this new product. Just getting people off shift and into a 9-5 training course proved hard enough. Eventually a date was agreed and we were joined by the consultant who gamely attempted to train us. He explained that CA-7 executed jobs and, upon successful completion, would automatically run the next one in sequence. But wait, there’s more - CA-7 could run variations in the schedule, according to the calendar. For example, if you had special reports that ran on the last day of the week, simply use a CA-7 calendar to submit these only on those dates.

 

This started to sound a lot like my job. CA-7 was, in fact, me - but without the dangerously high levels of caffeine input. Ah, but no, not really. Could CA-7 deal with program failures, lack of disk space, network issues, corrupt files? No, the operator needed to be there, vigilantly watching every step of the way and quickly putting the whole thing back on the rails when needed.

 

Our teacher explained the fundamentals of scheduling, articulated in ways that I still use today. As the course wore on, I thought that it might be better to accept this advance as part of my future. At lunch I sidled up to Dave. “Well, what do you think of CA-7?”

 

“Not a lot. Anyway, it doesn’t matter, I won’t be using it.”

 

“Why not, it’s the future, isn’t it?”

 

“Job scheduling? I have a job and I don’t need it scheduling away. If you’ve any sense, you’ll avoid it.”

 

Dave felt that CA-7 was the “thin edge of the wedge”, that once it was accepted then our services would be surplus to requirement. I pointed out that although the mainframe was the majority of our work we also had plenty of other systems that needed our skills (half-a-dozen DEC systems, Wang Word Processors, various standalone systems). And somebody would be needed to configure the schedules in CA-7 regardless. Dave was unmoved.

 

“Listen, I didn’t spend the last 10 years’ learning how these systems work just for some Johnny-come-lately to appear and tell me we’re going to do it all differently.”

 

“But we’re doing a job that didn’t exist 20 years’ ago, what if our predecessors took the same approach?”

 

Dave shrugged, “I am happy with my technology. The next kind of technology will cost us our jobs.”

 

I spent the early part of the afternoon session worrying about Dave’s comments. My world revolved around the job; the idea that I was not personally central to the company’s future plans concerned me deeply.

 

By the time we reached the afternoon break I was relaxing slightly. CA-7 wasn’t exactly user friendly and it seemed more suited to complex batch environments where hundreds, possibly thousands of jobs ran. I asked Harry for his thoughts. He was, after all, our new Operations Analyst and surely more inclined to welcome new technology?

 

“Nah, can’t see the point of it. If I want to run a sequence of jobs automatically then there are plenty of other ways to do it without buying a specialist tool.”

 

“But what about the calendars?”

 

“Don’t worry, I know when it’s Friday. Listen, you’re going to spend months configuring this thing and then have the overhead of maintaining it and what does it really give you? Saving 20 minutes every batch isn’t going to change the world.”

 

So there we were, again. On one side my colleague thought he would lose his job to this innovation; on the other hand, our technologist doubted the return on investing time in it. CA-7 was friendless.

 

In the end (and after some negotiation) CA-7 was used to submit a new batch of some 20 jobs that could run around 01:00 am. As with many new systems, the code in the batch was prone to failure and required manual fixes and subsequent re-runs. “Told you” opined Dave, “load of rubbish.” But the code failures weren’t the fault of CA-7, I pointed out. Nevertheless, “CA-7 problem” would often appear in the shift log and the system remained on the periphery.

 

I didn’t realise it at the time but suspicion, doubt and general dislike are routine barriers to automation of all varieties. How to overcome these issues were questions for later in my career. For now, I simply added CA-7 to the bottom of my CV and got back to work.

 

Anyway, I had other things to occupy me - I was off to Switzerland.