|
View previous topic :: View next topic
|
| Author |
Message |
fazilbe
New User
Joined: 03 Dec 2008
Posts: 25
Location: INDIA
|
|
|
|
Hi Mistermind,
I am afraid i cannot move the output to DASD from tape because of its huge size. Its holding more than 150GB of data and expected to hold the same every month. So we cannot have this amount of data in DASD in production machine which could results in space shortage. Please provide your valuable suggestion on this. Thank you.
Regards,
Fazil |
|
| Back to top |
|
 |
Debabrata Pruseth
New User
Joined: 11 Dec 2008
Posts: 59
Location: Pune , India
|
|
|
|
Hi fazilbe
| Code: |
Description Utility(Minimum CPU time)
VSAM to VSAM ADRDSSU
VSAM to IAM SORT
VSAM to QSAM SORT
IAM to VSAM SORT
IAM to IAM ADRDSSU
IAM to QSAM SORT
QSAM to VSAM SORT
QSAM to IAM SORT
QSAM to QSAM SORT
VSAM to Tape ADRDSSU
IAM to Tape ADRDSSU
QSAM to Tape SORT |
This was found out in a extensive research on backup utilities in one of the projects in our organization . ADRDSSU is the best utility for tape backup . You can have a similar testing in your environment and prepare a table for reference that your can use for future purposes.
You have to take similar size files and run the various utilities on them . Compare the CPU time and cost to pin point the best utility. I think the table above will hold true universally. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
It is good to keep in mind that cpu used is not usually a main consideration when comparing data copy utilities.
Another consideration is whether the copy is to be done on one or a few huge files of the same organization type or if the copy is for possibly hundreds or thousands of unlike files. |
|
| Back to top |
|
|
Debabrata Pruseth
New User
Joined: 11 Dec 2008
Posts: 59
Location: Pune , India
|
|
|
|
| dick scherrer wrote: |
It is good to keep in mind that cpu used is not usually a main consideration when comparing data copy utilities.
|
The main reason i referred CPU time is
a) Lesser the CPU time lesser the cost associated .
b) If CPU time is less then the batch window decreases . Ideally the critical period of any production batch should be minimum . At least in the system that we use ( Vision Plus for Credit Cards ) we are always advised not to put anything non critical that will increase the critical time in the production batch and have it as low as possible. Small changes such as using ADRDSSU has helped us in decreasing batch window timings in certain project to a great extent.
Can you give me from your experience what are the other main consideration when comparing data copy utilities ( apart from the size and type of data ). This will help us a lot in deciding the right compare utility for the right job . |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Lesser the CPU time lesser the cost associated . |
True in the purest sense, but quite misleading. The vast majority of the cost of high volume copies is the data transfer which reauires very little cpu time.
Yes, often there is a batch window that needs to be protected.
Time permitting, i'll try to add a few more thoughts to this over the weekend. Please post a reply/reminder to this topic Friday night or Sat so i'll get an alert e-mail. If you have the info you want, please post that as well. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
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. |
|
| Back to top |
|
|
Debabrata Pruseth
New User
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 . |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
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. |
|
| Back to top |
|
|
|
|
