The in-core directory is why my first step was to tell racfvm to release its a-disk. That flushes the in-core copy. Although I believe when you tell it to access the disk after you've done the flip/change/flip sequence the in-core copy is discarded, but don't offhand remember that for sure. -- Mike Harding z/VM System Support
[email protected] [email protected] [email protected] (925) 926-3179 (w) (925) 457-9183 (c) IM: VMBearDad (AIM), mbhcpcvt (Y!) The IBM z/VM Operating System <[email protected]> wrote on 12/05/2009 03:01:14 AM: > From: Kris Buelens <[email protected]> > To: [email protected] > Date: 12/05/2009 03:02 AM > Subject: Re: Automate z/VM RACF SMF process to z/OS > Sent by: The IBM z/VM Operating System <[email protected]> > > I just made a test, CMS is still behaving badly: it ignores the > machine check or CP isn't giving one when a R/W disk gets linked R/ > O. Conclusion: simply using CP SEND LINK ... RR followed by an > update and CP SEND LINK .... M is as dangerous as doing a LINK MW. > The reason: CMS has structures in storage describing an accessed > minidisk, when you suddenly LINK a R/W mdisk in R/O, CMS doesn't do > anything, the later R/W link doesn't trigger anything else in CMS > either, so the in storage structure still describes the initial > state of the minidisk. Changes applied by another user are invisible.
