One of the biggest things we have done is to move as much as possible from tape to disk. We had a large number of batch jobs at night that used tape, and some of the jobs used the SAME tape as input. Moving these files to disk probably cut down the nightly batch cycle by around 20 percent time-wise. Not only can multiple jobs use the dataset at the same time now, but we no longer have to wait for any outside-the-silo tape mounts from operators. Jobs tend to run VERY slowly when waiting for a mount while the operator is on the phone, getting dinner, or going to the restroom, etc...
Also, try and move as many files as possible to VIO. We've done this for many small temp files, and this has had great paybacks. C. Todd Burrell Senior z/OS Systems Programmer ITSO (404) 498-3299 (404) 723-2017 (cell) -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, December 27, 2007 4:34 PM To: [email protected] Subject: Re: Batch Tuning On Dec 27, 2007, at 2:49 AM, Jason To wrote: > We have been constantly improving our batch window by implementing the > following available technologies: > > 1. SMS SMB and data compression on some of our VSAM files 2. System > determined blocksizes on sequential files 3. BUFNO on some input files > 4. Constantly improving our access to DB2 > 4.1 Add indices > 4.2 Compress of big DB2 tables > 4.3 Reorg of DB2 databases > 5. Increase parallelism > 6. Improve DFSORT performance > 7. Improve application efficiencies > > We have basically improved the batch window after implementing all > these, however, after some time, the batch starts to become longer > again. My question is aside from these, any other thing we can do to > implement to improve our batch further? TIA. > > Regards, > Jason > Jason, You just gave a extremely brief list. So its hard to come up with any generalization(s)., The first I would do is look at sort and see if you can give in more storage. Sort LOVES storage and lots of it. I do not have much experience with DB2 you might want ask the DB2 list for ideas. If you have VSAM files and its heavily used look at increasing cisizes and make sure you don't have to many splits (CA or CI) as to the applications, I would suggest hiring a COBOL consultant (assuming that is what they are written in) . Don't be cheap with any resource is another well known tuning call but know when they are being wasted as well. Be generous but don't be overkill. Ws ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
