PROBLEM: (74027) (PATCH ID: OSF440-566)
********
PROBLEM: If the hostname is longer than 12 characters, binlogd writes
up to 4 additional characters into the system type field of each
binary error log record, corrupting the value of that field.  The invalid
value can be seen by examining the header with DECevent or Compaq Analyze.


PROBLEM: (86707) (PATCH ID: OSF440-904)
********
This patch fixes the following problems related to writing 
configuration tbale entries to the binary error log (binlog).  On 
later hardware platforms Compaq Analyze requires a configuration table
entry to be available for correct analysis.  Note that not all
platforms support configuration tables.
On systems that do support a configuration table, if the logfile is
truncated or removed and a SIGHUP (reconfigure) signal is sent to the
daemon, the logfile will not contain a configuration entry.

This problem is resolved by the apllication of this patch.


PROBLEM: (QAR:) (PATCH ID: OSF440-807)
********
If the system is brought down using the "init 0" command, it is possible
that the final binary error log entry may not be completely written to the 
disk, resulting in trailing logfile corruption.  This patch fixes the 
problem by syncing the logfile before closing it.


PROBLEM: (92167) (PATCH ID: OSF440-775)
********
In time zones that are east of the Prime Meridan (with a positive
offset from GMT) Compaq Analyze displays the offset value with a zero
(0) in place of the expected plus sign (+) in some display formats.  In
time zones with a negative offset the time is displayed correctly.
This patch produces the correct display for all time zones.


PROBLEM: (90973) (PATCH ID: OSF440-706)
********
On the first startup following a system panic, the kernel's error log
buffer is copied to a file so that events contained in the buffer can
be recovered and logged by the binary error log daemon, binlogd.  If
the contents of the buffer are invalid, it is possible for binlogd to
coredump while processing the buffer.  If this happens, the file
containing the buffer is not removed, and binlogd will attempt to
recover the events again the next time it is started.  It is most
likely that binlogd will coredump again, and continue to do so on each
subsequent startup until the file is removed.
This problem is fixed by application of this patch.