The other thing that we do, is we have a log file archiver (LOGARCH)
that receives all consol logs (in the virtual reader) saves them (after
compressing) and provides for a frontend to view them in XEDIT:
05/05/11 13:07 Log File Archives
2 of 2
Category Description Files Oldest Newest
Blocks
OPERATOR OPERATOR console log 8 03/31/11 04/10/11
708
OSADMIN1 OSA configuration logs 8 06/28/09 06/28/09
33
PERFSVM Performance Toolkit Console Log 31 04/05/11 05/05/11
32
SFPURGER SFPURGER run log 23 04/05/11 05/05/11
24
SMTP VM Mail Server 8 01/06/11 04/10/11
17
TCPIP VM TCPIP/Telnet Server 8 10/10/10 04/10/11
5553
VGINVHLP Secondary Inventory Support Server 8 08/08/10 04/10/11
29
VGLIBSRV VGS Machine 8 08/08/10 04/10/11
2112
VMLNX000 CentOS 4.7 Server 8 11/02/10 04/10/11
34
VMLNX001 SUSE SLES 11 Server 8 10/10/10 04/10/11
1412
VMLNX002 Debian Linux v5 2 04/08/10 04/23/10
27
VMNEW VM new version install and testing 0 - -
0
VMTEST VM RSU/COR testing 3 03/31/11 04/10/11
4
VMUTIL VMUTIL console log 24 04/05/11 05/05/11
1014
VM2ND VM 2nd level console log 8 10/27/10 03/22/11
12
VSECONS VSE IPL Console log 8 09/12/10 04/10/11
5550
VSEMAINT VSEMAINT (VSE Maintenance) user 2 01/05/10 01/13/10
19
VSESETUP VSE VDisk Setup console log 8 06/28/10 11/07/10
13
PF: 1 HELP 2 Refresh 3 QUIT 4 Sort+Cat 5 Sort+Des 6
7 Backward 8 Forward 9 Toggle 10 Sort+# 11 View 12
Sort-Blk
There is a configuration file that contains criteria (origin id, fn, ft,
etc.) and retention parameters.
Frank M. Ramaekers Jr.
-----Original Message-----
From: CMSTSO Pipelines Discussion List
[mailto:[email protected]] On Behalf Of Ackerman, Alan
Sent: Thursday, May 05, 2011 12:49 PM
To: [email protected]
Subject: [CMS-PIPELINES] Notification on logoff?
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.
_____________________________________________________
This message contains information which is privileged and confidential and is
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any
review, disclosure,
copying, distribution, or use of the contents of this message is strictly
prohibited. If you have
received this in error, please destroy it immediately and notify us at
[email protected].
