If my new batch applications aren’t performing as well as I’d hoped, what should I do? Well, the most likely answer is go back to the original code and see what was going wrong. Another solution might be to forget all about developing mainframe-based applications all together and move to a “newer” platform. I put newer in quotes because the IBM-compatible (does anyone ever say that anymore?) PC has been around since 1981 (12th August, I’m told) – which makes it older than many of the legacy applications it’s meant to replace and older than many of the “experts” who work on it! But there’s a third alternative – one well-known to senior mainframers who still inhabit enterprise sites. I can sum it up in three letters. J, C, and L – Job Control Language.
I had it drawn to my attention by Guy Giuffre that the main causes for batch applications wasting mainframe resources such as DASD, tape, and CPU cycles is invariably poor JCL and improper job scheduling. I was assured that the majority of performance problems are “caused by programmers who may know how to write code but are completely lost in writing effective JCL or in putting together job streams that run efficiently”. And if that particular blind spot wasn’t bad enough, there was another target of attack. Mr Giuffre asserted that: “These problems are then compounded by application support analysts who either blindly install what is given to them by the programmers or who do not have the ability to dissect what is given to them and optimize it.”
Hard-hitting stuff, but where’s the evidence? Again, Guy was able to identify his own successes by confirming that he didn’t need code to be re-written, he could achieve better performance by rewriting JCL and realigning job scheduling so successfully that he achieved DASD reductions of as much as 45%, tape reductions of as much as 50%, and overnight batch application run-time reductions of as much as 40%.
There are more savings to be had for an organization. For example, it becomes possible to avoid having to man shifts over a weekend because this and scheduling optimization results in the weekend cycle finishing by 7:30am on a Saturday morning instead of 5:30pm on a Saturday evening.
If someone were to turn up for a meeting with the IT Director and offer them a product that could bring about similar savings, then I bet they would have an easy sale on their hands. And yet, many sites have experienced mainframe programmers or system support personnel like Guy Giuffre, who understand the bigger picture and are not seduced by the need to run every application from a browser using AJAX and RESTful states. They can picture what’s going on inside the mainframe and make changes to improve performance of individual applications. And because it’s their job, their skills and abilities are not always celebrated the way more fashionable successes might be.
And, with so many experienced mainframe people coming towards retirement age, this powerful ability – this sense of what needs to be done to improve performance without pouring over hundreds of line of code – may soon become lost to many organizations. So I suggest that managers start picking the brains of the mainframe staff they have to ensure that this kind of knowledge is preserved. Otherwise, their companies will need bigger and faster hardware, not because their programs are bigger or clumsier, but because no-one has taken the trouble to look at the JCL and the job scheduling. Thanks Guy, for drawing our attention to this.
I had it drawn to my attention by Guy Giuffre that the main causes for batch applications wasting mainframe resources such as DASD, tape, and CPU cycles is invariably poor JCL and improper job scheduling. I was assured that the majority of performance problems are “caused by programmers who may know how to write code but are completely lost in writing effective JCL or in putting together job streams that run efficiently”. And if that particular blind spot wasn’t bad enough, there was another target of attack. Mr Giuffre asserted that: “These problems are then compounded by application support analysts who either blindly install what is given to them by the programmers or who do not have the ability to dissect what is given to them and optimize it.”
Hard-hitting stuff, but where’s the evidence? Again, Guy was able to identify his own successes by confirming that he didn’t need code to be re-written, he could achieve better performance by rewriting JCL and realigning job scheduling so successfully that he achieved DASD reductions of as much as 45%, tape reductions of as much as 50%, and overnight batch application run-time reductions of as much as 40%.
There are more savings to be had for an organization. For example, it becomes possible to avoid having to man shifts over a weekend because this and scheduling optimization results in the weekend cycle finishing by 7:30am on a Saturday morning instead of 5:30pm on a Saturday evening.
If someone were to turn up for a meeting with the IT Director and offer them a product that could bring about similar savings, then I bet they would have an easy sale on their hands. And yet, many sites have experienced mainframe programmers or system support personnel like Guy Giuffre, who understand the bigger picture and are not seduced by the need to run every application from a browser using AJAX and RESTful states. They can picture what’s going on inside the mainframe and make changes to improve performance of individual applications. And because it’s their job, their skills and abilities are not always celebrated the way more fashionable successes might be.
And, with so many experienced mainframe people coming towards retirement age, this powerful ability – this sense of what needs to be done to improve performance without pouring over hundreds of line of code – may soon become lost to many organizations. So I suggest that managers start picking the brains of the mainframe staff they have to ensure that this kind of knowledge is preserved. Otherwise, their companies will need bigger and faster hardware, not because their programs are bigger or clumsier, but because no-one has taken the trouble to look at the JCL and the job scheduling. Thanks Guy, for drawing our attention to this.
