Log file management ( 32768 version limit) - VMS

This is a discussion on Log file management ( 32768 version limit) - VMS ; The TCPIP RECEIVER creates a new log file for every incoming email attempt. The TCPIP$SMTP_RECV_RUN.COM procedure has logic to purge its own log files, but it has no logic to deal with version limit issues. I would like to automate ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Log file management ( 32768 version limit)

  1. Log file management ( 32768 version limit)


    The TCPIP RECEIVER creates a new log file for every incoming email
    attempt. The TCPIP$SMTP_RECV_RUN.COM procedure has logic to purge its
    own log files, but it has no logic to deal with version limit issues.

    I would like to automate this in as generic a way as possible.


    My initial thoughts are just to add code (or invoke an external
    procedure) that check if version limit is greater than say 32000 and
    then purge down to say 500 versions (to handle cases where a directory
    may not have version limits), and then proceeed to rename each one in
    proper order starting at version 1.

    (this code would be generic and be used for any command procedure or
    heck, even in sylogin.com for batch or network mode :-).

    Questions:

    Can a command procedure obtain the exact full file specification of its
    output file ?

    Can the command procedure rename its own log file to an earlier version,
    or would this fail because the file is in use ? (in which case, the
    command procedures would just submit the cleanup code to a batch queue
    instead of doing the cleanup themselves.)

    Any ideas on how to handle two processes running the same .COM and
    writing to different .LOG to ensure that only one of the two would
    perform a cleanup at a time ? Each could create a temporary file to as
    a poor man's lock, but this has issues should the procedure fail leaving
    a stray file there. Logical names that can be shared between processes
    require privileges. Any other ideas on how to have one process signal to
    another that it is handling a job (in DCL) without requiring any
    privileges ?

    Can unprivileged use JDOE create a logical name table owned by JDOE so
    that any JDOE process can read/write to it ?


  2. Re: Log file management ( 32768 version limit)

    JF Mezei wrote:
    >
    > The TCPIP RECEIVER creates a new log file for every incoming email
    > attempt. The TCPIP$SMTP_RECV_RUN.COM procedure has logic to purge its
    > own log files, but it has no logic to deal with version limit issues.
    >
    > I would like to automate this in as generic a way as possible.
    >
    >
    > My initial thoughts are just to add code (or invoke an external
    > procedure) that check if version limit is greater than say 32000 and
    > then purge down to say 500 versions (to handle cases where a directory
    > may not have version limits), and then proceeed to rename each one in
    > proper order starting at version 1.
    >
    > (this code would be generic and be used for any command procedure or
    > heck, even in sylogin.com for batch or network mode :-).
    >
    > Questions:
    >
    > Can a command procedure obtain the exact full file specification of its
    > output file ?
    >
    > Can the command procedure rename its own log file to an earlier version,
    > or would this fail because the file is in use ? (in which case, the
    > command procedures would just submit the cleanup code to a batch queue
    > instead of doing the cleanup themselves.)
    >
    > Any ideas on how to handle two processes running the same .COM and
    > writing to different .LOG to ensure that only one of the two would
    > perform a cleanup at a time ? Each could create a temporary file to as
    > a poor man's lock, but this has issues should the procedure fail leaving
    > a stray file there. Logical names that can be shared between processes
    > require privileges. Any other ideas on how to have one process signal to
    > another that it is handling a job (in DCL) without requiring any
    > privileges ?
    >
    > Can unprivileged use JDOE create a logical name table owned by JDOE so
    > that any JDOE process can read/write to it ?
    >


    For the SMTP RECV logs in particular, there is no real need of them,
    so I just let the version "hit the roof" and let it be like that.
    It (as you wrote) does not stop the SMTP server from running or
    processing received mails. If there is an actual problem to
    investigate, one can always delete all logs and just ask the
    sender to resend the "problem-mail"...

    > in which case, the command procedures would just submit
    > the cleanup code...


    Why would one need to run the cleanup code for *each* run
    of the batch job ? Just let the versions numbers grow and
    run the cleanup code nightly or weekly (or whatever,
    depending on how fast the version numbers grow).

    I have a similar case where a few 1000s of LOG's are created
    each day and each night they are renumbered back to ;1, ;2...
    After an PURGE/BEF=YESTERDAY to keep two days of logs.

    The "renumber" is done using two RENAMES commands and is run
    on the same batch queue as the original jobs and thus
    "blocking" any new LOG files during processing. Must have
    been running each night for well over 5 years now...

    Jan-Erik.

+ Reply to Thread