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