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
