Terry, Just because RACFVM was able to CP LINK the disk on WRITE mode does not mean that the CMS filesystem on the disk has not been trashed. An error may not be detected until a bad block or file pointer is traversed in the future.
If you can look at RACFVM's console for any errors **before, during, and after** you had it R/W from another ID, that may offer a "sort of" confirmation that nothing untoward happened. But it's not a guarantee. A good method might be to define a TDISK of the same size, LINK to the RACFVM disk RR, use DDR to COPY ALL of RACFVM's disk to the TDISK, and then run MDCHECK against the TDISK: MDCHECK vdev (FSTCHK You can find MDCHECK SAMPxxxx files on MAINT's 3B2 disk. Copy them as appropriate, e.g. COPYFILE MDCHECK SAMPMOD infm MDCHECK MODULE outfm (OLDDATE, and COPYFILE MDCHECK SAMPHELP infm MDCHECK HELPCMS outfm (OLDDATE Read the messages from MDCHECK carefully. Even though it's not 100% perfect (an older public domain STATX6 MODULE from eons ago caught even more errors), it should be good enough. If you have errors, then get back to us for possible fix techniques. And... in the future DON'T FOOL WITH MOTHER NATURE! ;-) Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 12/04/2009 04:53 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 Thanks Kris. Yeah it looks a little saver to what you suggest I will note this for the future. Since the RACFVM's A disk probably does not get written to very often and the change was pretty quick I guess I avoided any issues with him trying to write to the disk while it was in RR mode. I verified that it went back to WRITE mode ok by trying to LINK to it MR from OPERATOR and it would not because RACFVM had it in R/W mode so I knew the LINK worked. Anyway thanks again this was a learning experience for me and one that I will add to the many I have already experienced. Thanks again Kris and to all for the help! P.S - Maybe in a future release RACF can offer a more dynamic and straight forward solution for updating the CONTROL file. 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 From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Kris Buelens Sent: Friday, December 04, 2009 5:22 PM To: [email protected] Subject: Re: Automate z/VM RACF SMF process to z/OS >> 'SEND RACFVM * 191 191 MR' That is NOT enough. It might even cause an corrupted disk, If I remember correctly: when you change the Midsk mode from R/W to R/O, CMS will not release the disk, the "instorage pointers" are unchanged. When later you give it back in R/W, nothing is changed either... The fact though the RACF now correctly used the new file contradicts this.... Also, when you change from R/W to R/O and CMS doesn't do anything, it will be very upset when it would try to write to the disk, CMS will most probably abend, thinking it is about to corrupt the minidisk. Better is what Alan showed or a slight variation, a few more commands, less dangerous SEND CP¨RACFVM DET 191 (for a DETACH, CMS will perform a RELEASE) LINK RACFVM 191 xxx M ;;;;; SEND CP¨RACFVM LINK * 191 191 M SEND RACFVM ACCESS 2009/12/4 Martin, Terry R. (CMS/CTR) (CTR) <[email protected]> Hi Just to let you know I was able to get the SMF CONTROL file in WRITE mode and made the change to the control file. The issue was that apparently there needs to be at least in my case two blanks after "SERVER NO" once I added the extra blank I entered the SMF SWITCH command from the OPERATOR machine and the RACFVM XAUTOLOGGED the RACFSMF machine and the SMF files were processed as advertised. To get access to the RACFVM machine's 191 (A) disk I simply did: From OPERATOR 'SEND RACFVM LINK * 191 191 RR" and then I linked the the disk on OPERATOR in MR mode and made the change. Next I REL/DET the disk from OPERATOR and did a 'SEND RACFVM * 191 191 MR' which gave the RACFVM machine WRITE access back to the 191 disk. Thanks to all for your help it was much appreciated!! Now its on to automate this process on a daily basis and send the file over to the z/OS side for processing. 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 From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Kris Buelens Sent: Friday, December 04, 2009 3:43 PM To: [email protected] Subject: Re: Automate z/VM RACF SMF process to z/OS If your RACF access a MAINT 190, eg as disk Z, this "special" CMS is a bit more clever. 2009/12/4 Michael Harding <[email protected]> I've done the same for other svm's, but the special CMS running on RACFVM doesn't understand "disk load" (at least on systems I can play with). -- 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/04/2009 11:24:37 AM: > From: Kris Buelens <[email protected]> > To: [email protected] > Date: 12/04/2009 11:25 AM > Subject: Re: Automate z/VM RACF SMF process to z/OS > Sent by: The IBM z/VM Operating System <[email protected]> > > What has been shown is an easy way. > I did sometimes things like this: > - LINK in RR, copy the file to your A-disk and change it. > - SP PUNCH RACFM > - DISK DUMP fn ft A > - SET SECUSER RACFVM * > - SEND RACFVM DISK LOAD > -- Kris Buelens, IBM Belgium, VM customer support -- Kris Buelens, IBM Belgium, VM customer support 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.
