RX2600 VMS 8.4 keeps asking for the time at boot

[Richard Maher]

Hi,

When I boot VMS 8.4 on my RX2600 it asks me for the time and it was last
booted only yesterday.

Is there some battery I have to replace? Lovely YouTube video?

Cheers Richard Maher

[Rich Jordan]

On May 22, 5:50 pm, Richard Maher <maher_rjSPAML...@hotmail.com>
wrote:

http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c01868329/c01868329.pdf

Appears to be a coin cell on page 103 of the above doc.

If you have an iLO MP card then it may also have a battery

[Stephen Hoffman]

On 2013-05-22 22:50:42 +0000, Richard Maher said:

> When I boot VMS 8.4 on my RX2600 it asks me for the time and it was
> last booted only yesterday.
>
> Is there some battery I have to replace? Lovely YouTube video?

If the system parameters SETTIME or TIMEPROMPTWAIT are set to require
it, the box will prompt for the time at boot.

If your SYS$BASE_IMAGE.EXE base image file is five or more years old,
the box will prompt for the system time. Load a more recent UPDATE
kit. <http://labs.hoffmanlabs.com/node/1795>

If the coin cell is dead, the box will prompt for the time.

If it's the battery...

Item 8 on Page 63, and particularly page 103 and following:
<http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01868329/c01868329.pdf>

Battery part info:
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?prodSeriesId=447335&objectID=c03115627>

Replace both of the coin cells while you're in the box.

--
Pure Personal Opinion | HoffmanLabs LLC

[Richard Maher]

Thanks Rich and Steve!

When I put my head-phones on I'll check out all of your advice.

I pretty much don't own anything < 5 years old (especially my wardrobe!)

Cheers Richard Maher

[hb]

On 05/23/13 12:14, Richard Maher wrote:
> On 5/23/2013 7:14 AM, Stephen Hoffman wrote:
>> If your SYS$BASE_IMAGE.EXE base image file is five or more years old,
>> the box will prompt for the system time. Load a more recent UPDATE
>> kit. <http://labs.hoffmanlabs.com/node/1795>

Without looking a the referenced URL and its section about
EXE$GQ_TODCBASE the "age" of a base image is not obvious. HP is aware of
the problem and it seems the UPDATE kits have a more recent - again
determined by EXE$GQ_TODCBASE - base image.

If you don't want to update with an UPDATE kit, you can get a small
program to update EXE$GQ_TODCBASE in your base image - no, not from HP.

[sergeybo...@gmail.com]

пятница, 24 мая 2013 г., 1:54:56 UTC+4 пользователь hb написал:

Could you send a link to that program?

[hb]

On 01/18/2014 11:22 AM, sergeybo...@gmail.com wrote:
> пятница, 24 мая 2013 г., 1:54:56 UTC+4 пользователь hb написал:

>> If you don't want to update with an UPDATE kit, you can get a small
>>
>> program to update EXE$GQ_TODCBASE in your base image - no, not from HP.
>
> Could you send a link to that program?
>

http://www.vms2linux.de/settodcbase/settodcbase.zip (which contains an
Alpha/VMS and Linux/Debian-32bit executable).

[Rod Regier]

Any change I can get the source and an I64/VMS binary for the reset utility?

[hb]

On 09/08/2017 07:17 PM, Rod Regier wrote:
> Any change I can get the source and an I64/VMS binary for the reset utility?
>

Are you looking for settodcbasei64.zip? Same place, only an executable
image, aka binary.

[Rod Regier]

Got the alternate I64 binary download, thanks.

I'll have to give it a try on my test system.

\\

BTW, applying V/I64 8.4 Update V12 only takes the SYS$BASE_IMAGE.EXE
file up to a creation date of 2014. So without any further action a
server running that patch level would likely be back to getting a
date/time prompt on startup commencing in 2019.

[Rod Regier]

I have subsequently discovered that applying V/I64 8.4 SYS V7 takes the SYS$BASE_IMAGE.EXE file up to a creation date of 14-Jun-2016.

So apparently the SYS patch kit is one of the vehicles to get a more recent
SYS$BASE_IMAGE.EXE file deployed.

[Rod Regier]

HB, any instructions on how to use the supplied utility?

Tried these two ways w/o apparent success:

!!$ run settodcbase.exe
-e-insarg, supply an I64 base image file.
!!$ sss == "$dSa0:[dymax]settodcbase.exe "
!!$ sss SYS$SYSDEVICE:[VMS$COMMON.SYS$LDR]SYS$BASE_IMAGE.EXE
setTODCBASE, version 0.9
-e-openerr, errno: 65535 vaxc$errno: %X1828a

This code fragment from elsewhere implies %X1828a means
the file is open for write already.

http://nixforums.org/about73466-1.html

$ if status .eq. %x1828a
$ then ! %RMS-E-FLK
$ write sys$output "''p1' is write locked"

Looks like the file in question is open whenever the OpenVMS O/S is booted.

!!$ sho dev sys$sysdevice:/file/output=rr.rr
!!$ sea rr.rr base
00000000 [VMS$COMMON.SYS$LDR]SYS$BASE_IMAGE.EXE;1

Unless you booted from a different disk, unclear how you could update
SYS$BASE_IMAGE.EXE if it is continuously open during O/S execution.

Thanks

[hb]

On 09/12/2017 09:33 PM, Rod Regier wrote:
> HB, any instructions on how to use the supplied utility?
>
> Tried these two ways w/o apparent success:
>
> !!$ run settodcbase.exe
> -e-insarg, supply an I64 base image file.
> !!$ sss == "$dSa0:[dymax]settodcbase.exe "
> !!$ sss SYS$SYSDEVICE:[VMS$COMMON.SYS$LDR]SYS$BASE_IMAGE.EXE
> setTODCBASE, version 0.9
> -e-openerr, errno: 65535 vaxc$errno: %X1828a

Although not recommended, this works for me:

$ mc []settodcbase SYS$COMMON:[SYS$LDR]SYS$BASE_IMAGE.EXE
setTODCBASE, version 0.9
todcbase was 1-JAN-2016 00:00:00.00
todcbase changed to 12-SEP-2017 23:31:58.15
$

I would alway make a local copy, modify the copy and write it back.

You may even want to check the result:

$ dump SYS$BASE_IMAGE.EXE/out=modified.txt
$ dump sys$loadable_images:SYS$BASE_IMAGE.EXE/out=original.txt
$ diff original.txt modified.txt /ignore=header
************
File DISK$USER:[USER]original.txt;1
8235 00000000 00000000 FFFFFF93 0906B800 00000000 00000000 00B027AF
D22D0000
8236 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
******
File DISK$USER:[USER]modified.txt;1
8235 00000000 00000000 FFFFFF93 0906B800 00000000 00000000 00B20FA6
D88D9103
8236 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
************

Number of difference sections found: 1
Number of difference records found: 1

DIFFERENCES /IGNORE=(HEADER=2)/MERGED=1-
DISK$USER:[USER]original.txt;1-
DISK$USER:[USER]modified.txt;1
$

>
> This code fragment from elsewhere implies %X1828a means
> the file is open for write already.
>
> http://nixforums.org/about73466-1.html
>
> $ if status .eq. %x1828a
> $ then ! %RMS-E-FLK
> $ write sys$output "''p1' is write locked"
>
> Looks like the file in question is open whenever the OpenVMS O/S is booted.
>
> !!$ sho dev sys$sysdevice:/file/output=rr.rr
> !!$ sea rr.rr base
> 00000000 [VMS$COMMON.SYS$LDR]SYS$BASE_IMAGE.EXE;1

Dunno why it is open on your system, here (OpenVMS V8.4-2L1) it is not:

$ sho dev sys$sysdevice:/file/output=rr.rr
$ sea rr.rr base
NET$ACP 0000041B [VMS$COMMON.SYSEXE]NET$LOCAL_NAME_DATABASE.DAT;1
$

[Rod Regier]

I had a look at my installed base which is a mixture of systems running
HP OpenVMS/Alpha and HP OpenVMS/I64.

The Alpha sites (mix of 7.3-2, 8.3 and 8.4) all had the file *open*
and on all the I64 sites it was closed.
I'm not aware of having taken any variant action on the Alpha sites
to make them behave differently in this regard.

Apparently that was a behavior change coded as part of the Alpha to I64 port.

So on the Alphas I apparently would need to:

- Clone the file to a higher version w/same protections using BACKUP/IGN=INTE
- Use the utility to update the clone

Subsequent reboots will use the updated file producing the desired behaviour
(bypassing the date/time prompt).

Given the critical nature of the system file involved, probably safer to
use the same algorithm for OpenVMS/I64 servers too.

In both cases that gives an easier fallback if things go sideways later.

\\

General comments:

My experimentation suggests that the SYS$BASE_IMAGE.EXE behavior was coded
as a date/time consistency check. It prompts for the date and time if
- the stored date/time pre-dates the SYS$BASE_IMAGE.EXE module date
- The stored date/time post-dates by more than
5 years the SYS$BASE_IMAGE.EXE module date

\\

I would speculate that whoever coded the 5 year value presumed that the OpenVMS instance would be indefinitely receiving patching and/or version upgrades.

That turns out *not* to be a universal circumstance in the long term for sites running older versions of OpenVMS for which sustaining engineering is no longer extant.

HP Sustaining Engineering was concluded on 31-Dec-2016
for the very highest version of HP OpenVMS/Alpha - V8.4.
Sustaining engineering was also earlier concluded for versions of
HP OpenVMS/I64 *prior* to V8.4.

http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623087


Since patches apparently flow from HP Sustaining Engineering
more sites over time will experience this behavior.

[hb]

On 09/13/2017 03:04 PM, Rod Regier wrote:
> I had a look at my installed base which is a mixture of systems running
> HP OpenVMS/Alpha and HP OpenVMS/I64.

The problem with the 5 years is an I64 only problem. There is some
discussion on this problem on
https://community.hpe.com/t5/System-Management/Hp-Integrity-rx2620-Date-Time-issue/td-p/4344487

> So on the Alphas I apparently would need to:

Nothing.

[Rod Regier]

Curious. I can demonstrate the problem on a bench Alpha server no problem.

[Rod Regier]

Looking at the kindly supplied referenced article,
apparently there are major differences in how this is handled on
Alpha and I64.

"On Integrity servers, OpenVMS does NOT write the time stamp to the system disk when the SET TIME command is issued with no arguments. On Integrity servers, OpenVMS depends on the hardware clock provided on the platform. SET TIME on Integrity updates the EXE$GQ_TODCBASE and EXE$GQ_SAVED_HWCLOCK cells in memory, but nothing gets written out to the system disk."

So Alpha avoids it by writing to the system disk.

I was conducting my Alpha testing using a read-only optical disk,
not realizing the Alpha write behaviour.

That explains why I can reproduce the issue on a read-only Alpha
configuration but my old version Alpha site customers are
*not* reporting the issue.

\\

Since I can't guarantee the last time a SET TIME command was performed on
my installed base Alpha sites I think I'll write a remote execution script to simply perform a SET TIME on each of them to guarantee the high water mark.

[hb]

On 09/13/2017 03:45 PM, Rod Regier wrote:
> Curious. I can demonstrate the problem on a bench Alpha server no problem.

Looks like a different problem to me. On Alpha the TODCBASE data in the
base image is updated. It usually was done with a "set time", I don't
know whether that changed. And as far as I remember, that command was
issued in the shutdown procedure.

PS: The settodcbase.exe image, no matter for which platform you have it
and run it, only works with ELF images.

[Stephen Hoffman]

On 2017-09-13 13:04:58 +0000, Rod Regier said:

> I would speculate that whoever coded the 5 year value presumed that the
> OpenVMS instance would be indefinitely receiving patching and/or
> version upgrades.

Too clever by half. It's a test for a valid system time returned from
the hardware, and a test that would have involved a rather lively
discussion in many conceivable design or code review meetings.

At some point, VSI is going to have to look at online patch checks and
reporting support information status to the system manager, but this
design and this check for a valid system time isn't it.

Some Alpha systems have firmware that returns wacky values, and some
systems have had other operating systems save their time in a format
that OpenVMS doesn't recognize, or the system time is wrong because the
coin cell clock batteries are only good for five or ten years, and the
Dallas chips also fail. As an example of a bogus boot time,
AlphaStation XP1000 SRM is old and is buggy, and that SRM can't be
updated, and older versions of SRM had a bug that returns time values
in a format that is completely out-of-spec for what SRM console was
supposed to return; values for the time that OpenVMS wasn't expecting.
That case has been fixed in current patches.

> That turns out *not* to be a universal circumstance in the long term
> for sites running older versions of OpenVMS for which sustaining
> engineering is no longer extant.

Those "older" OpenVMS releases might be familiar and comfortable but
can still manifest latent problems and issues. not the least of which
is severely down-revision crypto, and known-insecure network services.
Attempts to create connections to or from releases prior to a fairly
recent IP patch will be rejected by other common systems, for instance.
There are more than a few known CVEs cases that OpenVMS is vulnerable
— the security marketing and CVE "count" web page over at VSI is a
gross misrepresentation and one that does a disservice to VSI, to
OpenVMS, and to OpenVMS customers — and there are other cases where
OpenVMS systems can be used as part of DDoSes against other network
denizens.

If this were a notification of the end of support, it'd be better off
issued as a message at the boot. Which would have been easier than
coding a time check of an image build date at boot. And much more
clear than forcing a prompt of the time at boot.

> Since patches apparently flow from HP Sustaining Engineering more sites
> over time will experience this behavior.

IIRC, current UPDATE patches removed the validity check for the system
time, or at least reworked it. Well, yeah, but that's the way of
running fossil versions under the delusions upgrades don't fix problems
that you have and just don't know about (yet).

I've probably heard every excuse and every justification for running
old releases of OpenVMS and layered products, too. Those folks that
run do those older configurations are simply getting better at
disconnecting their servers from all other computing, and never
changing anything; unchanging hardware or software or system time or
otherwise. For the rest of us, the bill for falling behind on
patches and system and app version upgrades and migrations inevitably
and eventually comes due. Sometimes in very strange and unpredictable
ways. Sometimes — such as with connections and security being a
moving target, and as even supposedly-isolated systems are increasingly
being exposed to attackers — in very predictable ways.

TL;DR: get to current UPDATE patches on HPE OpenVMS V8.4, with plans
for or deployments of VSI OpenVMS releases and eventually to port to
VSI OpenVMS on x86-64. Or for staff at those sites, have plan to
retire or re-hire elsewhere before the bill comes due and the mess
becomes un-ignorable. We're on an upgrade treadmill now, and the
remaining static and never-upgrade software installations are embedded
and disposable.

ps: VSI folks: you're missing a huge marketing opportunity with your
pricing, if I understand what you're licensing for the prices and
packaging that you're now quoting.

[Rod Regier]

Steven:

I've been replacing CR2032 coin batteries and Dallas clock battery chips on Alphas for over a decade :-) DS10 and DS15 use the Dallas.

As a community service the Dallas equivalent can be non-exclusively sourced here as new from in-depth stock

https://www.digikey.com/products/en?keywords=DS12887%2B-ND

[Rod Regier]

BTW, the HPE spec coin TOY battery for the RX2600 is the semi-exotic BR2330.

Before changing the battery use the offline EFI System Configuration menu
to examine the stored date and time. If the stored value is good your issue
probably lies in the software issue we're discussing.

HPE note on same the RX2600 TOY battery:

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c03115627&sp4ts.oid=447335

[Stephen Hoffman]

On 2017-09-13 15:01:21 +0000, Rod Regier said:

> Steven:

I'll assume that was aimed at me, as I've not noticed a reply from
Steven in this thread.

> I've been replacing CR2032 coin batteries and Dallas clock battery
> chips on Alphas for over a decade :-) DS10 and DS15 use the Dallas.

Coin cells are common in HPE Integrity servers, and are used in some
Alpha systems. Like all gear, they eventually fail.

Sometimes consoles fail in surprising ways, such as the longstanding
bug in the Alpha console design around the console selection reverting
SRM to AlphaBIOS/ARC.

Preemptively swapping coin cell batteries or Dallas chips is akin to
keeping software patches and versions current. Those practices can
smooth out expenses and reduce outages, but not everybody invests in
the associated effort. Running Alpha gear that's fifteen or twenty
years old or more can be great fun for hobbyists, but it's a tougher
sell for businesses. Budgeting for upgrades and support and
replacements is an ongoing cost, but preferable as an outage on a
critical system is more disruptive and more expensive for many sites.
Requirements for data security are pushing more than a few hardware and
software upgrades and patches, too. The x86-64 port will likely
reduce the numbers of remaining commercial installations of Alpha
substantially, and will be the replacement path for "more recent" Alpha
systems, and for Integrity servers. Cheaper, too.

[Rod Regier]

Developing news:

Clocks on OpenVMS apparently work well when the SYS$BASE_IMAGE.EXE file
can be updated to highwater by SET TIME command. SET TIME is also executed during shutdown even if a sysmgr didn't perform a SET TIME themselves.

This was broken in OpenVMS/I64 by keeping the SYS$BASE_IMAGE.EXE file
continuously open during operating system execution.

HPE apparently quietly fixed this issue with V/I64 8.4 SYS V7 patch.
Under that patch SYS$BASE_IMAGE.EXE is now again closed during operating system execution. That restores online write access to the critical file.

Apparently that same patch effect is also in VSI OpenVMS V8.4-2L1.
No open SYS$BASE_IMAGE.EXE file there.

TL;DR: Sites running V/I64 below "8.4 plus SYS V7 patch" could find value in HB's update program.

[Bob Koehler]

In article <548625f8-8477-4a6f...@googlegroups.com>, Rod Regier <rre...@dymaxion.ca> writes:
> Looking at the kindly supplied referenced article,
> apparently there are major differences in how this is handled on
> Alpha and I64.
>

> "On Integrity servers, OpenVMS does NOT write the time stamp to the system =
> disk when the SET TIME command is issued with no arguments. On Integrity se=
> rvers, OpenVMS depends on the hardware clock provided on the platform. SET =
> TIME on Integrity updates the EXE$GQ_TODCBASE and EXE$GQ_SAVED_HWCLOCK cell=

> s in memory, but nothing gets written out to the system disk."
>
> So Alpha avoids it by writing to the system disk.
>
> I was conducting my Alpha testing using a read-only optical disk,
> not realizing the Alpha write behaviour.
>
> That explains why I can reproduce the issue on a read-only Alpha

> configuration but my old version Alpha site customers are=20

> *not* reporting the issue.
>
> \\
>
> Since I can't guarantee the last time a SET TIME command was performed on

> my installed base Alpha sites I think I'll write a remote execution script =
> to simply perform a SET TIME on each of them to guarantee the high water ma=
> rk.

There is such a command in SYSHUTDWN.COM. VAX also writes to the
disk and that command has been in there for a very long time.

[johnwa...@yahoo.co.uk]

I thought there was a SET TIME in there too, since the era of the
Ark if not before. But I also have a vague recollection that there
may be circumstances when it's not executed (e.g. when the system
isn't shut down except in what amounts to an uncontrolled manner).

I even have a vague recollection of using SYSMAN to do a
clusterwide SET TIME on a periodic basis, so the problem doesn't
become visible.

Not perfect, by any means. But not much is perfect.

[Rod Regier]

sea SYS$SYSTEM:SHUTDOWN "set time"

SYS$COMMON:[SYSEXE]SHUTDOWN.COM;1

$SET TIME="''f$time()'"
$SET TIME="''f$time()'"

\\

http://h41379.www4.hpe.com/doc/83final/9996/9996pro_223.html

SET TIME

Resets the system clock, which is used as a timer to record intervals between various internal events and as a source clock for displaying the time of day.

Note
"Alpha systems maintain system time during power failures and system down time. When a system is booted, if the time is known to be earlier than the time value of the last time modification, or greater than five years in the future, you are prompted to enter the time at the console prompt."

[Stephen Hoffman]

On 2017-09-13 19:13:21 +0000, Rod Regier said:

> sea SYS$SYSTEM:SHUTDOWN "set time"

That writes the current time to the saved time. Which neither avoids
nor resolves the problems that were referenced earlier, such as battery
failures or other operating systems or the SRM problems that exist on
some Alpha systems. The approach used by the OpenVMS bootstrap for
timekeeping predates ubiquitous networking and network services, but
here we are. But then I've previously grumbled about how IP should be
a fundamental and always-present part of the base installation.