PROBLEM: (SSRT0713U) (PATCH ID: OSF510-189)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file or privilege management. Compaq has
corrected this potential vulnerability.


PROBLEM: (83795, 86707, 81711) (PATCH ID: OSF510-327)
********
This patch fixes the following problems related to writing
configuration table 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.
1) On systems that do support a configuration table, if a SIGUSR1
signal is sent to the binlog daemon to cause the error log to be
archived, a new logfile is created with no configuration entry.  The
same problem occurs if the log is truncated or removed and a SIGHUP
(reconfigure) signal is sent to the daemon.

2) On systems that produce a configuration entry that is larger than 32
Kbytes,  a corrupted entry may be written to the error log under some
circumstances.  This problem is reported by Compaq Analyze as a corrupt
error log.

3) On systems that do not produce a configuration entry, the binlog daemon
may incorrectly display the following messages when it is restarted with
an empty error log:
  GSI_FRU_TABLE_SIZE: Function not implemented
  GSI_FRU_TABLE: Function not implemented
  ERROR allocating mem for fru table

All of these problems are resolved by application of this patch.


PROBLEM: (90973) (PATCH ID: OSF510-487)
********
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.