On Friday, 05/17/2002 at 09:58 AST, David Boyes <[EMAIL PROTECTED]> wrote: > Hmm. This sounds kind of like the tricks you used to have to do under early > 390 releases with defining multiple addresses for the same device with > different control units to fake the system into initiating more than one I/O > to the same device at the same time (sounds maybe/kinda/sorta what PAV is > supposed to accomplish). > > I would suspect that this probably won't be too effective on the 390 because > the details of the I/O system aren't directly visible to the Linux driver -- > you'd have to do some strange IOCP things to get it to present the same > device with multiple devnums so that this gadget could try to do it's stuff > in the kernel. Do your disks have PAV capability? If so, try turning on this > widget against a PAV volume and see what happens.
PAV is not transparent to the operating system. VM will not enable the PAVs, but permits the guest to do so. On a Shark (ESS), the customer creates logical control units. Within the LCU, the customer defines "base" volumes and "alias" volumes. Each alias is associated with a base volume. The operating system has to be able to (1) enable the alias volumes and (2) identify the base volume for each alias. Parallel Access Volumes (PAV) is the name we give to the concept of using both alias and base volumes to take advantage of the fact that there are multiple physical drives in the box and that head movement and data transfer on some drives does not preclude head movement and data transfer on other drives. In this way the o.s. bypasses the usual "device busy" conditions. It's not like the venerable multi-exposure 2305 (? Can't remember model number. Not meant to engender OT dasd discussion.) which was hard-wired. Alan Altmark Sr. Software Engineer IBM z/VM Development
