>E.g., if you code BUFNO=huge, for very large values of huge (>>5), then you will tie up large amounts of real storage which, in some situations, may cause other users to suffer excessive page faults. ...
As smart as DR. Barry is, I wouldn't trust anybody's 21 year old paper on memory/disk/io performance. Too many things have changed since 1984. A lot of shops weren't even on XA. 64M was considered excessive memory. Expanded storage was just coming out. (Now it's gone, again). We've had: XA ESA OS/390 z/OS Since then. And, we haven't even touched on DASD improvements, cache as an expensive option to standard equipment, huge memory allotments, data in memory (various flavours), 64-bit, z9 IDAW changes, ESCON, FICON, FICON & FICON, and datastriping. I would consider that paper as a good starting point, just like POP370 is a good starting point for z/Arch. I'd rather get something a little more current. Even the guideline I posted earlier, is suspect; it came from 15 years ago. But, that being said, I tend to think 8-12 buffers is the best choice, assuming that we have 'reasonable' blocking (ymmv). But, it has more to do with LDR, than the potential for page-faults (yours or others). -teD In God we Trust! All others bring data! -- W. Edwards Deming ---------------------------------------------------------------------- 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
