Mary Anne You don't have to re-issue the SPOOL CONS START again after the SPOOL CONS CLOSE because you haven't issued a SPOOL CONS STOP. SPOOL CONS CLOSE doesn't stop the console spooling it just closes the current console spool file and opens another one.
It would seem to me the best way to do this would be for your CONLOG SVM to be a class C user and use SEND or the FOR command in z/VM 5.3 to close the consoles. Your CONLOG SVM could wakeup at midnight and issue "FOR userid CMD SPOOL CONS CLOSE" or "SEND CP userid SPOOL CONS CLOSE" for each of the LINUX guests and then process the console files from its reader. You could also just use the CP CLOSE CONsole command to close the console because you are not changing the spooling characteristics. One way to ensure the guest had spooled their console to CONLOG would be to use "FOR userid CMD SPOOL CONS TO CONLOG CLOSE" Rick Richard R. Bourgeois President Virtual Software Systems, Inc. 7715 Browns Bridge Rd Gainesville, GA 30506 770-781-3200 [EMAIL PROTECTED] -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mary Anne Matyaz Sent: Thursday, September 20, 2007 8:39 AM To: [email protected] Subject: Re: Copying zVM and zLinux Logs to MVS GDG dataset Someone in IBM had a paper that detailed this, basically called CONLOG. I'm checking to see if it's ok to post it. But basically, you you do a SPOOL CONS CONLOG START EOF in each Linux's profile exec. Nightly, we do a 'bump' by issuing a SPOOL CONS CLOSE then the SPOOL CONS CONLOG START EOF again to all the linuxes. This sends the log to an ID that you set up called CONLOG. In CONLOG then who is constantly running, you do a WAKEUP function (WAKEUP +2(RDR)) that wakes up when reader comes in, and processes it. From there you can receive it, then FTP. (Here's my FTP): queue 'userid password' queue 'put profile.exec VM.GDG(+1) queue 'quit' 'FTP 9.1.1.1' Mary Anne (Finally able to give something back to the list...you've come a long way baby) On 9/20/07, Dave Kutz <[EMAIL PROTECTED]> wrote: > > I am not a Linux user and know very little of zVM. I am responsible for > zOS TCPIP. > > But maybe someone can provide a "How to". > > I'd like to have our zVM and zLinux logs reset every morning and sent over > to a z/OS GDG dataset automatically so that we have a history of what > happened. > We do this today for the zOS console messages. > > My zVM sys programmer responded with this comment > "Not very easily. Each item running under z/VM has it's own log and one > operator log. With Linux, I set up a seperate log. To get the task you > need to issue a close console" command for each individual task. With > that, it gets spooled to the PRT queue. From there we need to get it to > the RDR queue then to a mini-disk. From there we would have an ftp job to > grab the listing and put it into a GDG. The problem is to get something > scheduled to trigger the close console and to then to transfer it to each > queue then the minidisk." > > Has anyone out there come up with a easier automated way to cut the logs > and willing to share? > > Thank you > > > Dave > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
