>A few programs had enough CPU that it was worth while to go further. Don't get me wrong. I have had CPU intensive jobs that could/should have been tuned, but not many.
We had a special unload process that would read a VSAM file and transmit key data to ABMs (A**h***s Become Managers -- respond offlist). It only had one string (RPL) defined (100 sub-tasks). I checked with our CICS people (they always seem to be the VSAM gurus), and they recommended that you have one string per index level and one per concurrent task reading. We did the analysis and increased the strings. The process ran under NETVIEW automation, and the processor was still pegged during this process, but there was a big difference. Before the optimisation, the CPU consumption was over 50% SRB (non-productive -- string re-use). After, SRB was less than 5% -- TCB time -- productive. The job took so long beforehand, that we often had to cancel it. Afterwards, it ran less than 20 minutes. And, all benefited, because we didn't peg the box and pre-empt everything else. I got a B+ performance appraisal and a promotion out of that. (I also got paged because they thought the process had failed. It took us a few hours to verify that everything was kopacetic) - Too busy driving to stop for gas! ---------------------------------------------------------------------- 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
