It doesn't address unplanned halts -- we always do a START RECOVERY in
these cases simply because the logging subsystem does *not* seem to recover
the user log files otherwise.

The problem with doing a :LOG xxx,STOP without a prior :CHANGELOG xxx is
that the stop record may be that which takes the open log file to its
limit.  When a :LOG xxx,RESTART is issued, the current file is already
full, and with no new file to which to write the restart record, the
:LOG,RESTART command fails.  If you haven't ever run into this, you've been
very lucky.  We hit it a couple of times several years ago before we
discovered the bug and implemented the :CHANGELOG procedure.

Lee



From: [log in to unmask] on 08/13/98 03:16 PM

Please respond to [log in to unmask]


To:   [log in to unmask]
cc:    (bcc: Lee Gunter/BCBSO/TBG)
Subject:  Re: Auto reboot? (without mem dump?)




        <<<Steve>>>  Same here, and this is the only time a START has
failed
to properly restart logging in as long as I can remember. There is, or at
least was, a problem where if the system were halted with the current log
file almost full, the restart got into a Catch-22 situation: it needed to
write some data to the open file to properly close it out, but couldn't
because there wasn't enough room left, so it couldn't open the next file,
so.... I thought this was supposed to have been fixed, but maybe not.
        <Lee>>>>  This is a long-standing bug in the Image logging
subsystem.
HP has *not* fixed this as of the last time I  inquired (I think Alvina
Nishimoto (sp?) responded to my question at the time, and she further
stated
that this was not in the queue to be done).  We get around this problem by
automating our LOG xxx,STOP commands to be preceded by a CHANGELOG xxx
command to ensure that the next LOG xxx,RESTART always encounters a new log
file.  This way, the log file change record may fill the current log file,
but the new log file receives the subsequent log close record, and the next
log restart record isn't blocked by an EOF=LIMIT condition.>>

Interesting idea, but how does it address the problem with unplanned system
halts/power losses? I don't remember having this happen if we did a
"controlled" shutdown of the box; as long as we do a :LOG <logid>,STOP
before
the shutdown, it seems that a NORECOVERY start works fine. But maybe we've
been lucky.