Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
Quote:
a) Lesser the CPU time lesser the cost associated .
b) If CPU time is less then the batch window decreases
a) This depends on the chargeback system used; some sites don't use chargeback so there is not a "cost" associated with CPU time. Sure the machine cost something when purchased, but without chargeback that can be regarded as a sunk cost.
b) you're mixing apples, oranges, and pomegranates in one statement. CPU time going down may or may not impact the run time of the job -- if the job is I/O-bound, which is true for many data transfer jobs, you could reduce CPU usage to zero and the run time for the job wouldn't change. I/O-bound jobs are not waiting for CPU time, so cutting CPU time doesn't change the amount of time it takes to run the job -- unless you manage to change the job to be CPU-bound. And the batch window is an entirely different fruit as well. Reducing the run time for a single job only impacts the batch window if that job is on the critical path for the batch window. If there is slack time during which the job is running, the job could be eliminated without impacting the batch window at all.
Joined: 11 Dec 2008 Posts: 59 Location: Pune , India
Thanks Robert for the information .
I was referring wrt the environment i am working. At this moment i can only comment the following on the two points
a) Most of the outsourcing organizations or banks cannot afford a mainframe/MVS of their own . Hence they hire a mainframe either for a tenure like one year or pay a cost for each job run on the mainframe or report kept is SAR etc. For jobs the cost is directly linked to mainframe CPU time.
b) Frankly speaking i am not much aware of making a job 'CPU bound' or 'I/O bound' in the way discussed.May be i am forgetting something. I will go and do my homework and if i get stuck anywhere will disturb you .
Joined: 06 Jun 2008 Posts: 8697 Location: Dubuque, Iowa, USA
a) I'm pointing out that cost in the sense you're using it can be a very fuzzy number.
b) This is classic computer science going back to my college days. A job (which could be a batch process, started task, TSO user, etc) running on a computer cannot finish in zero time because it is waiting for something. If it is waiting for CPU to be able to continue (which would include paging, CPU cycles, virtual memory access, etc), the job is CPU-bound; if the job is waiting for I/O (reading the data off disk, channel transfer time, request time, etc), the job is I/O-bound. The job may be swapped out in which case it is neither since it is not ready to run. If the job is spending 99% of its time waiting for data to come off disk, reducing the CPU time from whatever it is to zero would cut your run time by ... 1% at most. This is I/O-bound.
