A long time ago, in an IT environment far, far away … I began my career in Computer Operations. Across the IT industry this band of brothers (and no few sisters) has frequently been re-branded with the words “information”, “systems” or “infrastructure” imposed upon it. However, the original title that I encountered is hard to improve on; Computer Operations Group, a small but essential wheel in supporting and supplying platforms for the business user.
Back in that distant galaxy, Computer Operations was often a miscellany of high-end activities (who wants to do an emergency point-in-time database recovery at 3 a.m.?) mixed with the mundane repetition of handling tapes and distributing printed output. At the heart of everything was the overnight batch. An art in itself, the batch was a constantly changing creature, often growing to the point where it threatened to impinge on that sacred resource, online business hours. The batch would plow on overnight, like a hulking cruise ship and (with a bit of luck and judgement) come dawn it would find itself safely berthed.
The batch run was mapped out in a paper-based checklist and your best chance of avoiding icebergs was to use the latest checklist version. My employer invested in a top-end Xerox Documenter (children, this was what desktop computing was meant to be before Apple and Microsoft performed their audacious heist) and I enthusiastically dedicated myself to maintaining the checklist on my outsized Xerox screen. The system was ideal for drawing flow charts and I frequently asked (i.e. bugged) our Operations Analysts if it was possible to shorten the total batch run time by making the flow more efficient. If an update job only had to wait on a few specific files then, under my watch, it would be run as soon as those new files were available.
My eagerness to optimise the batch was not entirely altruistic. True, we did only have a small window in which to resolve job failures (about 2 hours leeway on a weekday night) but I had quickly come to learn that I had my limits when it came to shift work. We could, on average, finish the batch by 4 a.m. This was the point at which I would hit “the wall” – a state of extreme tiredness that would see my shift leader banish me from the bridge area (where all the system consoles flickered on 3270 terminals) to the relative safety of the tape library or the print room. After 4 a.m. I would wander, zombie-like, struggling to replace the ribbon on a huge printer or trying to find a tape cartridge from the 7,000 available in the racks.
The ideal night shift, for me, was to sign-off the end of the batch at 03:59 and repair to the drawing room. Actually, we had no drawing room but what we did have was a coffee area with the comfiest sofas that I have ever encountered. Perhaps they weren’t actually the comfiest ever but all I know is that as soon as my head touched the armrest then I was out like a light. The datacentre was located high in one of the first towers to be built in Docklands, so I would drift off to sleep whilst watching nocturnal London twinkle.
All I needed was 60 minutes sleep and then I was ready to go again. That was just as well, because this was no holiday camp, no sir! The online systems were required to be restarted by 6 a.m. sharp. Databases needed to be made available followed by the ubiquitous CICS systems, the DEC-based systems fired into life and a range of other, less reliable, systems demanded various levels of assistance before they could face the business day. We even had an IBM XT PC (what for, nobody knew, it was certainly no Xerox Documenter).
By 8 a.m. we were happy to hand over to the day shift and head home, another batch put to bed, another checklist completed. However our cosy world was about to be rudely disturbed by the constant roil of technology - and the blot on the Computer Operations horizon was something called batch job scheduling.