[Info-vax] Openvms AXP clock problem

[Stephen Hoffman]

On 2016-10-14 22:49:39 +0000, Sandro Altamura said:

> Dear Stephen,
> thanks for your reply. My DEC2K AXP is actually a Jensen machine.

There's Jensen and Culzean in the most likely translation for what 
you've specified.   The DEC 2000 model 300, and DEC 2000 model 500, 
respectively.

>  I know that it is not a "pure" machine (it can even run WinNT) but 
> when I bought it more than 10 years ago was already coming with OpenVMS 
> installed. I already replaced the 4.5V battery since the old one was 
> exhausted.

Pure?  More than a few Alpha systems could run Windows NT.   That was 
one of the ways DEC tried to make Alpha more successful, and get the 
hardware costs down.   My grumbles here are that Jensen and the 
bigger-box Culzean systems were the first attempt to make cost-reduced 
commodity-parts Alpha systems.    Prior to these boxes, the parts were 
pretty heavily DEC-derived.   But I digress.  The Jensen and Culzean 
boxes had particular problems with stable hardware configurations, 
particularly around the SCSI bus.     If you were right in the center 
of what was supported, they worked.    Extend the SCSI bus wrong, and 
things got wonky.   Later boxes — AlphaStation, AlphaServer — were also 
using commodity parts, but with a comparatively better and more stable 
mix, and configuration support was much more flexible.

Historically, hobbyists have hsf trouble with those boxes, and those 
boxes get passed around, and the newest recipients of those boxes show 
up here with... hardware weirdnesses.   Though not usually clock 
related.

That DEC 2000 box has one of those old three-cells battery packs?   
Interesting.   Didn't think that made it across from VAX hardware.   
Ah, well.    Newer Alpha boxes usually have either Dallas or coin 
cells.   I'd probably replace that three-cell pack again, but I'm still 
puzzled by the time-skew-matches-the-power-outage that you're reporting.

> NTPD is not running and the timezone is already set.

Set the timezone again.   V6 and that box were both flaky.    Then 
ensure the shutdown is running to completion, and that it is issuing 
the SET TIME there,    Then — failing all that — get NTP going, and 
fetch the NTP date from somewhere else.   Using NTP (client, not NTPD) 
will mask the symptoms of whatever is going on here.

> I switch off the machine only after getting the chevron on the console 
> so the system is definitely shut down.

You're using SHUTDOWN.COM and it's getting as far as the "use console 
to halt system" message?   Okay.   That should get the data written.

> I guess my next step would be to reinstall vms (maybe to version 7.3) 
> and see if things will go better.

Install V7.3-2 or V8.4 on a scratch disk and see if that manifests 
similarly.   Though there was an Alpha version, V7.3 is only used on 
VAX in recent years.   If you need a V7 release, it's V7.3-2.

The other possibility is that there's some other bug that's effecting 
the timekeeping.  A number of older Alpha boxes on older SRM had 
timekeeping bugs in SRM.   This might be another one, but this 
time-skew-matches-the-power-outage is not a manifestation I've seen 
discussed or reported before.

Here?    Failng all that?   Configure NTP, and then fetch the time (via 
ntpdate) for each boot, and then start the NTP client to keep the time 
synchronized.

http://labs.hoffmanlabs.com/node/1280

Make sure you don't expose an NTP server to the Internet.   All of the 
old versions of OpenVMS have a serious security problem with NTP, and — 
if the NTP server is somehow exposed to the 'net — it'll get detected 
and will be picked up into one of the DDoS botnets, which will hammer 
your performance plus hammer some other folks on the network limited 
only by the speed of this Jensen / Culzean box, and the bandwidth of 
your Internet link.



-- 
Pure Personal Opinion | HoffmanLabs LLC