Hello!
I asked about strange timestamps (01-JAN-1970 00:59:59) in the errorlog
of a XP1000 running 4.0E + pathckit 1. I received some answers (also
including the ExploreZip Trojan Horse Program :-):
Dr. Tom Blinn replied, that DECevent doesn't support the XP1000
plattform. I rechecked the web site again and V2.9 is the latest
version available and it is supposed to include support for the new
style error log format.
Peter Stern suggested to check the output of uerf (almost forgotten) and
surprisingly it doesn't seem to be DECevent's fault:
# uerf
uerf version 4.2-011 (122)
CORRUPTED ERROR ENTRY - ENTRY DUMP:
RECORD HEADER
0000: 00000000 00000000 00000000 00000000 *................*
0010: 00000000 00000000 00000000 00000000 *................*
0020: 00000000 00000000 00000000 00000000 *................*
0030: 00000000 00000000 *........ *
RECORD BODY
0038: 00000000 00000000 00000000 00000000 *................*
0048: 00000000 00000000 00000000 00000000 *................*
0058: 00000000 00000000 00000000 00000000 *................*
...
This output explains the strange date, as 01-JAN-1970 is the beginning
of the unix epoch, as many responses suggested.
My last action was to check the installed patches, which brought my
attention to:
>PROBLEM: (Patch ID: OSF435-056)
>********
>Compaq Analyze enabler
>
>A new version of the binary error log daemon (/usr/sbin/binlogd) converts
>the internal format of each error log entry to a new format that is common
>across the three major Alpha operating systems: Digital UNIX, OpenVMS,
>and Windows NT. This common format is utilized by "Compaq Analyze",
>a new analysis utility that replaces DECevent. Compaq Analysis only
>supports the new, non-TurboLaser EV6 machines (DP264, Goldrush, Clipper...),
>therefore the new binlogd only converts the headers of binary events on
>the new EV6 platforms. The previous platforms are unchanged.
The only thing replaced by this patch is /usr/sbin/binlogd. I did a
test, killed the running daemon, restarted the old daemon, created a
log entry with 'logger -b' and the timestamp was the current time as it
should be!
Conclusion: Until I find an acceptable reason, I will skip this patch on
my installations from now on.
--
Stefan
Received on Tue Jun 15 1999 - 16:04:21 NZST