In answer to your question on why MWV... Back in the late '80s, I think it may have been with VSE/SP 4, IBM started sending out the PSRs with the recommendation of MWV for all VSE minidisks. I guess that it was more of a safety kind of thing. That is, with MWV on all minidisks, you can't accidently destroy a disk by writting on it from another VSE on the same VM image. (Of course, they also had SHR on all ADD statements recommended, also)
I was at two different sites, in the early '90s, that were upgrading to a new box. Single VSE image under VM. And had a lock file defined. All packs MWV and SHR on the ADD statement. The lock file (real disk not vdisk), was getting millions of I/O to it every day. And each site said: "I don't know....IBM said...." To some extent, I could see the logic. If you have a single VSE system under VM, and someone, brought up a second VSE system and didn't know the proper way to share VSE packs, this kind of practice could keep you from shooting yourself in the foot. I seem to recall that a Redbook came out later on how to share VSE disks, under a single VM image. You might want to do a search for it. I normally share, 1 volume across VSE systems for sequential disk and 1 volume across VSE systems with it's own VSAM catalog. When I check the LOCK01 pack for total I/O counts (using Vollie), I see that day to day, I get very little change in total I/Os to the lock file. Just the way I like it <G>. Tom Duerbusch THD Consulting Tom Duerbusch THD Consulting
