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] <mailto:[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
