Thanks Kris. I understand what is happening now. This was a good exercise for me and I learned a lot hopefully this has helped others that are in the same boat in terms of being new to VM and becoming more advanced as me. I am still not sure why my update to the CONTROL file worked basd on your test but it did. Anyway live and learn. Thanks again for everyone's help on this. Here is the output from the MDCHECK that I ran per Mike's suggesstion it looks like I got lucky in this case and the disk looks ok: Address: 6400 Device type: 3390 Date created: 07/04/27 13:01:35 VOLID: RCF191 Block size: 4096 Last changed: 09/12/04 15:26:52 Cyls: 9 Usable cyls: 9 Total blocks (ADTNUM): 1620 Blocks used (ADTUSED): 12 ( 1%) Blocks counted: 12 Bits set in ALLOCMAP: 12 Lost blocks: 0 Invalid blocks: 0 Multiply-used blocks: 0 Disk origin pointer: 4 Files reported in DIRECTOR: 6 (including DIRECTOR and ALLOCMAP) Number of files found: 6 Number of invalid FSTs: 0 Files with bad data block count: 0 . 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 <mailto: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: Saturday, December 05, 2009 6:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Automate z/VM RACF SMF process to z/OS 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