What I'd do (gingerly) is to set myself temporarily as racfvm's secuser, do
a "send racfvm release a", then "send racfvm q disk" to see that the
release worked.  Then link racfvm's 191 MW and access it, make your change
and release/detach it, Finally, "send racfvm access 191 a" and "send racfvm
q disk" to verify, then reset racfvm's secuser.
--
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
10:23:05 AM:

> From: "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]>
> To: [email protected]
> Date: 12/04/2009 10:23 AM
> Subject: Re: Automate z/VM RACF SMF process to z/OS
> Sent by: The IBM z/VM Operating System <[email protected]>
>
> Thanks Mike, yeah I noticed that also wasn’t sure what that meant
> but I will adjust the file and see what happens,  I do have one more
> question on this and that is how do I modify the SMF CONTROL file on
> the RACFVM’s ‘A’ disk without logging on to the RACFVM machine?
> Since RACFVM has the 191 disk in R/W I can’t link to from another
> user id in R/W. Is there a another way?
>
> 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 Michael Harding
> Sent: Thursday, December 03, 2009 11:13 AM
> To: [email protected]
> Subject: Re: Automate z/VM RACF SMF process to z/OS
>
> Like Paul's and unlike yours, our SMF CONTROL file has 2 blanks
> following the "SEVER NO". If the following is positionally parsed
> rather than white-space, that would account for the attempt to
> xautolog "ACFSMF".
> --
> 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/
> 02/2009 06:26:03 PM:
>
> > From: "Feller, Paul" <[email protected]>
> > To: [email protected]
> > Date: 12/02/2009 06:26 PM
> > Subject: Re: Automate z/VM RACF SMF process to z/OS
> > Sent by: The IBM z/VM Operating System <[email protected]>
> >
> >  Here is what our control file looks like.  The switch works okay for
us.
> >
> >   |...+....1....+....2....+....3....+....4....+....5....+....6....
> > +....7....+....8....
> > 0 * * * Top of File * * *

> > 1 CURRENT 301 K PRIMARY 301 K SECONDARY 302 K 10000 VL03 CLOSE 001
> > SEVER NO  0 RACFSMF
> > 2 * * * End of File * * *

> >
> > Paul Feller
> > AIT Mainframe Technical Support
>
> > From: The IBM z/VM Operating System [mailto:[email protected]]
> > On Behalf Of Martin, Terry R. (CMS/CTR) (CTR)
> > Sent: Wednesday, December 02, 2009 5:33 PM
> > To: [email protected]
> > Subject: Re: Automate z/VM RACF SMF process to z/OS
> >
> > It appears that there is something wrong with the SMF CONTROL file
> > when I do a SMF SWITCH to RACFVM and he tries to autolog RACFSMF I
> > get and error stating that user
> >
> > ACFSMF is not in the CP Directory. Notice that the ‘R’ in RACFSMF is
> > missing. Here is a screen print of the control file I can’t see the
> > issue maybe I am missing it:
> >
> >

> > ===== * * * Top of File * * *

> >       |...+....1....+....2....+....3....+....4....+....5....+....
> > 6....+....7...
> > ===== CURRENT 302 K PRIMARY 301 K SECONDARY 302 K 10000 LVD1 CLOSE
> > 001 SEVER NO
> > 0 RACF

> > ===== * * * End of File * * *
> >
> >
> > And here it is after I hit PF10:
> >
> > ===== * * * Top of File * * *

> >       ....+....3....+....4....+....5....+....6....+....7....+....
> > 8....+....9...
> > ===== Y 301 K SECONDARY 302 K 10000 LVD1 CLOSE 001 SEVER NO 0
> RACFSMF
> > ===== * * * End of File * * *

> >

> >

> >

> >

> >

> >

> > ====>

> >                                                             X E D I
> > T  1 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: Wednesday, December 02, 2009 9:55 AM
> > To: [email protected]
> > Subject: Re: Automate z/VM RACF SMF process to z/OS
> >
> > Append you code to the PROFILE EXEC of RACFSMF.
> > "append" is a general word here, you could imbed your code in the
> > PROFILE EXEC, have the PROFILE EXEC call your exec, or your exec may
> > replace the current PROFILE EXEC.
> > To make it possible to recover from a failed FTP, it might indeed be
> > good to keep the "old" SMF log on RACFSMF's A-disk and tell FTP to
> > send that (and not send the one from RACFVM 301/302, because that
> > will be ERASEd a while later.
>
> > 2009/12/2 Martin, Terry R. (CMS/CTR) (CTR) <[email protected]>
> > Great thanks just for clarity on my part when the SMF file is either
> > switched due to being FULL or told to switch by the command it
> > writes the file to the A disk (191) of RACFSMF so when I invoke my
> > code to FTP it to z/OS the file mode will by default be looking at
> > the A disk for the FN FT that I pass on the PUT correct?
> >
> > Thanks again!
> >
> > 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: Wednesday, December 02, 2009 2:26 AM
> > To: [email protected]
> > Subject: Re: Automate z/VM RACF SMF process to z/OS
> >
> > You should place your code in user RACFSMF: this user is autologged
> > when RACF's SMF disk is full (that is this RACFVM 301 or 302).  Th
> > "standard" code will copyfile it onto RACFSMF 191 and erase it from
> > 301/302.  Extend the code with your FTP stuff.
> >
> > If you surely want to process each night (and not only when the disk
> > gets full) use your favorite automation software to issue a
> >   CP SMSG RACFVM SWITCH  (or SMF SWITCH or something alike, I don't
> > have the manual here)
> > then RACF will proceed as it the disk is full and start RACFSMF.
> > To be able to send such a SWITCH command, the issuer must be defined
> > in some file you must ASSEMBLE (afair: CSTCONS ASSEMBLE, hence
> > CSTCONS TEXT).  By default OPERATOR is inside, so a CP CLASS C user
> > can fool RACF with
> >   CP SEND CP OPERATOR SMSG RACFVM SWITCH
> >
> > By using RACFSMF directly, you will be sure to process at the time
> > you want, but also when the disk gets full sooner than you expect.
> > 2009/12/2 Martin, Terry R. (CMS/CTR) (CTR) <[email protected]>
> > Hi
> >
> > I want to automate the copying of the RACF SMF records over to z/OS
> > each night. I have the basics down on how to do this but the one
> > thing that I am not sure about is how to determine the SMF data file
> > that is not in use so that I can FTP that file to z/OS. My thoughts
> > were to create a Virtual Machine that links to the appropriate disks
> > so that I can access the RACFVM machine to get the SMF DATA file.
> > Since I do not want to FTP the “in use” SMF DATA file some where in
> > here I need to figure out how to determine which file is not in use.
> >
> > I thought I would XAUTOLOG the Virtual Machine at a designated time
> > each night that would execute an EXEC that would FTP the SMF DATA
> > FILE to z/OS.  As part of the Exec I would probably need to run the
> > RACFADU Unload utility and then run the SMFCONV utility on the
> > output from the unload utility. I will probably write PIPES to
> > handle this.  The SMFCONV process will convert the SMF Unloaded file
> > so that it can be read by the RACF Report Writer on the z/OS side.
> >
> > So, given what I am proposing to do to handle this is there
> > something I am missing or are there any recommendations that would
> > make it similar?
> >
> > Thanks for the help!!
> >
> > 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 on Tuesdays and Fridays
> >
> >
> >
> >
> > --
> > Kris Buelens,
> > IBM Belgium, VM customer support
> >
> >
> >
> > --
> > Kris Buelens,
> > IBM Belgium, VM customer support

Reply via email to