We have programs that read the spool statements from opr:spool.log and then display these in an easy-to-read format so that users can easily reprint files.

As you know when spool.log reaches approximately 3mb it is automatically renamed to spool.001 (and .001 is pushed back to .002, etc to .005). Unfortunately this makes the spool files displayed to our customer just "disappear suddenly".

Is there a option/switch to turn off this auto-renaming feature (note that we already have a "trim" command that we use to manage the number of records in logs such as this)? I know that we could also read spool.001 along with spool.log, but it would be simpler if an option already existed.

I've gotten a surprising amount of complaints (or suggestions) about the way the spool.log and ashlog.log files work (where they go, how big they get, how many copies are kept, etc.) Unfortunately, while it would be simple to make any one change (like increasing the size), the difficulty of trying to come up with the ultimate set of options to allow everyone to configure it the way they want has discouraged me from doing anything.

For example, perhaps better than having options for size and number of backup copies, maybe a nightly "trim" mechanism makes more sense. If you have such a trim command, why not run it every night telling it to trim SPOOL.LOG to just, say 1MB. (Or do you generate more than 3MB of SPOOL.LOG entries every day?)

Unfortunately, trimming a file is not particularly efficient, compared to renaming it and starting a new one, so it wouldn't be a great idea to apply trim logic every time we write to the log (like we currently do with the rename logic).

But I suppose it wouldn't be that hard to implement a universal LOGSIZE parameter in the miame.ini to set the threshold for renaming. (One complication though is that some people can generate 100's of MB of ashlog traces in a minute, whereas that would be pretty unlikely with SPOOL.LOG, so one LOGSIZE parameter might not be enough.)

The other approach would be to just use the existing operating system syslog utility, and let you configure that externally from ashell. (The reason I didn't do that originally is that it varies between operating systems and it would be awkward to have to tell people to go study their OS docs to figure out how to find some ashell log messages.

I'm open to suggestions (for 5.1)...

We recently raised the threshold on our "trim" command to 10mb since the former trim limit of 1mb and was not nearly large enough (at 1mb spool.log at larger users would only go back 2-3 days). So we didn't even know until we raised this above 3mb that spool.log had the same auto-renaming feature as ashlog.log!

A selectable LOGSIZE set at say 50mb would do the trick for us since we would be trimming spool.log it nightly to 10mb (i.e. well before the Ashell rename would occur). But if you think users generating 100's of mb of ashlog trace files in a minute would be a problem with a settable LOGSIZE, think how much problem they have with the current 15mb (5x3)limit!

I don't think anyone wants to sort through O/S logs to figure out what printed - especially since the temp file spooled by Ashell is long since gone.

So given the current state of affairs I'll change our programs simply append spool.log on the end of spool.001 (in a temp file) and then read in the spooled lines from it. For the future the LOGSIZE would cure our "issue" as long as it fits into your grand scheme of log management.