Changed Boot behavior on XP1000 since 2013

[MichaelM]

XP1000, VMS V7.2-1 or V7.3-2, latest Firmware V5.9-1, SYSGEN-
TIMEPROMPTWAIT=65535 (default), battery ok.

Since 2013 all machines booting up from "Power off" or after doing
">>> INIT" on the boot prompt stop booting and ask for the system time
DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until
login normally. All XP1000 boot normally too if power wasn't off or if
no >>> INIT was given on the boot prompt.

Only XP1000 are infected, our DS10 and some other alphas boot as
expected.

You can force the machines to boot through with another TIMEPROMPTWAIT
value, but than the system time will be inaccurate (time of last boot
or of last $SET TIME).

It seems that any time from 2013 on is an invalid time for the
processors time-of-year clock and this clock becomes important after
"power off" or >>>INIT.

[MG]

On 18-jan-2013 14:47, MichaelM wrote:
> Only XP1000 are infected, our DS10 and some other alphas boot as
> expected.
>

> [...]

>
> It seems that any time from 2013 on is an invalid time for the
> processors time-of-year clock and this clock becomes important after
> "power off" or >>>INIT.

It's strange that more than one XP1000s (correct?) were affected,
or /infected/ (in case of a rare/unlikely virus...?), otherwise I
would have guessed it's an NVR/TOY (or the like) battery issue...

- MG

[Steven Schweda]

Hmmm. I haven't booted my main XP1000 system since
1-SEP-2012, so my sample is restricted to my
spare/experimental XP1000 system, but it does seem always to
ask, now. It probably has done for a while, possibly since
New Year's Day, but I've probably assumed that it was the
usual interference from Tru64, which I also run on that
machine from time to time. (The fact that I couldn't
remember having run Tru64 on it lately means less and less
every day, so I didn't think too hard about any unexpected
"Please enter date and time (DD-MMM-YYYY HH:MM)" query.)

I'll start holding my breath, waiting for HP to provide
the firmware fix. (Do you suppose that they still employ (or
could find) anyone who would be able to do the work, even if
they wanted it done?)

> Only XP1000 are infected, our DS10 and some other alphas boot as
> expected.

One more (firmware) reason to shun these otherwise mostly
attractive systems.

[Phillip Helbig---undress to reply]

In article
<5feb33d2-8018-42bb...@a15g2000vbf.googlegroups.com>,

MichaelM <michae...@rwe.com> writes:

> XP1000, VMS V7.2-1 or V7.3-2, latest Firmware V5.9-1, SYSGEN-
> TIMEPROMPTWAIT=65535 (default), battery ok.
>
> Since 2013 all machines booting up from "Power off" or after doing
> ">>> INIT" on the boot prompt stop booting and ask for the system time
> DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until
> login normally. All XP1000 boot normally too if power wasn't off or if
> no >>> INIT was given on the boot prompt.
>
> Only XP1000 are infected, our DS10 and some other alphas boot as
> expected.

My last XP1000 boot was 10-JAN-2013, but no power off. I might have
done an INIT and vaguely recall an unexpected time prompt (but I'm not
sure and/or that could have been on another machine with bad battery and
power cycle).

> It seems that any time from 2013 on is an invalid time for the
> processors time-of-year clock and this clock becomes important after
> "power off" or >>>INIT.

Does anyone else see this? Is there a fix?

[Ian Miller]

What patches do you have installed?

[Steven Schweda]

On Jan 18, 11:38 am, Ian Miller <g...@uk2.net> wrote:
> What patches do you have installed?

Patches? Patches? I can't get any stinking patches!
(For VMS Alpha V8.3. And precious few for V8.4) Can I?

Which patch fixed the problem?

[BillPedersen]

You can get a recent set of consolidated patches with the download of the Hobbyist OpenVMS Alpha V8.4. Go to the Hobbyist Page, register and ask for a download link for Alpha:

http://www.openvms.org/pages.php?page=Hobbyist

Bill.

[David Froble]

Are such patches available only for V8.4, or is V8.3 patches available.

After some of the things I've read, I'm not sure I want to leave V8.3.
And I also support "made in USA" :-)

(Please don't miss the smiley, I don't handle abuse well anymore.)

[Steven Schweda]

> Are such patches available only for V8.4, or is V8.3 patches available.

When last I looked, which was a while ago, only V8.4 and a
big update kit for it were there. My main Alpha system runs
V8.3, and my primary IA64 system runs V8.3-1H1, and I was in
no particular hurry to change them, so the current hobbyist
patch availability, while better than nothing, is not so
useful for me as the old one was. (The old, carefree,
"anything anytime" access scheme nicely involved jumping
through no hoops (like requesting renewed credentials), and
lent itself to the use of Wget, all of which generally leaves
me longing for the good-old days, more even than usual.)

[BillPedersen]

The current availability is just the most recent patch rollup for the current release of VMS on each architecture. I have started a discussion with my contacts to see if they might be able to do a similar thing for one prior version.

As far as the patch access mechanism and hoops, not much is expected to happen there. The access is controlled by people in the Services Organization at HP and not Engineering. And as you should be aware, all of the different OS environments, including HP-UX are affected, not just VMS. Not much is going to change there I suspect.

Bill.

[David Froble]

BillPedersen wrote:

> The current availability is just the most recent patch rollup for the current release of VMS on each architecture. I have started a discussion with my contacts to see if they might be able to do a similar thing for one prior version.
>
> As far as the patch access mechanism and hoops, not much is expected to happen there. The access is controlled by people in the Services Organization at HP and not Engineering. And as you should be aware, all of the different OS environments, including HP-UX are affected, not just VMS. Not much is going to change there I suspect.
>
> Bill.

It's the way things are today. Everyone is expected to be running only
the latest version of anything. Windows 8 anyone?

My PC is running Windows 2000 Pro, and the e-mail client is Thunderbird
V2... They are up to version 17-19 or thereabouts, and the new versions
will not run on Windows 2000. Maybe not on XP either, don't know.

Not too much sympathy these days for anyone who wants to keep something
that isn't broke.

I'm really getting into pulling a copy down to my system(s) of anything
that I might be interested in. The internet experience isn't to be
trusted. Things disappear.

[Paul Sture]

In article <kdfqfb$64h$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> wrote:

> It's the way things are today. Everyone is expected to be running only
> the latest version of anything. Windows 8 anyone?
>

<snip>

>
> I'm really getting into pulling a copy down to my system(s) of anything
> that I might be interested in. The internet experience isn't to be
> trusted. Things disappear.

I noticed this when I was still stuck on the PPC Mac architecture. More
and more stuff was going forward with Intel versions only, and the
original PPC binaries were disappearing. Web sites with useful code
snippets disappear too.

I have become quite a pack rat with stuff I find useful.

--
Paul Sture

[Richard B. Gilbert]

On 1/20/2013 3:03 AM, Paul Sture wrote:
> In article <kdfqfb$64h$1...@dont-email.me>,
> David Froble <da...@tsoft-inc.com> wrote:
>
>> It's the way things are today. Everyone is expected to be running only
>> the latest version of anything. Windows 8 anyone?

I'm still using Windows XP Service Pack 3 (I think it's 3). It does
what I need and it works. I traveled a long bumpy and road to get there
and I'm not eager make any changes. What I have works and it will take
one hell of an incentive to get me to upgrade.

>>
> <snip>

[Joukj]

I see the same on some of my alpha's since 1-JAN-2013.
Definitely one of my XP1000 does it (on the other 2 I have not seen it
yet, but I did not do a power-cycle on those, only a "reset" by pressing
the button).
I see the same on a DPWS500au and a AlphaServer 2000 4/200, but not on
the boot-member of my cluster, a DPWS600au (I even power-cycled this
machine)
All 6 of machines form a cluster with one boot-member and 5 satelites
booting form the same system-disk. It is a OpenVM8.4 system with all
available patches installed.

When I mentioned this to HP-support, they blamed the battery. I have not
had time to replace them to see if they are right. But I'm still
wondering why 3 systems failed on this point at the same time (since
1-jan-2013).

Jouk

[Bill Gunshannon]

In article <9M2dncyZ973h2WHN...@giganews.com>,

I've got two systems still running Vista. If it ain't broke, don't
fix it.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Mazzini Alessandro]

"Joukj" wrote in message news:kdj504$3jf$1...@speranza.aioe.org...

MichaelM wrote:
> XP1000, VMS V7.2-1 or V7.3-2, latest Firmware V5.9-1, SYSGEN-
> TIMEPROMPTWAIT=65535 (default), battery ok.
>
> Since 2013 all machines booting up from "Power off" or after doing
> ">>> INIT" on the boot prompt stop booting and ask for the system time
> DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until
> login normally. All XP1000 boot normally too if power wasn't off or if
> no >>> INIT was given on the boot prompt.
>
> Only XP1000 are infected, our DS10 and some other alphas boot as
> expected.
>
> You can force the machines to boot through with another TIMEPROMPTWAIT
> value, but than the system time will be inaccurate (time of last boot
> or of last $SET TIME).
>
> It seems that any time from 2013 on is an invalid time for the
> processors time-of-year clock and this clock becomes important after
> "power off" or >>>INIT.
I see the same on some of my alpha's since 1-JAN-2013.
Definitely one of my XP1000 does it (on the other 2 I have not seen it
yet, but I did not do a power-cycle on those, only a "reset" by pressing
the button).
I see the same on a DPWS500au and a AlphaServer 2000 4/200, but not on
the boot-member of my cluster, a DPWS600au (I even power-cycled this
machine)

//////////////////////////////////////////////////////////////////////////////////////

Just tried to doublecheck on a pws500au , and the boot was normal (even if
maybe
slightly slower than usual). 8.4 on it, with the usual hobbyist patches. No
cluster
configured at the moment.

What version of openvms are you using on the pws500au ?latest firmware ?

Alessandro

[MichaelM]

>              Jouk- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -


Even with the lastest V7.3-2 patch (vms732_update-v2500) the V7.3-2-
XP1000 system asks for a new time value.
It seems to be VMS version independent (our V7.2-1 and V7.3-2 and your
V8.4), but hardware / firmware dependent.
The batteries were the first things we have checked.

[Phillip Helbig---undress to reply]

In article <kdj504$3jf$1...@speranza.aioe.org>, Joukj

<jo...@hrem.nano.tudelft.nl> writes:

> > Since 2013 all machines booting up from "Power off" or after doing
> > ">>> INIT" on the boot prompt stop booting and ask for the system time
> > DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until
> > login normally. All XP1000 boot normally too if power wasn't off or if
> > no >>> INIT was given on the boot prompt.
> >
> > Only XP1000 are infected, our DS10 and some other alphas boot as
> > expected.
> >
> > You can force the machines to boot through with another TIMEPROMPTWAIT
> > value, but than the system time will be inaccurate (time of last boot
> > or of last $SET TIME).
> >
> > It seems that any time from 2013 on is an invalid time for the
> > processors time-of-year clock and this clock becomes important after
> > "power off" or >>>INIT.
> I see the same on some of my alpha's since 1-JAN-2013.
> Definitely one of my XP1000 does it (on the other 2 I have not seen it
> yet, but I did not do a power-cycle on those, only a "reset" by pressing
> the button).
> I see the same on a DPWS500au and a AlphaServer 2000 4/200, but not on
> the boot-member of my cluster, a DPWS600au (I even power-cycled this
> machine)

I noticed my ALPHAstation 500/500 satellite booted slowly (I normally
boot it without the console). It's not the first boot this year, but
then I tend to switch it on and come back a bit later. Maybe it is
waiting for the time then continuing after timing out.

> When I mentioned this to HP-support, they blamed the battery. I have not
> had time to replace them to see if they are right. But I'm still
> wondering why 3 systems failed on this point at the same time (since
> 1-jan-2013).

Someone here mentioned the changed behaviour even though the battery was
good.

[DaveG]

On Friday, January 18, 2013 7:47:21 AM UTC-6, MichaelM wrote:
> XP1000, VMS V7.2-1 or V7.3-2, latest Firmware V5.9-1, SYSGEN- TIMEPROMPTWAIT=65535 (default), battery ok. Since 2013 all machines booting up from "Power off" or after doing ">>> INIT" on the boot prompt stop booting and ask for the system time DD-MMM-YYYY MM:HH. IF you set the time back to 2012 they boot until login normally. All XP1000 boot normally too if power wasn't off or if no >>> INIT was given on the boot prompt. Only XP1000 are infected, our DS10 and some other alphas boot as expected. You can force the machines to boot through with another TIMEPROMPTWAIT value, but than the system time will be inaccurate (time of last boot or of last $SET TIME). It seems that any time from 2013 on is an invalid time for the processors time-of-year clock and this clock becomes important after "power off" or >>>INIT.

I was asked for the system time (same as the others here) this morning on an Alpha 4000 after a power down restart. I did set the date as 22-JAN-2013 and the boot continuded normally. I thought battery too then stumbled on this thread.

Don't recall this being a problem before 2013 rung in.

[Hans Vlems]

I saw this happen on a Digital Server 5305 5/533. Now this is not a
supported VMS system so I didn't do anything about it.
A reboot without a powering off the system will still get you to the
date and time prompt.
Something else that I noticed on this system: in ARC the date is set
to 24 January 2073.
The 5305 runs the last issued firmware for the 5305 and is the same
for the Alpha Server 1200.
I'll check my other systems this evening. All I can say is that my
DS20E does not show this behaviour.
Hans

[Jan-Erik Soderholm]

Same with my customers D20e's. I havn't checked but I do not
expect my DS25 to ask for a date either.

Everything right now points to some "feature" in older firmware
versions where it can't handle dates that are too "new", right ?

Jan-Erik.

[Hans Vlems]

On 25 jan, 12:12, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:

> Jan-Erik.- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

So far I've seen this:

The Digital Server 5305 5/533 as well as the 5/400 suffer from this
problem.
The Alpha Server 1200 (again both models) too. These systems are at
their latest firmware V6.0-4 (AFAIK).
My XP1000 boots normally as does the AlphaServer DS10 (V7.3-1) and the
DS20E (V7.3-1), no problems there.

On both the AlphaServer 1200 and the Digital Server 5305 I tried ARC
and had a look at the date kept in there.
It showed the year 2073, the day and month were set at expected values
(24, 25 and Jannuary).
Next I set the year to 2013 and saved that value (F10) en left that
menu. Next, press the cycle button and VMS
booted alright. Power cycling removed the correct date setting and the
VMS date and time prompt appeared again.

I don't think this is a dead battery problem, all my Alpha's have
different ages and different run times.
They all run ARC version 5.70 and I believe that's where the problem
is.

Any suggestions for a remedy or do I have to learn an live with this?
I suppose there are no AlphaServer 1200's left
covered by a maintenace support contract, right?


Hans

[Hans Vlems]

On 25 jan, 12:12, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:

> Jan-Erik.- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

No the date found in the ARC console today was January 25 2073
And the year will go as high as 2080 before it returns to 1908 again.
I've tried setting the value to 2013 but that isn't kept correctly.
'So I'll try and set the year to 1985 and see what happens.
Hans

[Michael Moroney]

A little birdie has a suggestion:

This has been seen on v8.3 Itanium, too, on EACH AND EVERY
ONE of <a customer's> 14 OpenVMS systems, but over a YEAR
ago.

The fix FOR THIS was the SYS updates from Oct 2011; when we
installed this set, it was all fixed:

VMS83I_PCSI-V0400.ZIPEXE;1
3498/3504 30-SEP-2011 17:29:22.00
VMS83I_SYS-V1800.ZIPEXE;1
34108/34112 25-OCT-2011 18:33:14.00
VMS83I_UPDATE-V1500.ZIPEXE;1
210783/210784 2-NOV-2011 18:41:10.00

It can't be said that it's the same issue, but it sure looks
suspiciously similar.

[David Froble]

Been reading this thread, and curiosity finally got to me. So I did
some testing.

DS20, EV6, single processor, firmware V6.9 or something like that, I
didn't write it down. Not running for several months. Powered it up,
booted VMS, no date and time prompt.

So, to be complete, at least for me ...

AlphaServer 800, 500 MHz, don't know if that's EV5 or EV56. Shut it
down, powered it down, powered it up, booted VMS, and again no date and
time prompt.

That's my survey, all the AlphaStation 200s are busted :-(

Oh, VMS 8.3, if it matters ...

Oh, oh, didn't try the DS10L ...

Dave

[Hans Vlems]

> Dave- Tekst uit oorspronkelijk bericht niet weergeven -

>
> - Tekst uit oorspronkelijk bericht weergeven -

I didn't check my AlphaServer 800's and AlphaServer 300 yet.
The AS800 is an EV5. Does that mean that the EV56 systems are
affected?

The next question : Is there a fix / will there be a fix for these
elderly systems?

Hans

[Hans Vlems]

On 26 jan, 03:09, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:

> hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>
> >In article

> ><5feb33d2-8018-42bb-a06c-61f749581...@a15g2000vbf.googlegroups.com>,

> >MichaelM <michael.me...@rwe.com> writes:
> >> It seems that any time from 2013 on is an invalid time for the
> >> processors time-of-year clock and this clock becomes important after
> >> "power off" or >>>INIT.
> >Does anyone else see this?  Is there a fix?
>
> A little birdie has a suggestion:
>
>     This has been seen on v8.3 Itanium, too, on EACH AND EVERY
>     ONE of <a customer's> 14 OpenVMS systems, but over a YEAR
>     ago.
>
>     The fix FOR THIS was the SYS updates from Oct 2011; when we
>     installed this set, it was all fixed:
>
> VMS83I_PCSI-V0400.ZIPEXE;1
>                             3498/3504    30-SEP-2011 17:29:22.00
> VMS83I_SYS-V1800.ZIPEXE;1
>                            34108/34112   25-OCT-2011 18:33:14.00
> VMS83I_UPDATE-V1500.ZIPEXE;1
>                           210783/210784   2-NOV-2011 18:41:10.00
>
>     It can't be said that it's the same issue, but it sure looks
>     suspiciously similar.

Michael,
what were the contents of these kits and was there an Alpha equivalent
too at the time?
Hans

[hb]

On 01/26/2013 03:09 AM, Michael Moroney wrote:
> A little birdie has a suggestion:
>
> This has been seen on v8.3 Itanium, too, on EACH AND EVERY
> ONE of<a customer's> 14 OpenVMS systems, but over a YEAR
> ago.
>
> The fix FOR THIS was the SYS updates from Oct 2011; when we
> installed this set, it was all fixed:
>
> VMS83I_PCSI-V0400.ZIPEXE;1
> 3498/3504 30-SEP-2011 17:29:22.00
> VMS83I_SYS-V1800.ZIPEXE;1
> 34108/34112 25-OCT-2011 18:33:14.00
> VMS83I_UPDATE-V1500.ZIPEXE;1
> 210783/210784 2-NOV-2011 18:41:10.00
>
> It can't be said that it's the same issue, but it sure looks
> suspiciously similar.

Different issue. As noted somewhere else, on I64 the "$ SET TIME" did
not (and maybe still does not) update the variable EXE$GQ_TODCBASE in
the base image file. The above "fix" contains a base image with a more
recent date in that cell: different architecture, different cause for a
similar problem. There is also a SMOP available on request - no not from
HP - to do just that: write the current date into the I64 base image.

[Volker Halle]

Cross-reference:

This issue is also being discussed in the HP Support Forums:

http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231

Volker.

[Hans Vlems]

On 26 jan, 11:38, Volker Halle <volker_ha...@hotmail.com> wrote:
> Cross-reference:
>
> This issue is also being discussed in the HP Support Forums:
>

> http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000...
>
> Volker.

It sure is, but no direction for a solution, right?
Or should we put a $ SET TIME command in SYSHUTDWN.COM?

Hans

[VAXman-]

I'd all but forgotten about that HP forum. Thanks.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[VAXman-]

Just use SYS$SYSTEM:SHUTDOWN.COM to shutdown your system(s). There's a
$ SET TIME in there already.

[Volker Halle]

I've posted instructions over in the HP Support Forum on how to find
the date & time values as read from the DALLAS DS1287 TOY clock during
the SET TIME operation (routine READ_SYSTEM_BBW). This first attempt
to further diagnose this problem tries to determine, if the date &
time provided by the TOY clock are correct. If they are, this would be
an OpenVMS problem. If they aren't, it would be a HW/Firmware problem
and chances for a solution would be pretty low..

http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231

Don't be afraid of using XDELTA ;-)

Please report your results for the various Alpha systems affected by
this problem, please include the SRM firmware version.

Volker.

[Hans Vlems]

On 26 jan, 15:17, VAXman- @SendSpamHere.ORG wrote:

Well actually Brian my remark was somewhat cynical actually.
This is the first time something happened to my VMS systems which I
fear has a soluation way out of my scope.
Over the years I got to feel comfortable with several DEC built
systems. The PDP 11/44, the VAX 8650, the VAX 8550,
VAXstation 4000/90A and the AlphaServer 1200 (including its niece the
Digital Server 5305).
There are two systems I run frequently, ARGON (VAXstation 4000/90A)
and even more often OSMIUM ( Digital Server 5305).
Reliable, have them for 12 years or so and all I had to do is just
turn them on.
Now suddenly the AS1200 class machines developed a sudden urge to have
somebody else to look at the clock.

OK, for me it's just a hobby, right?
Hans

[MichaelM]

Now we are able to read the hwc on XP1000; :

>>> e -b toy:0 -> secs
e -b toy:2 -> mins
e -b toy:4 -> hrs
e -b toy:7 -> date
e -b toy:8 -> month
e -b toy:9 -> year offset
or together without secs
e toy:2 -w -n 3
shows 4 (-n 3) halfwords (-w) beginning with address 2 (toy:2).

So we have made some tests on our XP1000 and have noticed:

>>> e toy:2 -w -n 3 shows the hwc time correct beginning with minutes and using year 2000 as base time (tested for years 2012 and 2013).
After an >>> INIT on the boot prompt or after a power off (poweroff
results in an INIT), the firmware changes the year byte if the byte is
greater than 0C (0C -> 0C, 0D -> 5D, 10 -> 60).

The hwc shows this behavior:

VMS time 31.12.2012 23:45 2 772E 2E = 46 minute
4 BB17 17 = 23 hour
6 1F02 1F = 31 Day
8 0C0C 0C = 12
Month
0C = 12
Year + 2000 = 2012

after Poweroff 2 7732 32 = 50
4 BB17
6 1F02
8 0C0C

after Poweroff for ~ 25 min 2 7712 12 = 18 minute
4 BB00 00 = 00
hour
6 0103 01 = 01
Day
8 5D01 01 = 01
Month
5D =
93 Year + 2000 = 2093 ?

boot with 2 770A 0A = 10
25-jan-2013 14:05 4 BB0E 0E = 14
after shutdown 6 1903 19 = 25
8 0D01 01 = 01
0D =
13 Year + 2000 = 2013

>>>INIT 2 770D 0D = 13
4 BB0E 0E = 14
6 1903 19 = 25
8 5D01 01 = 01
5D =
93

boot with 31.12.2012 23:50 2 7737 37 = 55
4 BB17 17 = 23
6 1F03 1F = 31
8 0C0C 0C = 12
0C =
12

after 10 minutes 2 7700 00 = 00
4 BB00 00 = 00
6 0104 01 = 01
8 0D01 01 = 01
0D =
13 , after >>>INIT 0D -> 5D.

We have noticed too, that after year 2041 the time stays correct after
an INIT, so only years between 2013 and 2040 (28 years) seem to be
affected.
My old Alphastation 200 4/233 is not affected and boots fine with VMS
V8.4.

[Bob Koehler]

There is one in shutdown.com.

[Hans Vlems]

Michael, excellent work, thanks!
This was done on an XP1000, may I assume this applies also to the
Alpha Server 1200?
The next question is : can we fix the error?
Very likely we won't get any support from HP, presumably there are
very few XP1000's or
ALpha Server 1200's (let alone Digital Server 5305's) covered by a
hardware maintenance contract.
So is it possible to patch or edit the binary firmware file?

Hans

PS
In 2041 I'll be 84 and if I'm still alive it is doubtful that the
hardware will be still around.
And even if the hardware is still there perhaps the nurse won't let me
touch the equipment....

[Volker Halle]

Hans,

please try the >>> e toy:2 -w -n 3 SRM commands on your AlphaServer
1200 equivalent system, to see, if they are supported in the version
of SRM firmware you're running. If they work, you should be able to
examine the TOY registers in the same way as on the XP1000 and you
should be able to verify the problem on your system(s).

Once you've verified the problem, it would be time to think about
possible solutions:

- fix the firmware - very unlikely to happen
- add workaround into OpenVMS routine READ_SYSTEM_BBW. Not impossible,
but it's hard to design a workaround in this generic routine for
certain system types.
- patch SYS$CPU_ROUTINE_nnnn of your affected system: something like:
if year > 93 then year=year-80 This routine modifies the year anyway,
as the DALLAS DS1287 chip only keep a 2-digit year and the code has to
add 1900 or 2000. The PATCH utility is available on Alpha, so it's
possible.

Volker.

[MichaelM]

You can read the hwc on XP1000; :

>>> e -b toy:0 -> secs
e -b toy:2 -> mins
e -b toy:4 -> hrs
e -b toy:7 -> date
e -b toy:8 -> month
e -b toy:9 -> year offset

or together without secs

e toy:2 -w -n 3

shows 4 (-n 3) halfwords (-w) beginning with address 2 (toy:2).

So we have made some tests on our XP1000 and have noticed:

>>> e toy:2 -w -n 3 shows the hwc time correct beginning with minutes and using year 2000 as base time (tested for years 2012 and 2013).
After an >>> INIT on the boot prompt or after a power off (poweroff
results in an INIT), the firmware changes the year byte if the byte is
greater than 0C (0C -> 0C, 0D -> 5D, 10 -> 60).

The hwc on our XP1000 shows this behavior:

[Stephen Hoffman]

On 2013-01-29 11:07:50 +0000, Hans Vlems said:

> The next question is : can we fix the error?
> Very likely we won't get any support from HP, presumably there are very
> few XP1000's or ALpha Server 1200's (let alone Digital Server 5305's)
> covered by a
> hardware maintenance contract.

AlphaStation XP1000 is listed as a supported system for OpenVMS Alpha
V8.4 <http://h71000.www7.hp.com/doc/spdalphaintegrity84.pdf>, so HP
will either be changing the SPD here, or changing the firmware, or
(likely) changing the OpenVMS Alpha code.

> So is it possible to patch or edit the binary firmware file?

Yes, but not easily.

The relevant OpenVMS kernel code is easier to get at, it's in the
source listings, and it's easier to patch.

Pending any comments from HP and pending any patches, the easiest fix
is probably whacking the toy value directly from the SRM nvram script.

Something like the following (untested!) should work, if edited into
the nvram script

10 deposit -b toy:9 0d

The line number (10, in the example) must be unique within the script.
See the SRM edit command and the nvram script documentation for
details.

Given I see no obvious way to do math on the values examined by
previous SRM console commands, this nvram hack script will have to be
changed once a year. Set a calendar alarm for December 2013, with some
notes to either look for a patch, or to tweak the nvram script.

--
Pure Personal Opinion | HoffmanLabs LLC

[Hans Vlems]

Volker,
sure, as soon as I'm at home I'll try these commands.
Besides the XP1000 and the AS1200, was there also an issue with the
AlphaServer 800?
Hans

[Hans Vlems]

On a Digital Server 5305 this is what I get after powering up the
system VMS not yet booted):

P00>>>e toy:2 -w -n 3
toy: 2 001B
toy: 4 0012
toy: 6 1D02
toy: 8 5D01
P00>>>

Which is what you've seen on an XP1000, just a different time of
couse.
Hans

[Hans Vlems]

On 29 jan, 14:34, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

There is one very odd side effect. VMS is not supported on white box
alpha's.
To make it boot you needed two commands in nvram:
10 set boot_reset on
20 set srm_boot on
I noticed that the nvram file was empty on this machine and VMS still
booted alright.
Strange. But the deposit command worked its magic.

Hans

[Stephen Hoffman]

On 2013-01-29 17:38:52 +0000, Hans Vlems said:

> On 29 jan, 14:34, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
> wrote:
>>
>> Something like the following (untested!) should work, if edited into
>> the nvram script
>>
>> 10 deposit -b toy:9 0d
>

> There is one very odd side effect. VMS is not supported on white box
> alpha's.
> To make it boot you needed two commands in nvram:
> 10 set boot_reset on
> 20 set srm_boot on
> I noticed that the nvram file was empty on this machine and VMS still
> booted alright.
> Strange.

The srm_boot command was only needed with older versions of the
firmware for that box, AFAIK.

> But the deposit command worked its magic.

Good.

Pending a determination by HP of what they want to do with this box, at
least there's a work-around that'll allow it to directly boot this year.

[David Froble]

My memory (what's left of it) is that the XP1000 is an EV6, while the
other systems are EV5. Causes me to wonder how much if any the CPU has
to do with this problem. I'm not a hardware type, so I really don't
know what's happening, and where, at this stage of the startup.

Could be that some of the hardware was copied from earlier systems for
the XP1000 ???

[MG]

On a somewhat ironical and anecdotal note, my heavily 'outdated'
Multia/UDB with its old and 'unofficial' DEC AXPpci166 MT Common
Console X4.5-819 (29-APR-1996) 'SRM-surrogate' works just fine!

- MG

[Hans Vlems]

Yes, same for my Multia. The AXP / DEC 3000 model 300L also works
fine.
The XP1000 seems a closer relative to the AS1200 than expected though.
I'm curious about the AS4100 and Digital Server 7305 though.
Hans

[Joukj]

Stephen Hoffman wrote:
> On 2013-01-29 11:07:50 +0000, Hans Vlems said:
>
>> The next question is : can we fix the error?
>> Very likely we won't get any support from HP, presumably there are
>> very few XP1000's or ALpha Server 1200's (let alone Digital Server
>> 5305's) covered by a
>> hardware maintenance contract.
>
> AlphaStation XP1000 is listed as a supported system for OpenVMS Alpha
> V8.4 <http://h71000.www7.hp.com/doc/spdalphaintegrity84.pdf>, so HP will
> either be changing the SPD here, or changing the firmware, or (likely)
> changing the OpenVMS Alpha code.
>

Given this listed support as mentoned above, does the following make sense?
-I have a software contract with HP
-I have NO hardware contract
Hp has to respond on the problems I see when booting OpenVMS (asking for
the date (I noticed that the time is always picked up correct even if if
it is not typed)

Jouk

[Volker Halle]

Jouk,

if you have a software contract for OpenVMS with HP, you can certainly
raise a call for this problem. Whether HP decides this to be a
firmware problem and refuses to fix the firmware or whether HP tries
to provide a workaround or even put a workaround into OpenVMS, will be
seen.

If any of your systems are affected (you were talking about the
XP1000, AlphaServer 2000 and DWPS500 earlier), please raise a call
with HP.

Volker.

Volker.

[Joukj]

I'll do later today

Jouk

[Stephen Hoffman]

Since my comments were apparently unclear, your contract status is
irrelevant to my comments, beyond meaning that you likely won't gain
access to any fixes at all quickly.

Depending on what HP decides to do here — given this box is currently a
supported platform — there'll be either a CPU-specific patch[1] and
that'll probably eventually get rolled into an UPDATE kit, and some of
those UPDATE kits do eventually seem to arrive in the recent download
distros for hobbyists, and this presumes that the folks with
AlphaStation XP1000 boxes can't make a case for early access to the
CPU-specific patch or potentially the UPDATE.

Or there's the other outcome for this, where HP decides to drop support
for the box entirely, and all bets are off.

Put another way, if HP patches this, you might be able to gain access
to this particular fix in a year or three. Pending that, it's NVRAM
time...

On a semi-related note, I did suggest to the HP folks that it would be
reasonable to provide a way to purchase licenses and support on-line.
It'd be nice if there was a way to easily buy a real yearly OpenVMS
license and to buy support escalations or specific patches, but I don't
see that happening.


————
[1] probably some sort of a CPU2208 or CPU220B patch kit. Some years
back, there was a VMS721_CPU2208-V0100 patch for this box, for instance.
[2] And can't use the NVRAM deposit workaround that was posted earlier.

[Hans Vlems]

>           Jouk- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Please do Jouk, and I'm very curious to see to what (kind of) solution
this will lead.
Hans

[Hans Vlems]

On 30 jan, 15:45, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

> Pure Personal Opinion | HoffmanLabs LLC- Tekst uit oorspronkelijk bericht niet weergeven -

>
> - Tekst uit oorspronkelijk bericht weergeven -

Hoff, us white box alpha users were already quite used to an nvram
work-around....

[Stephen Hoffman]

On 2013-01-30 20:48:58 +0000, Hans Vlems said:

> Hoff, us white box alpha users were already quite used to an nvram
> work-around....

FWIW, with recent firmware for the box, pull out the workaround, and test SRM.

You may not need that workaround anymore.

There's some backstory around the whitebox stuff, but that's fodder for
another day.

[Hans Vlems]

On 30 jan, 21:56, Stephen Hoffman <seaoh...@hoffmanlabs.invalid>
wrote:

The firmware for the Digital Server 5305 is 6.0-4 and has been so for
quite some time (since 2001 IIRC).
I've been using 6.0-4 on all my Digital Server 530x systems and had to
use the nvram escape route.
One of my Alpha Server 1200 systems came with Alpha Server 4100
firmware loaded. The system thought it was
an AlphaServer 4100 with two processors installed. The firmware for
the 4000/4100 is at version 6.1, which is more recent
(I think). Whether it will solve the VMS compatibility issue I do not
know.

Since I've got 5 whitebox alpha's (four 530x's and one 3300), your
reference to a "whitebox alpha backstory" makes me curious !
Hans

[MichaelM]

I have tried to use nvram to set the hwc back to 0D and have put "dep -
b toy:9 0D" into the nvram file:

>>> cat nvram
dep -b toy:9 0D
>>> e -b toy:9
toy: 9 0D
>>> init
.....
CPU 0 booting
>>> ^C
>>> e -b toy:9
toy: 9 5D
>>> nvram
>>> e -b toy:9
toy: 9 0D

So a call to nvram will change the year byte, but nvram seems not to
be called on system boot or after an >>> init.
Does anyone know how to force nvram to be called before VMS boots?

[Hans Vlems]

I noticed that the workaround with nvram works well for a Digital
Server 5305 and Alpha Server 1200
but won't work with an XP1000.
I haven't found a solution yet.
Hans

[Volker Halle]

HP has responded in the HP Support Forums and is actively collecting
information about affected systems and thinking about a workaround in
OpenVMS.

If one of your systems is effected, please obtain the following
information:

1. The Alpha system type (XP1000, AS1200, etc.)

2. P00>>> e toy:2 -w -n 3 (collect this after Power-Up or >>>
INIT)

Then log a call with HP (or maybe just post the information here or in
the HP Support Forums):

http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231

Volker.

[Hans Vlems]

> http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000...
>
> Volker.

The fix suggested there (by HP?):

<HP>
The following code segment is used by OpenVMS:

if .time_result [tim$w_year] GEQ .EXE$GL_TRANSITION_YEAR
then
time_result [tim$w_year] = .time_result [tim$w_year] + 1900;
else
time_result [tim$w_year] = .time_result [tim$w_year] + 2000;

OpenVMS engineering thought of the following fix / workaround for this
issue. In the above code, change the hardcoded 1900 to a 1920 (1920 +
93 = 2013).
</HP>

Am I too critical here to consider that a kludge?
I'd rather fix the problem where it lies: the firmware. The next best
thing is to apply a fix BEFORE VMS gets booted.
My systems are far from production critical but I'd rather not run a
patched CPU$ROUTINES*.EXE for this problem.
Hans

[Joukj]

2 considerations;
1) OpenVMS should work with the hardware/firmware as it is. So if
the machine/firmware contains a bug OpenVMS should cope with it.
2) For patching the firmware HP will need:
a) people who know how firmware has been/is to be programmed.
b) machines to test it on
I wonder if HP has this "in-house"

Jouk

[Hans Vlems]

Well, I can imagine that an AlphaServer 1200 (let alone its white box
cousin) would be
hard to find within HP. I've got plenty available :).
Hans

[Jan-Erik Soderholm]

I see two realistic "solutions".

1. Fix/patch VMS to handle the brooken servers (as HP suggested).
2. Remove the brooken servers from the "supported" list in the SPD.

To ask for any change to servers that has gone
of support many years ago, is unrealistic.

The question is, has HP got a service request on this issue
from *any* paying customer yet?

Jan-Erik.

[Keith Parris]

On 2/8/2013 1:59 AM, Jan-Erik Soderholm wrote:
> The question is, has HP got a service request on this issue
> from *any* paying customer yet?

Yes. No worries there.

[Hans Vlems]

On 8 feb, 19:41, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:

For which Alpha systems, can you tell us that Keith?

[Volker Halle]

Patching the SYS$CPU_ROUTINES_2208.EXE has proven to be a successful
workaround, see:

http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000...

Volker.

[VAXman-]

I get a page with Kanji characters.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.

[Stephen Hoffman]

On 2013-02-13 21:05:47 +0000, VAXman- @SendSpamHere.ORG said:

> In article
> <a22dce8f-eb17-49b1...@fw24g2000vbb.googlegroups.com>,
> Volker Halle <volker...@hotmail.com> writes:
>> Patching the SYS$CPU_ROUTINES_2208.EXE has proven to be a successful
>> workaround, see:
>>
>> http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000...
>
> I get a page with Kanji characters.

That's the "404" page-not-found page for that HP server.

Here's the correct URL:
<http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231>


Here's the URL, wrapped:
<http://h30499.www3.hp.com/t5/Hardware/
Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231>

[VAXman-]

In article <kfh0mj$spd$1...@dont-email.me>, Stephen Hoffman <seao...@hoffmanlabs.invalid> writes:
>On 2013-02-13 21:05:47 +0000, VAXman- @SendSpamHere.ORG said:
>
>> In article
>> <a22dce8f-eb17-49b1...@fw24g2000vbb.googlegroups.com>,
>> Volker Halle <volker...@hotmail.com> writes:
>>> Patching the SYS$CPU_ROUTINES_2208.EXE has proven to be a successful
>>> workaround, see:
>>>
>>> http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000...
>>
>> I get a page with Kanji characters.
>
>That's the "404" page-not-found page for that HP server.
>
>Here's the correct URL:
><http://h30499.www3.hp.com/t5/Hardware/Changes-Boot-behavior-on-XP1000-since-2013/m-p/5936231>

Works so much better with a complete URL. :)

I just booted one of my DS20E which load SYS$CPU_ROUTINES_2208.EXE. I had
no problems with the TOY clock.

Is this peculiar to the XP1000 only?

[Stephen Hoffman]

On 2013-02-13 21:55:19 +0000, VAXman- @SendSpamHere.ORG said:

> Is this peculiar to the XP1000 only?

No.

I'm aware of a case involving an AlphaServer 1000 configuration (with
old firmware), and there were a couple of other Alpha systems
referenced up-thread here.

HP was collecting trouble reports.