>I rewrote a single COBOL program myself. The run time went from about 12 hours >to less than one hour. And it was a change to only one paragraph. And not >likely a truly optimal change at that.
In the very early 1980's, my ex-wife was a junior COBOL programmer at a large Canadian (now out of business) retailer, in Toronto. They had this huge batch job that took (literally) hours to run. With the multiple time-zones in Canada, this was becoming a major problem. So, they assigned her the job of optimising it. They didn't know her husband was a performance analyst. So, she brought the problem to me. I asked her to show me the JCL and the File Definitions. I know COBOL, but I hate debugging it. All the files were FB-80-80! I told her to change the FD's to BLOCK CONTAINS ZERO. And, to maximise the blocksizes in the JCL. She did it in two steps. COBOL first, JCL second. When the job ran for the first time, after both changes, it took less than 20 minutes. She was actually paged because Operations had thought it had failed because of the shortened duration even with RC=0 for all steps. She got a raise and a promotion out of this, because it was running at a service bureau and saved real money, including disk and tape. So, the point: not all optimimisation is code. CPU is cheap compared to I/O, and I/O can be optimised with common sense. CPU optimisation takes analysis and an understanding of what the code is doing. I/O just takes looking at the file definitions. - 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
