Celebrating!!!

[Jan van den Ende]

AMLVMS$ Write sys$ouput f$getsyi("cluster_ftime")
13-APR-1997 11:35:50.75

CET DST ~ GMT + 2:00:00.

Yes, this means the cluster uptime has reached seven years today, at 9:35 GMT.

May 5, at the ENSA/Interex Symposium in Muenchen, Anton van Ruitenbeek and myself will be presenting it as a case study.
Consider sourselves invited!!

Cheers,

jan

[Willem Grooters]

Jan,

Congratulations!

Tim efor a contest: Who's up longer that that? Issue OS as well - it will be VMS only, I guess ;-)

I won't be in Muenchen but would very much get the presentation. Will it be available?

Willem

[Jan van den Ende]

Willem,

we are trying to do the session for PinkRoccade internally before going to Muenchen as a try-out. If and when we succeed in doing that, I will ask if we can invite you there (argument: have someone that can ask the relevant questions). And maybe the VMS-SIG can be interested? That's all I can promise for now.

jpe

[Ian Miller.]

any change of the presentation appearing elsewhere or can you post some details here?

[Willem Grooters]

Jan,

VMS-SIG: Ok for the technical details, but the actual implications ("we had to convince management that the applications did NOT have to be stopped") are of higher importance OUTSIDE this SIG. Contact chairman and coordinator!

Willem

[Martin P.J. Zinser]

Hello Jan,

Congratulations from here too! One of the obvious questions here is how much of the infrastructure has been exchanged here over time. OS upgrades will be the trivial part, as well as adding/removing single nodes. How about the cluster interconnect, is this still the same?

You already have a room booked for the party in 2007?

All the best,

Martin

[Uwe Zessin]

> "we had to convince management that the applications did NOT have to be stopped"

He He - one of my former managers asked me to reboot the systems because they had been running for so long that even processes like ERRFMT had accumulated a noticable amount of CPU time. Unfortunately the whole cluster locked up after 497.5 days of uptime because some 32-bit counter inside the MicroVAX-3400 wrapped around and VMS was not able to deal with this at that time. :-(

[Willem Grooters]

Uwe,

I happen to know Jan and the environment. He made this remark one day (in a VMS-sig meeting) Jan published a description of the environment on OpenVMS.org: http://www.openvms.org/stories.php?story=03/11/28/7758863 (dated Nov. 28th 2003). In that description, you'll see that EVERYTHING has been upgraded during that period and the application was NOT brought down (unless fail-over, I presume).

[Ganesh Babu]

Hi Jan,
Congratulations..

Ganesh

[Hein van den Heuvel]

for your entertainment...
---
VMS internal timekeeping is generally 64bits. However, elapsed time for a
process is kept () as a longword. These times are in 10ms intervals, not
100ns like a lot of timekeeping, so 31 bits lasts maybe 10ish months. Then it
wraps into bit 31 and becomes an abs time, as you see.

---

$ show process /accounting /id=20800069

24-MAR-2004 17:13:21.34 User: SETIATHOME

Accounting information:
Buffered I/O count: 27892722
Direct I/O count: 23006056
Images activated: 600
Elapsed CPU time: 26-JUN-1859 21:54:19.90 <----- :-)
Connect time: 294 03:12:45.05

-----
A workaround/fix has been submitted to at least use 32 bits, not 31, expanding the range to 500 days or so. Yeah... Yeah... not enough for some, but how many other OSes do you know that would come close to this problem huh? (Plus... you can sort of back-track to see what the real value is based on the current + wrap-around :-).
------

XXXX> sho proc/id=53800128/acc

13-APR-2004 16:13:13.87
Process name: "SETI@home 39% "

Accounting information:
Buffered I/O count...
:
Images activated: 1
Elapsed CPU time: 495 05:30:43.16
Connect time: 2 04:07:56.31
XXXXX>

They are looking into promoting PHD$L_CPUTIM to a quadword in a future release.


:-).

Hein.