Been in VM waaay to long to do the duplicate minidisk problem <G>. All my shared minidisks are owned by user $SHRDASD. Everyone else links.
And when I have a second level VM system, there is no MDC on the second level system. Since VSE can't run on an IFL, there is also no sharing across LPARs. Anyway, I reject (until proven otherwise) that this problem has/is being caused by any sort of caching on this system. But when the vender is trying to fix the problem, I tend to go along with any/all suggestions, if anything, just to move the process forward. Tom Duerbusch THD Consulting >>> Alan Altmark <alan_altm...@us.ibm.com> 7/29/2009 11:49 AM >>> On Wednesday, 07/29/2009 at 11:52 EDT, Tom Duerbusch <duerbus...@stlouiscity.com> wrote: > However, CA is saying that the root cause of our DYNAM catalog corruption is > caching. Not impossible, of course, but highly unlikely. If all I/O is coming down the same chpid from the same VM system, the cache isn't relevant, so you could vary offline all but one chpid. > Where I can see if some VSE systems are accessing the DYNAM catalog thru some > sort of cache while other systems are not....big problem here. > > But single VM system with MDC turned on for all, with the IBM DS6800 with > caching being mandatory (I believe), shouldn't cause problems. > > I turned off MDC for the DYNAM shared disks and our corruption problem > continues. So they wanted caching turned off in the controller for the DYNAM > disks. I don't think that is going to happen. Possibly you have other MDISK statements rather than LINKs, and one has MDC and the other doesn't? Tell CP the volume is SHARED and all MDC for the volume will be disabled, regardless of directory settings or SET commands. Alan Altmark z/VM Development IBM Endicott
