How to configure page data sets is an interesting question. I've just been involved in a customer situation where significant paging was a problem. Unfortunately it's still too fresh to really talk about it. But I can see this new function is a good excuse to blog about paging. And I already have a foil in "Memory Matters" on the importance of paging subsystem design. The customer situation and this APAR mean, I think, another foil or two. At a time when I need FEWER foils.
It's funny how fast things move between (4-monthly) updatings of presentations. In a good sort of way. :-) I think the assumption that paging performance rarely matters is a poor one. Even if true there's a heck of a difference between dumping into a poorly-configured paging subsystem and into a good one. (Far better still to dump into memory, though I realise that's probably unaffordable for many.) And now I have some questions: Do any disk controllers cache paging activity? For many years the answer was an unequivocal "no". This matters because that might drive you to more, smaller, page data sets. Is it still the case that the "contiguous slot algorithm" degrades above, say, 30%? I would think so, though I now measure the number of pages written per I/O and it seems to be around 5 - 10 in the 1.7 era. Maybe I should attempt to prime my developerWorks space with a discussion on paging and invite people to contribute. Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- 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
