>This should have been fixed in the access method so it would benefit all >applications, not in the COBOL RTL where it benefits only COBOL.
"Fixing" blocking factors has always been a performance issue. I remember, shortly after becoming a performance analyst (1981), my ex-wife (application [COBOL] programmer) came to me with a problem with a (tape) batch problem that the entire stream was taking forever (and longer) to run. It had this tape file that was being passed around from job to job. I recommended things like VOL=(,,,RETAIN), which dropped OPS intervention, but then I had her look at the DCB. It was LRECL=BLKSIZE=80 (on tape!). I told her to change the JCL to create what ever BLKSIZE is close to 32756 (I never remember the number -- I use SDB, now). The COBOL programmes all had BLOCK CONTAINS ZERO. The first run of the stream ran in less than 30 minutes. She actually got paged because OPS thought it had failed since it ran so long before. She got a promotion/raise out of it; I got (well never mind!). But, this issue has been sticking around (especially with the knowledge disappearing/retiring), and getting worse. That is why I am such a proponent of SMS. IF (BIG IF) you implement it correctly, you can take the access method details out of the hands of the (less storage savvy) application programmers. But, SMS doesn't stand alone. We need the compilers/assemblers to understand this, as well. - 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
