Are you up?
Yeah? How long?
The Uptime Project has moved around over the past few years, and currently resides at uptimes-project.org. This server keeps a database of clients and their reported uptimes. Yes, some of the data is absurd (a Windows machine with 272 years of uptime? Heck I thought 1 year was hard to believe...) Fortunately, the OpenVMS and OpenVMS Cluster times are more reasonable and logically consistent.
Here are instructions on setting up the client on your system. NB: don't install this on a system that you do not have authorization to run it on. From a security perspective, the source code is included -- it is up to you to review the code and build it for your system. I am not responsible for software that YOU install on YOUR system.
I've hosted the ZIP file kit on this system for your use. (Note: file updated 17-Feb-2008 with new database host definition. Both Alpha and VAX .exe's have been rebuilt.) You'll need an unzip utility to extract the contents.
Before you start, request a key from the Uptimes Project server via the "Signup" menu item on the site. Extract your kit, examine it as you need, and @Build the object and executable.
Included in the kit are two .com scripts that will allow you to run the program -- unfortunately, they only allow you to run it as a subprocess or a batch job. Personally, I wasn't enthralled with either of these options, so I created a very simple account with its own UIC (in a non-priv'd group) so that I could run the program as a detached process instead. I used Sys$Examples:AddUser.com to create the account, and then tweaked it by specifying /Flag=(DisUser,Restricted) /NoBatch /NoLocal /NoDialup /NoRemote /Network. This combination prevents the account from being used for any other purpose, just as any good dedicated service account should be set.
A simple UpClient$Startup.com file can be added to your SyStartup_VMS.com to start the detached process (edit this file to customize your file locations):
UpClient$Startup.com
$ Run /Detach -
Sys$System:Loginout.exe -
/Input=Disk$User0:[UpClient]UpClient_Detached.com -
/Output=Disk$User0:[UpClient]UpClient.log -
/Process_Name="UpClient" -
/Priority=1 -
/UIC=[UpClient]
This program requires one other, the target of the /Input qualifier. This script looks very similar to the UpClient_Batch.com file that's included in the kit and is included here:
UpClient_Detached.com
$ D = F$ENVIRONMENT("Procedure") ! Presumes this .COM and the .EXE are colocated
$ E = f$Parse(D,,,"Device") + f$Parse(D,,,"Directory") + "UPCLIENT-" + F$GETSYI("ARCH_NAME") + ".EXE"
$ upclient = "$" + E
$ write sys$output "%UpClient-I-Exe, UpClient executable ''E'"
$
$!***
$! Customize the client command line below. For instance:
$!
$! upclient -k <key>
$! upclient -k <key> -p http
$! upclient -k <key> -p http -x proxy -xp port
$!
$!***
$
$RunIt:
$ upclient -k {YourKeyHere}
$ write sys$output "%UpClient-W-ImgExit, UpClient executable terminated unexpectedly at ''f$time()'."
$ wait 00:05:00.0 ! Wait 5 minutes before trying again.
$ goto RunItNote that in either of these scripts, you'll need to edit it to add your key to the upclient command line as a value for the "-k" switch.
You can place all of these files -- the executable and any supporting files, as well as the 2 .com scripts above, into the login directory of the new account you've created. Set the security on the files to be only accessible from the owner (which should be the new account you created) and the system account -- no one else should need access to these files or logs.
Execute the startup procedure and you should see your uptime reflected on the server in just a few minutes! If you don't get an update, you can define the foreign command for the upclient program and test the program in an interactive debug session using the following syntax:
$ upclient -k {YourKeyHere} -d Based on my experience, I hope your system's on a UPS! If you look at this system's "Reboot reasons", you'll see that the majority of my reboots have been caused by power issues. A powerful UPS and I've gone almost 2/3rds of a year without a reboot as of this writing.
Happy uptimes, all!
three comments:
One of the reasons I stopped participating was seeing those ridiculously long Windows uptimes; if it’s that easy to cheat, why bother?
Another reason I stopped participating is that I reboot my system every month/few months for patching: I was beginning to feel guilty that I was bringing down the collective average uptime of VMS users by my “frequent” patching. I decided it was more important to stick to my own schedule, than to create artificially longer uptimes, especially when I was trying to (potentially) fix an elusive problem.
brad () (URL) - 16-Mar-2008 - 14:18
Hey, why do paragraphs show up in the comments as ”\n\n”?
brad (URL) - 16-Mar-2008 - 14:19
The ”\n\n” is an annoyance with the particular version of Pivot I’m running on this site. This problem should go away when I get around to updating this blog.
That said, I know what you mean about patching and the ridiculous Windows uptimes. But I still like to see at least some legitimate numbers out there, so I still run the program. Note that the startup is not in my system startup—I manually launch this program after the system has been up for several days, so that I don’t get a bunch of short uptimes in the case of multiple system reboots.
[Aaron] () (URL) - 17-Mar-2008 - 16:00
No trackbacks: