[Info-vax] Long uptime cut short by Hurricane Sandy

[Alan Feldman]

On Jan 26, 12:09 pm, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
wrote:
> On 2013-01-26 00:17:28 +0000, AEF said:
>
> > On Jan 25, 2:48 pm, Stephen Hoffman <seaoh... at hoffmanlabs.invalid>
> > wrote:
> >> Disaster Tolerance.
>
> > Uh, I missed this part. There is no DR for these systems. There
> > doesn't need to be. When Hurricane Sandy hit, the building lost power.
> > We didn't get stable power back until about Jan 4. Nobody missed the
> > VAXes except for me.
>
> I had inferred that from your response.
>
> Given you're not swapping batteries (~$25 for a Dallas, or less for a
> coin cell, or probably ~$5 for a NiCd pack), the VAX boxes aren't
> uptime-critical production servers.  The boxes are effectively personal

Hi Hoff,

I'd have to pay for it myself and do it on my own time. I didn't know
it was that easy and inexpensive, though. Or is it? You have to take
almost everything out just to replace the power supply. Is the battery
easy? I never looked for it.

> computers or simple servers, but running a "weird" operating system on
> "weird" hardware.  Yes, these small computers (and even iPads) can and
> do run critical apps, but seldom with requirements for redundancy and
> continuous access.

They used to, but the 2008 Financial Crisis took care of that.

> > OK, I'm running VMS 6.2 with all relevant ECO kits applied. Can you
> > give an example of a latent bug that might hit me? I have no apps
> > running. I just use my DCL script once in a while and do an occasional
> > backup. Thanks!
>
> You have some fairly non-critical[1] computer systems here.  While
> these are VAX boxes, personal computers and tablets and small commodity
> servers are more common for these roles and these tasks in recent
> times, and these are generally cheaper to power and program and deal
> with.

Yes, but this is a legacy bit, if I'm using the right word. The VAXes
were online, and the quickest and easiest solution to working with the
AOT (see below) was to write some DCL.

>
> If these VAX systems were within my purview, I'd look to either VAX
> emulation or to port the DCL procedures, or both.   Either porting to
> newer VMS boxes and newer (and probably used) Itanium hardware, or
> porting (at least the data) all the way to commodity platform hardware,
> and to pursue reasonable opportunities to consolidate onto fewer boxes.
>
> Fix the short-term problems at minimal cost and effort (when that
> effort becomes necessary), and then remove VAX hardware (via
> consolidation onto fewer VAX boxes and via emulation, or via a platform
> port), and potentially remove VMS entirely.
>
> Given the problems you're reporting with the hardware, I'd prototype
> for and cost for consolidation, for VAX emulation, and the two sorts of
> ports, and for continued operations until the port is completed.
> That's probably already the long-term management plan[2] for these
> boxes anyway, though probably won't go forward with any priority until
> the existing VAX hardware doesn't meet your already apparently minimal
> requirements.

Unfortunately, management doesn't care about these boxes. And there
are actually three cabinets still holding a number of MicroVAX
systems. One day they will need the space. But I only need one
MicroVAX. Or perhaps I could keep two or three. Well, I could say I
use the main MicroVAX for my AOT work (which they are probably barely
aware of). But there is no pressing need at this point for the space
to be used for other stuff. Unless business picks up, I don't think
there will be a problem to keep these MicroVAXes in the cabs "as is".

>
> Depending on the nature of use here — yours is apparently fairly
> low-grade production usage — and pending wholesale replacement of the
> existing VAX hardware, you might monitor for hardware errors being
> logged, monitor the error logs for memory errors, and consider
> preemptive replacements of at least the hard disks, and possibly
> migrating the storage out into SBBs or other analogous external
> shelves.  I'd probably also not bother with periodic system-wide
> backups here, probably not even backing up the code; just the data.
> Back the non-volatile stuff once a year and after changes[3], and keep
> the periodic backups of the data off of the box.  Given the existing
> minimal investment in these servers, well, who cares what happens here?
>  Keep the data, and be prepared carry the scrap out when the box dies.

Here's the situation: The box with the longer uptime used to be a
member of a pair of VAXes that served as each other's backup. These
boxes ran trading software for brokers. They no longer do that. They
just serve as storage for stuff that no one will ever want.

The other box used to be my "home base". I wrote "TO.COM" and other
DCL routines on that box. It also served as a monitoring system to
monitor all the other VAX systems. But there is no need for that
anymore, as the trading app is no longer used.

ALL needed data are on tape at one site (Recall) and on disk at
another (overseas). ALL. Actually, much, if not all, of the data is
also on tape in the same room. I'm not even sure -- it's been so long.
(I _am_ sure of the offsite data being okay.) And actually I think
quite a lot of it is on a shadow set on one of the other systems.)

My boss's boss maintains an XL spreadsheet with all of our apps listed
with much information about each app. There are maybe two dozen
columns of stuff for close to 284 apps. I need only 5 of those columns
to post in the Application Owner Table (AOT) on our Confluence wiki,
which runs on a Unix system.

Now, sometimes he has to make changes: add or remove apps, or change
owners (each app has "owners"). So every once in a while he updates
his copy and emails it to me. I FTP it to the VAX. I do some very
quick edits (using EVE, as the lines are too long for EDT!) to take
care of a couple of things that would be far too time-consuming to
code. Then I run it through a DCL command procedure (which calls other
DCL routines). The DCL routine extracts the 5 columns I need and
converts them to wiki markup. It also adds headers and a short
informational note. I then FTP the wiki file back to my PC. I open it
in Wordpad and copy and paste the wiki markup into the appropriate
Confluence page.

That's it! That's ALL I use the VAX for. Yes, I know it's depressing,
and perhaps hard to believe, but that's it. Oh, I also use the SEARCH
command to check what owners own a given app when I need to know that.
But that's it. Certainly not worth buying new hardware for!

What I should probably do is one of the following:

o Install a VAX emulator on my PC (what would you recommend?) and port
it over.
o Write some Unix scripts to do the same thing.
o Just keep doing what I'm doing until I'm forced to do something else
(and keep a backup copy of the DCL routines, which I already have -
oh, the disk is shadowed, too!)

Should the box need repair, I have several dozen other MicroVAXes to
cannibalize. But I'd probably have to do it on my own time.

Thanks for your response.

AEF

>
> ————
> [1] The DCL application(s) might be critical, but there are clearly
> also relaxed requirements around continuous access, and hardware
> maintenance.
> [2] Variously also known as "run it into the ground, then replace it."
> [3] Possibly even performed automatically as part of SYSHUTDWN.COM or
> as a site-local wrapper around SHUTDOWN.COM, or as a part of
> SYSHUTDWN_0010.COM on newer releases.
>
> --
> Pure Personal Opinion | HoffmanLabs LLC