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.
Here's the console: *Step 1: make EREP link its 191 in R/O* send erep q disk a EREP : LABEL VDEV M STAT CYL TYPE BLKSZ FILES EREP : EREP 191 A R/W 2 3390 4096 28 EREP : Ready; T=0.01/0.01 11:36:19 Ready KRIS at VMKBBR01 cp send erep listfile new file A *<-- Check if file exists* EREP : DMSLST002E File not found EREP : Ready(00028); T=0.01/0.01 11:37:28 Ready KRIS at VMKBBR01 cp send cp erep LINK * 191 191 Ready KRIS at VMKBBR01 EREP : DASD 0191 LINKED R/W cp send cp erep LINK * 191 191 RR Ready KRIS at VMKBBR01 EREP : DASD 0191 LINKED R/O send erep q disk a *<-- CMS in EREP still thinks its 191 is R/W* EREP : LABEL VDEV M STAT CYL TYPE BLKSZ FILES EREP : EREP 191 A R/W 2 3390 4096 28 EREP : Ready; T=0.01/0.01 11:37:41 Ready KRIS at VMKBBR01 *Step 2: create a new file on EREP' s 191* link EREP 191 999 M DASD 0999 LINKED R/W; R/O BY EREP Ready KRIS at VMKBBR01 ACC 999 Z Ready KRIS at VMKBBR01 PIPE LITERAL ****!> NEW FILE Z Ready KRIS at VMKBBR01 l new file z NEW FILE Z1 Ready KRIS at VMKBBR01 rel z (det DASD 0999 DETACHED Ready KRIS at VMKBBR01 *Step 3: Give EREP its 191 back in R/W* cp send cp erep LINK * 191 191 M Ready KRIS at VMKBBR01 EREP : DASD 0191 LINKED R/W send erep q disk a EREP : LABEL VDEV M STAT CYL TYPE BLKSZ FILES EREP : EREP 191 A R/W 2 3390 4096 28 EREP : Ready; T=0.01/0.01 11:40:03 Ready KRIS at VMKBBR01 *Step 4: Does EREP see the new file?* cp send erep listfile new file A *<-- New file invisible* EREP : DMSLST002E File not found EREP : Ready(00028); T=0.01/0.01 11:40:15 Ready KRIS at VMKBBR01 cp send erep ACCESS EREP : DMSACC724I 191 replaces A (191) EREP : Ready; T=0.01/0.01 11:40:27 Ready KRIS at VMKBBR01 cp send erep listfile new file A EREP : NEW FILE A1 EREP : Ready; T=0.01/0.01 11:40:31 Ready KRIS at VMKBBR01 If EREP would have performed an update in step 4, but before the ACCESS command, the disk could have gotten corrupted, and for sure, the "NEW FILE" would not have been there anymore. 2009/12/5 Martin, Terry R. (CMS/CTR) (CTR) <terry.mar...@cms.hhs.gov> > Mike, > > I took your suggesstion and ran MDCHECK against a copy of the RACFVM 191 (A > disk) and there were no errors found. I assume I was to do this only on the > 191 mini disk and not the whole pack which is broken up into multiple mini > disks? > > > > > Thank You, > > Terry Martin > Lockheed Martin - Information Technology > z/OS & z/VM Systems - Performance and Tuning > Cell - 443 632-4191 > Work - 410 786-0386 > terry.mar...@cms.hhs.gov > > WFH Tuesdays and Fridays > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Mike Walter > Sent: Friday, December 04, 2009 6:55 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Automate z/VM RACF SMF process to z/OS > > 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)" <terry.mar...@cms.hhs.gov> > > Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > 12/04/2009 04:53 PM > Please respond to > "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> > > > > To > IBMVM@LISTSERV.UARK.EDU > 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 > terry.mar...@cms.hhs.gov > > WFH Tuesdays and Fridays > > > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Kris Buelens > Sent: Friday, December 04, 2009 5:22 PM > To: IBMVM@LISTSERV.UARK.EDU > 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) <terry.mar...@cms.hhs.gov> 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 > terry.mar...@cms.hhs.gov > > WFH Tuesdays and Fridays > > > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Kris Buelens > Sent: Friday, December 04, 2009 3:43 PM > > To: IBMVM@LISTSERV.UARK.EDU > 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 <mhard...@us.ibm.com> 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 > > mhard...@us.ibm.com > mike.b.hard...@kp.org > mikehard...@mindless.com > (925) 926-3179 (w) > (925) 457-9183 (c) > IM: VMBearDad (AIM), mbhcpcvt (Y!) > > > The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on > 12/04/2009 11:24:37 AM: > > > From: Kris Buelens <kris.buel...@gmail.com> > > To: IBMVM@LISTSERV.UARK.EDU > > 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 <IBMVM@LISTSERV.UARK.EDU> > > > > 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. > -- Kris Buelens, IBM Belgium, VM customer support
