> It is true that DIRMAINT's support for "regions" dates back to when your > "DASD Analyst" studied the hot spots on the disk using the SEEK data from > the Monitor. But these days there are no worries about RPS delays or how > far the heads have to move. What you focus on today is I/O queuing.
And spreading that stuff out tends to even that out too. > That said, DIRMAINT regions remain useful to protect things like warm start, > checkpoint, XLINK map records, and anything else that you don't > want DIRMAINT to allocate. Alternatively, you can use the $WARM$, > $CKPT$, etc. users to identify reserved space. My wish list contains an > update to CP QUERY ALLOC to include these other CP-owned extents. Then > DIRMAINT could dynamically create .WARM., .CKPT., etc. users as it does for > the things currently in QUERY ALLOC MAP. Would be nice - someday when the dev folks have a spare afternoon. I find the "dummy userid" ($WARM$, etc) approach is a lot simpler than coding it in DIRM control files -- that approach works regardless of what directory management tool you use -- even if you don't have one -- and it's one less thing to forget about when you do directory migration. ---------------------------------------------------------------------- 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/
