There could be a simpler way to handle the log files. In the Pipe that I use to collect EREP data, I write to files that have the current date as their filetype. It is very easy to set a limit for the number of days' data you are willing to keep. Once a day, a routine runs that simply erases files that are too old. Another machine is logged on daily to process the data from the previous day. Simple, clean, and it doesn't take much time to clean off the disk. You have access to the data for a few days if you need it. If you want to mash it all into one big file you can do so from another machine without impacting the server in any way.
Surely something like that could be implemented in the TCPIP family where, it appears, someone thought there would be an infinite amount of space on the A-disks of the servers. How else can you explain an ever-increasing file with no provision for performing regular maintenance? "An oversight," you say. Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, August 29, 2007 2:11 PM To: [email protected] Subject: Re: TCPIP restarting server too soon On Wednesday, 08/29/2007 at 03:06 EDT, Aria Bamdad <[EMAIL PROTECTED]> wrote: > I have a local exit defined in my DTCPARMS file for my SMTP servers. > When a server is started the exit is called with the 'BEGIN' parameter. > During this time, the server will process the log files that exist on > it's A disk. However, this may take some time and at times, the server > does not finish before TCPIP notices that the server is not listening > and force/autologs the server. This messes up the log processing routine! > > Is there a way to prevent TCPIP from restarting servers for a window of > time to allow for server exit processing to complete. No, sorry. I would suggest using the exit to swap disks and then signal another virtual machine that it can link, access, and process the logs or maybe just SENDFILE them to another virtual machine. Alan Altmark z/VM Development IBM Endicott
