Author: Robert Sample
Posted: Sat Aug 13, 2016 7:43 pm (GMT 5.5)
I assume you work for a contracting company attempting to pad its hours? The ONLY time with modern mainframes that anyone should want to optimize is AFTER a performance issue arises. See my signature for the Donald Knuth quote.
And what are you optimizing for? You could want to minimize CPU time? minimize elapsed time? (and no, those are not the same -- at all) minimize I/O? minimize tape usage? Saying you are optimizing without specifying what your goal is, means you're just wasting resources.
Furthermore, optimizing "all our job" (sic) is rather ridiculous. By the 80/20 rule, 20% of your jobs use 80% of whatever resource you are wanting to optimize -- so concentrate on them and ignore the other 80% since they make no material contribution to whatever issue you think you have that needs optimization to resolve. You could easily spend thousands in people time and testing time to save a few cents a job for those 80%.
And, finally, you may be chasing the end of the rainbow. If all your jobs are I/O-bound, and you are optimizing to minimize CPU time, then you have a MAJOR issue. Namely, with an I/O-bound job you could drop the CPU usage as close to zero as you want and it would not have any impact on the job as the critical path is the I/O, not the CPU. So unless you have analyzed your jobs, one by one, and know if they are I/O-bound or CPU-bound, even STARTING an optimization project is a huge waste of resources.
Have you TRIED replacing DFSRRC00 with IKJEFT01 in a job? What was the result if you did? If you haven't, why are you wasting time asking questions on a forum instead of actually testing things?
Optimization makes sense in a couple of cases -- where you have a known performance issue (such as the batch processing not completing in the batch window), or if your management wants to delay an upgrade by tweaking the current workload. However, in both cases the LAST place you look is individual jobs -- start by looking at the overall job flow and see if moving jobs around in the scheduler could buy back whatever is needed.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth
Posted: Sat Aug 13, 2016 7:43 pm (GMT 5.5)
| Quote: |
| Actually we are optimizing all our job. |
And what are you optimizing for? You could want to minimize CPU time? minimize elapsed time? (and no, those are not the same -- at all) minimize I/O? minimize tape usage? Saying you are optimizing without specifying what your goal is, means you're just wasting resources.
Furthermore, optimizing "all our job" (sic) is rather ridiculous. By the 80/20 rule, 20% of your jobs use 80% of whatever resource you are wanting to optimize -- so concentrate on them and ignore the other 80% since they make no material contribution to whatever issue you think you have that needs optimization to resolve. You could easily spend thousands in people time and testing time to save a few cents a job for those 80%.
And, finally, you may be chasing the end of the rainbow. If all your jobs are I/O-bound, and you are optimizing to minimize CPU time, then you have a MAJOR issue. Namely, with an I/O-bound job you could drop the CPU usage as close to zero as you want and it would not have any impact on the job as the critical path is the I/O, not the CPU. So unless you have analyzed your jobs, one by one, and know if they are I/O-bound or CPU-bound, even STARTING an optimization project is a huge waste of resources.
Have you TRIED replacing DFSRRC00 with IKJEFT01 in a job? What was the result if you did? If you haven't, why are you wasting time asking questions on a forum instead of actually testing things?
Optimization makes sense in a couple of cases -- where you have a known performance issue (such as the batch processing not completing in the batch window), or if your management wants to delay an upgrade by tweaking the current workload. However, in both cases the LAST place you look is individual jobs -- start by looking at the overall job flow and see if moving jobs around in the scheduler could buy back whatever is needed.
_________________
TANSTAAFL
The first rule of code reuse is that the code needs to be worth re-using.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Donald Knuth