Our problem with purging spool files (we use VM:Spool instead of SFPURGER) is the following:
The date & time stamp on the file is the time it was OPENED. Our Linux guests run for months. So when a Linux guest crashes or is logged off, the spool file is immediately eligible for purge -- and we risk losing error messages. To avoid this, we close the spool files every night. That saves recent messages, but not messages issue when the guest was first brought up. So be careful if you have long-running guests. -----Original Message----- From: CMSTSO Pipelines Discussion List [mailto:[email protected]] On Behalf Of Kris Buelens Sent: Thursday, May 05, 2011 10:13 AM To: [email protected] Subject: Re: [CMS-PIPELINES] Notification on logoff? SFPURGER does not purge open files. And, that SFSPURGE can purge it right after an IPL, I'd like that: after an IPL, AUTOLOG1/2 will probably restart the service machine, so it is OK, and one'd better not receive that pending" email. 2011/5/5 Schuh, Richard <[email protected]> > Does the purger purge open files? If not, it would be OK; however, it will > not be sent until it is closed. If that happens in conjunction with a > SHUTDOWN, it may still be caught by the purger before it can be sent. The > monitoring SVM is the answer. Here we have 2 machines. One monitors the > entire complex of SVMs; the other, only the main monitor. > > Regards, > Richard Schuh > > > > > -----Original Message----- > > From: CMSTSO Pipelines Discussion List > > [mailto:[email protected]] On Behalf Of Bruce Hayden > > Sent: Wednesday, May 04, 2011 12:11 PM > > To: [email protected] > > Subject: Re: Notification on logoff? > > > > That would only work if the virtual machine resets, which it > > would do if it is IPLed or it logs off. But, if it just dies > > and sits there without a VM or CP read (or the 15 minute > > timebomb is disabled) then your spool file wouldn't be sent. > > > > Maybe your server could use the timebomb diagnose (diag 288) > > via the timebomb package on the VM download page. Then, if > > your server crashes, you wouldn't reset the timebomb and it > > would reboot. Of course, a better answer is use some kind of > > monitoring software (commerical product, a tool, or home > > grown) that would know that your server died and react accordingly. > > > > On Wed, May 4, 2011 at 1:29 PM, Paul Gilmartin > > <[email protected]> wrote: > > > I tend a service machine that mostly runs unattended, > > processing work > > > requests that are sent to its reader (email, actually, from UNIX > > > systems.) Yesterday, someone complained that his request > > had not been > > > processed. The service machine had crashed 32 days before! > > > > > > I can't diagnose it from the spooled console log -- our site purges > > > spool files after two weeks. > > > > > > So, I get a weird idea. In PROFILE EXEC: > > > > > > CP DEFINE PUNCH ... /* Not 00D */ > > > CP SPOOL ... to RSCS CONT > > > > > > Use NETDATA, etc. stages to create an email image addressed to > > > me, and leave it in the CONT spooled punch. > > > > > > When the server crashes, the punch will be closed and the RSCS will > > > deliver the email to me. > > > > > > o Will this work? > > > > > > o Is it abusive of system resources? > > > > > > o Is there a better way? > > > > > > Thanks, > > > gil > > > > > > > > > > > -- > > Bruce Hayden > > z/VM and Linux on System z ATS > > IBM, Endicott, NY > > -- Kris Buelens, IBM Belgium, VM customer support ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
