Hi Mike, Thanks for the information I will store it way for future reference. Yes, I am coming from the z/OS side so I am trying to learn the way z/VM handles things. With help from folks like you and others on the LIST I have learned a lot with much more to go!
Thanks again, Terry Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [email protected] WFH Tuesdays and Fridays -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Mike Walter Sent: Monday, December 07, 2009 10:34 AM To: [email protected] Subject: Re: Automate z/VM RACF SMF process to z/OS Terry, In case you're coming from the z/OS side of the house, each CMS minidisk contains a File Status Table (FST), pointing to every file on the disk (think of it as the equivalent to the z/OS VTOC). Each time a minidisk is ACCESSed, the FST is read into that user's CMS memory for high-speed access. When a user with R/W access to the disk changes a file (or issues "RELEASE"), the in-memory FST is committed to disk, as well. But if other userid LINKs the disk MW (multi-write), and then issues the ACCESS command for that mdisks, then that other user will read the active FST from the disk into their own CMS storage. When either userid makes any change to a file on the disk, their in-storage FST is re-written to the disk, but the other user is unaware of the change and their in-memory FST is out-of-date. I call that "one-way encryption". Things get very messy, very quickly. Precisely what was changed, and the amount of changes will determine how badly the minidisk is corrupted and how many complete files may be able to be copied from the damaged minidisk to a different minidisk. CMS users can and do reliably share a minidisk read-only. Changes can be made to the disk by one R/W user - but all the R/O users then need to ACCESS the disk again to "see" any changed (when the ACCESS command reloads the FST from the disk into their CMS memory). There are manual procedures that permit such shared R/O disks to permit multiple file changes without affecting users, but they must be followed very carefully. Better to not fool Mother Nature with any production minidisks in the first place until you have researched more, and as always: have good backups in place and ready for restore. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Michael Harding" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 12/05/2009 02:10 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: Automate z/VM RACF SMF process to z/OS 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. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
