On 6/17/11 10:03 AM, "Bill Holder" <[email protected]> wrote:
>That would certainly prevent any page allocation on paging volumes. >Just be aware that if you do need to depopulate the spool volumes >that paging overflowed to, you'll have the same problem - the existing >techniques for moving spool (SPXTAPE and such) won't work on >paging overflowed to spool. Paging on spool space is still paging. OTOH, that idea pretty much guarantees that those seldom-referenced pages that get paged out during startup end up on lesser-performance DASD where they're out of the way. Few of us (if any) want that miscellaneous cruft on the really high-performance paging disk, which we'd probably never use for spool space. The renaissance of SSD in the outboard disk boxes may make the prioritization of paging hierarchy important again. (geez. Shades of HPO. I feel all DMKxxx'y again. 8-)) >But I should mention that the DRAIN statement in the config file >can be used to similar effect, on a per volume and per >allocation type basis, Wouldn't that be easier? Would save the steps of listing paging volumes in Offline_at_IPL, VARY ON and ATTACH x to SYSTEM, anyway, particularly with multiple paths to volumes, etc. We can just use START for the individual volumes. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
