%BACKUP-F-CLUSTER, unsuitable cluster factor redux

[Jon Pinkley]

BT>They will not replace the switch with another FDDI switch
BT>that could be managed because it wouldn't be "standard",
BT>so they're turning it off.

Was this leased equipment, or it the switch just going to be thrown away?

If it is going to be thrown out, why can't you just mount it in one of the VAX 7730 cabinets, and run fiber patch cords to the DEMFAs and the DEFPA and just make it a dedicated cluster interconnect, with no connection to any network? Then it would be invisible to the networking group, and would just be "part of the Cluster hardware". The networking group didn't control your CI cables and HSJ/HSC did they? Just call it an FDDI star coupler.

Jon

[Shriniketan Bhagwat]

Hi Brian,

As Ian Miller said, please send an email to openvms.programs@hp.com regarding this issue. You may get some useful assistance.

Regards,
Ketan

[BrianT_1]

SB> As Ian Miller said, please send an email
SB> to openvms.programs@hp.com regarding
SB> this issue. You may get some useful
SB> assistance.

Why be so secretive? If the people monitoring that address are aware of the problem and can be of assistance, why don't they just say so publically here and help everyone who may have this problem?

I've written as you suggest, but I'd rather have the conversation in public.

[Robert Brooks_1]

Why be so secretive? If the people monitoring that address are aware of the problem and can be of assistance, why don't they just say so publically here and help everyone who may have this problem?

--

For the same reason that we ask folks who have a support contract to formally log a call. Like it or not, "management likes to track and quantify various issues, and the requested email is effectively a less formal way of logging a call that's offered as a courtesy for folks without contracts.

Yeah, I "get it" that we should want to fix all bugs, independent of how they're discovered and reported, but that's how we're asked to play the game.

-- Rob (who is using the "royal we" as a HP'er, but not a member of VMS engineering)

[BrianT_1]

I wanted to bring this thread to a close. Back in July of 2010, I received from HP a zip file containing a version of BACKUP and BACKUPSHR that purported to fix the problem of restoring an IMAGE backup of a disk whose BITMAP.SYS was larger than 255 blocks. I had installed those BACKUP images and used them in the course of our normal backup procedures, but because I had no spare disks of sufficient size as to test the ability to restore the image backups, the fix went untested.

Because we're in the process of implementing Charon-VAX, I was able to create two extra disks that were each the same size as my RAIDed RZ1DFs (28 GB). I made an IMAGE backup of a production disk and put the saveset on the first of these large disks. I then attempted to restore that saveset to the second large disk. BACKUP displayed an informational messages that said the disk wasn't usable in V7.2 or earlier of VMS and then proceeded to initialize the large disk with the same values as the source disk and restore the saveset. Needless to say, I'm DELIGHTED! I offer profuse thanks to the people at HP who worked at correcting this bug in BACKUP and encourage HP to make this patch available to all customers who use VAX (and VAX emulations) and run OpenVMS 7.3 on them.

I also offer thanks to all the people who helped in this thread and especially to those who were able to examine the BACKUP source and find the true cause of the issue.

[Ian Miller.]

A way that fixes get packaged as patches and release is that customers with support contracts ask for the fix and if enough support customers do that then the patch is released to all support customers.
There are other ways

[BrianT_1]

Except that this particular problem prevented VMS BACKUP from handling legitimate disk sizes. Thus, everyone using OpenVMS VAX 7.3 should get the patch, support contract or not.

[Proliant VMS San Mgrs]

Hi Brian, (this is Carl Friedberg) I only recently began reading ITRC, and just finished this story. During our long use of an HSZ50 (way more than 10 years), we never had a situation like the one you describe with the HSJ. We did have a few controller failures, bad cache batteries, and disks failed about once a month. I never, ever, used anything but RAID 1; I wanted the better performance of RAID 1 over RAID 5. I went through a long, painful series of steps to upgrade disks, from 4GB to 9 GB to 18 GB to 36 GB (and the HSZs were limited to a small number of those, 2 in each disk shelf, IIRC). However, we never lost a bit of data, nor ever had any forced errors, so far as I know. I am also happy that we had DEC, then compaq, then HP hardware and software support (and until he was laid off by HP last year, we had the same experienced hardware engineer).

If you ever are fortunate enough to acquire an EVA, you will be amazed at how much easier it is to manage all of this.

I am glad to hear that HP engineering addressed the backup issue on VMS 7.x release, and made it available to a customer without a support contract.