In a conversation yesterday with Jim Manias of Advanced Systems Concepts about the nature of software scheduling, it occurred to me that today’s batch jobs are not your grandfather’s batch jobs by any means. This is worth a modicum of discussion….
From the days of mainframe computing right through to the minicomputer and Unix server era, batch processing had a healthy life. Some major processing loads were handled as batch jobs simply because it wasn’t possible to process such work in an on-line manner.
Thus, for example, we had credit card transactions being recorded at retail outlets across the world that would be sent to one of the big credit card processing engines (Visa, Master Card et al) where they would be passed in big batches through the engine. Once upon a time all business applications worked in that way, because on-line access simply did not exist. Then on-line computing was introduced and because of the gifts of Moore’s Law, we could afford to process individual transactions on a “random arrival” basis. Batch business applications began to die out at that time.
But there was other batch work, such as the back-up of files or the movement of data into a data warehouse or the renewal of data marts or the cleaning down of log files or the archiving of data. Batch processing never vanished.
The PC
Tell a lie. Actually it did, in respect of the PC. Or to be more accurate, it was never born. There was a distinct difference in the philosophical approach of the PC. It was a device you interacted with and ran programs on. It was completely interactive and never offered scheduling capabilities. This lack of appreciation for batch work has persisted even though the PC is now running a distinctively different operating system than the one it as born with.
Windows, incidentally is where Advanced Systems Concepts has done rather well in selling its ActiveBatch scheduling software, precisely because scheduling isn’t something that Windows ever focused on. However that wasn’t something we spent much time discussing. ActiveBatch sells well because it targets “Enterprise Scheduling”. It spans multiple environments and it maintains a central library so it is possible to control all scheduling from one point (at least in respect of all the environments it caters for).
Silo-Stomping SOA
You could legitimately be wondering why anyone would want to schedule jobs globally across a corporate network. Given the way that applications have been deployed in recent times, there hasn’t been much need for that. Under Linux and Unix, local scheduling needs can be catered for by the local Cron utility. Under Windows you could use ActiveBatch or some other scheduling utility to meet the local need. And that would be because most or maybe all business applications are deployed in siloes and the need for local scheduling is confined to the silo, carried out in many instances by the database. The general tidying-up work that batch jobs also carry out (deleting log files, etc.) will be local. SOA has put an end to such a tidy arrangement.
The key point to understand here is that, prior to SOA, you could pretty much schedule a system’s activities according to time. There would be a “duty cycle” that matched the clock with a system being available to users, say, between 6.00am and 10.00pm, after which the system would be unavailable. For the other 8 hours, batch jobs would run that moved data about and tidied up the environment. This could be the case even for web-facing systems, with transactions being gathered-but-not-actioned within part of the 24 hour cycle. So while the web-facing part of the system ran 24/7 the back-office was taken out of service to allow for batch work.
Leave a reply