From: [log in to unmask] on 08/12/98 08:43 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?)




<Gilles>>        <<I've seen 2 types of problems associated with user
logging after
after rebooting - and, in retrospect, they probably are more associated
with
start norecovery - although I'm not positive.
        The two most common problems are as follows:
        1.      LOG xxxx,RESTART fails.
                This is almost always due to the fact that the command is
issued too soon after startup. The larger the existing log file, the longer
one needs to wait to restart logging. It seems that the system needs to
read
the entire log file before allowing the log xxxx,restart to succeed.
Therefore, simply waiting a minute or two or five (according to the size
and
number of active log files) after rebooting before re-issuing the log
command(s) does the trick.>>

<Steve>>>  It would be interesting to hear HP's explanation of this. We use
automatic
restart of the START persuasion, and a SYSSTART file that streams a job
that
executes a script that, among many other things, restarts the logging
processes. An automatic START-type restart almost never fails to restart
the
logging processes (the small number of failures match the next item
mentioned), while a NORECOVERY start fails 100% of the time, as nearly as
we
can recall. There is only one 60-second pause in the automatic startup
sequence, of whatever persuasion; a delay in the job streamed by SYSSTART
to
give the console operator time to :ABORTJOB it if desired.
<Lee>>>> I'd love to hear this, too.  We've never had a problem restarting
logging after a START [RECOVERY].


<Gilles>>        <<2.    For some reason, the log file eof is the same as
its limit.
I can't explain why this happens - only that I've seen it happen many
times.>>

<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
condition.