>Thanks for the tip(s). I forgot to mention that there is an IBM RedBook "VSAM De-Mystified" that goes into some, if not all, of what Tom mentioned.
And, as I said, rather than identifying VSAM as a problem, determine what are your problem jobs/transactions/programmes and 'fix' those. I remember once, years ago, my ex-wife was tasked with fixing a programme that had a programming 'problem' -- it was too slow. She looked at it and found that it used three tape files: Input master. Transaction. Output master -- to be used next run. It was a standard COBOL application -- the first thing you're taught in first year programming at University. She found that the LRECL and the BLKSIZE were the same (132). And, the master files were multi-reel. So, she put in a request for JCL changes. The job went from 4 hours+ to less than 20 minutes. And, the master files went down to a single volume, each. She actually got paged, because the job finished so quickly. There are a lot of stories like that out there, and they are still happening, today. My point is, if you go in assuming something is a problem -- my ex: the programme -- you: VSAM, you potentially close the door on examining the real issues. Not to say that a VSAM file is NOT the problem, but, please, keep an open mind. Identifying the few problem tasks, can also reduce your workload. - 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
