On Thu, Jan 28, 2010 at 1:27 PM, Phil Tully <tull...@optonline.net> wrote: > suggesting a performance monitor is appropriate, but more appropriate is > pointing to the commands or screens of such that should be used in that > monitor to determine what was wrong.
My apologies. I was actually holding back with such explicit references in an attempt not to annoy the few subscribers who don't have ESALPS. But you'd look at ESAMDC2 basically for the current fair share value and the number of times users were prevented from inserting into MDC. The invalidate requests is there too (purge of MDC data because of competing I/O) My guess is that the exceeded the fair share. You can tell CP to bypass that for a user, through the directory option. > Also, this is ALMOST a full-pack mdisk, it starts at cyl 1-end,not cyl 0 > > BTW: I am attempting to do this with DDR since I am about to clone 120 linux > guests from the same set of mdisks, and I was going to run this in parallel. > But the ongoing production value is in the 6 mdisks that are shared by > hundreds of WAS guests. In that case, I think I would avoid the additional reading and simply use a pipeline with "fanout" and enough "trackwrite" stages to write them all at once. Even though that does not overlap, your DASD subsystem writing to the back-end may end up being the bottleneck anyway... -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/