Why RACF pick the updated SMF CONTROL file: maybe CMS in RACFVM abended, then it restarts itself and the 191 disk is reaccessed.
2009/12/5 Martin, Terry R. (CMS/CTR) (CTR) <[email protected]> > 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* > *[email protected]* <[email protected]> > > *WFH Tuesdays and Fridays* > > > ------------------------------ > *From:* The IBM z/VM Operating System [mailto:[email protected]] *On > Behalf Of *Kris Buelens > *Sent:* Saturday, December 05, 2009 6:01 AM > > *To:* [email protected] > *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) <[email protected]> > >> 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 >> [email protected] >> >> WFH Tuesdays and Fridays >> >> -----Original Message----- >> From: The IBM z/VM Operating System [mailto:[email protected]] On >> Behalf Of Mike Walter >> Sent: Friday, December 04, 2009 6:55 PM >> To: [email protected] >> 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)" <[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. >> > > > > -- > Kris Buelens, > IBM Belgium, VM customer support > -- Kris Buelens, IBM Belgium, VM customer support
