BACKUP of fragmented disk reboots VMS

[BrianT_1]

I have a VMS V5.5-2H4 system and one of the disks is quite fragmented. As a result I'm getting directory allocation failures because of not enough contiguous space to expand the direcories. DFU says its fragmentation state is "poor" (over 3). I want to take the disk offline and perform a backup and restore to defragment it but when I try, part way through the backup, VMS simply reboots. I found a V5.5-2 ECO for backup but it doesn't seem to address the problem. My current backup is:

Image Identification Information
image name: "BACKUP"
image file identification: "VAX 552R_62-000"
link date/time: 4-MAR-1998 17:10:01.46
linker identification: "05-13"

The ECOd BACKUP (VAXBACK4_U2055.A) is

image file identification: "VAX V6.1-008"
link date/time: 26-OCT-1994 08:49:21.76

Would you expect this to help? Is there a BACKUPSHR.EXE to go with it? I notice there isn't one in the ECO kit.

[BrianT_1]

In addition to VAXBACK4_U2055.A on the HP ECO site, I've found VAXBACK05_U2055.A on another VMS V5.5-2H4 system we have with backup image

image file identification: "VAX 552R_62-000"
link date/time: 20-JUL-1995 00:35:27.46

How do I know which of these two is the later version?

[BrianT_1]

Stupid me. I just realized that the BAKCUP image in VAXBACK05_U2055.A is the one I have installed. The question remains, however, which ECO is the later because I didn't see VAXBACK05_U2055.A on the ECO site, only VAXBACK4_U2055.A

[GuentherF]

Oh Brian, you seem to attract trouble. Are you a currator in a computer museum? ;-)

It is not BACKUP that crashes the system. Something else is broke. What was the BACKUP command? Input disk to BACKUP and output device? No crash dump?

/Guenther

[BrianT_1]

GF> Oh Brian, you seem to attract trouble.
GF> Are you a currator in a computer
GF> museum? ;-)

Ha! One might think so. We have about 25-30 VAXes and VAXstations around here that perform some fairly business-critical functions. We develop flight software for and test airborne computers we manufacture with them.

GF> It is not BACKUP that crashes the
GF> system. Something else is broke. What
GF> was the BACKUP command? Input disk to
GF> BACKUP and output device? No crash dump?

A fairly simple

$ backup/image disk: tape:saveset

command will produce the problem. It won't happen right away, but it happens every time during the backup. It has been a while since I last pursued this, so I don't have a dump right now. I can certain generate one, though.

If it's not BACKUP doing it, could it be the tape device? I have a TF85. Sime time the most recent attempt at defragging the drive I had to get the drive in the tape cabinet replaced because it stopped working. Perhaps the crash was just a sign that the drive was failing.

[Art Wiens]

Depending on your storage, do you have the "luxury" of doing the backup to another spindle? That would rule out your tape drive being a problem.

I happen to have a v5.5-2H4 system still as well, it's BACKUP.EXE shows:

image name: "BACKUP"
image file identification: "VAX 552R_62-002"
link date/time: 1-DEC-1999 15:31:17.11
linker identification: "05-13"

If I search through the release notes in SYS$HELP, I find it mentioned in:

VAXY2K01_U2055.RELEASE_NOTES

Kits superseded by this kit:

...
VAXBACK05_U2055 (Backup utility)
...

Good lord man, you're not Y2K compliant!! Planes are going to be falling out the skies!! ;-)

It does read like there were quite a few backup fixes in this patch as well.

And as an aside, reading this and your other recent threads, (and I have no affiliation with the vendor) you really should look into CHARON-VAX. It takes all the "old hardware" worries out of maintaining such relics. It works great!

Cheers,
Art

[Robert Gezelter]

Brian,

If one does not have the disk space, another option is to write the BACKUP save set over DECnet to another node that is better endowed with disk space.

A strong suggestion, particularly with older version is to ensure that the RMS extend, blocking, and buffering factors are commensurate with the situation (hint: default extend is FAR TOO LOW). This can be resolved by including the SET RMS command in the LOGIN.COM for the account being used as the targeet.

I have used the above many times when a tape drive is not available not appropriate (e.g., it is difficult to change tapes from 1,000 miles away).

- Bob Gezelter, http://www.rlgsc.com

[Steven Schweda]

> If it's not BACKUP doing it, could it be
> the tape device?

Or the disk? If the cause of the crash is a
complete mystery, why rule in the output
device, but rule out the input device?

Can you do BACKUP of another (comparable)
disk to the same tape drive/medium? Can you
do a similar BACKUP of the problem drive to
NL: (or some other reliable device)? Can you
do a BACKUP /PHYSICAL of the problem disk?
Does ANAL /DISK have anything to say about
the problem disk? (I would try to hold off
on /REPAIR until I knew that I had some kind
of useful BACKUP.) Standalone BACKUP?

[GuentherF]

...or can we have a look at the top few lines from an "SDA> SHOW CRASH" output?

Charon-VAX is not a bad idea. You can run a whole cluster with VAX7000s on you desktop PC. All your HSJ disks can be dropped on a USB-thumb drive.

/Guenther

[Edwin Gersbach_2]

To rule out the output device you could try the following:

$ BACKUP/IMAGE DISK: NL:X.BCK/SAV/LOG

that way you also see the last file copied and can determine the file beeing processed when the system crashes.

Edwin

[BrianT_1]

AW> If I search through the release notes
AW> in SYS$HELP, I find it mentioned in:
AW>
AW> VAXY2K01_U2055.RELEASE_NOTES
AW>
AW> Kits superseded by this kit:
AW>
AW> ...
AW> VAXBACK05_U2055 (Backup utility)

Well, I had certainly installed VAXY2K01_U2055 because the release notes are in SYS$HELP. Perhaps I should reinstall the BACKUP image from that kit.

AW> And as an aside, reading this and your
AW> other recent threads, (and I have no
AW> affiliation with the vendor) you really AW> should look into CHARON-VAX.

That takes money. Some other sites of the company for which I work have had their VAXes replaced with Charon VAX and it was justified using the reduction in maintenance contract costs. We haven't had maintenance for ten years and the planners can't find any cost savings large enough to pay for buying it for my site.

RG> If one does not have the disk space,
RG> another option is to write the BACKUP
RG> save set over DECnet to another node
RG> that is better endowed with disk space.

Clearly. Naturally I already knew this and would have used it were I able.

SS> Or the disk? If the cause of the crash
SS> is a complete mystery, why rule in the
SS> output device, but rule out the input
SS> device?

It's hard to suspect a device that never reports anything in the error log.

SS> Can you do BACKUP of another
SS> (comparable) disk to the same tape
SS> drive/medium?

I have. It worked, but this particular disk is the only one with the level of fragmentation and I thought I remember reading of a bug that caused BACKUP to fault when there was a high level of fragmentation. And yes, I checked BUGCHECKFATAL to make sure it was zero.

SS> Does ANAL /DISK have anything to say
SS> about the problem disk?

No.

GF> ...or can we have a look at the top few
GF> lines from an "SDA> SHOW CRASH" output?

%SDA-E-DUMPEMPTY, dump file contains no valid dump

EG> To rule out the output device you could
EG> try the following:
EG>
EG> $ BACKUP/IMAGE DISK: NL:X.BCK/SAV/LOG

Of course.

I think I'll go get the BACKUP pieces from the Y2K kit again.

[Richard W Hunt]

Given the symptoms you report, I have to think your crash dump must not be set up correctly. OK, when everything works fine, your bean-counters get really tight with the bucks. But something you said in passing makes me think you need to start looking at your hardware more closely.

To make that work, I think you need to assure that your crash dump file is good AND that the error log file is properly set up to be retained post-crash. I recall running with VAX/VMS 5.x, which was pretty good with crash dump analysis and such - but we had to assure that we could get good information for the rare times when our VAXen would hiccup.

If no device errors are being reported, what about memory errors? Since you aren't even retaining crash information, you can't tell whether it is one of those pesky little bugchecks for taking a memory fault at elevated IPL or something like that.

I would review your crash dump and SYSGEN parameters related to same to verify that you are using the correct crash dump style and that you have a proper crash dump file.

I also hope it isn't your system disk that is so badly clogged up. But on the other hand, if this gets bad enough, have you tried a standalone backup booting from the distribution media? Yeah, I know it is slower than Arctic molasses in February, but standalone backup will use default SYSGEN settings and will guarantee no competition from any background tasks. In this situation, it would rule out some issues for you. Which would be a positive thing.

[Art Wiens]

"planners can't find any cost savings large enough to pay for buying it for my site"

I'm sure they'll be very proud of how much money they saved when the system disk needs to be restored and you've got tapioca on tape!

Good luck,
Art

[Art Wiens]

"I think I'll go get the BACKUP pieces from the Y2K kit again"

No, don't bother, the BACKUP.EXE in VAXY2K01_U2055.A is :

image file identification: "VAX 552R_62-000"
link date/time: 4-MAR-1998 17:10:01.46

I'll see if I can find where the newer one came from.

Cheers,
Art

[Art Wiens]

That was easier than I thought ...

it comes from : VAXODS1_01_U2055.A

Art

[BrianT_1]

AW> I'll see if I can find where the newer
AW> one came from.

Can you answer my earlier question about whether the VAX 552R_62-000 or the VAX V6.1-008 version is the newer?

[BrianT_1]

BT> Can you answer my earlier question
BT> about whether the VAX 552R_62-000 or
BT> the VAX V6.1-008 version is the newer?

After reading the release notes for the ODS1 ECO, it seems to me that the BACKUP image it contains is the same as on VMS V6.2, which would be later than the "VAX V6.1-008" image found in VAXBACK4_U2055. Is this correct?

[Art Wiens]

I don't think you can say that The date on the V6.2 distribution savesets is 15-May-1995. The BACKUP.EXE included in there is actually:

image file identification: "T6.2-FT3"
link date/time: 22-APR-1995 00:38:14.23

I guess it would seem "obvious" from the link dates, but it's hard to say what "new features" in 6.1 and 6.2 were being back ported to 5.5-2H4. It was supposed to be a shortlived hardware specific release (for the VAX 4000-100's IIRC - July 1993) until they could put that support into v6. Suddenly 15 years slip by ;-)

Cheers,
Art

[Volker Halle]

Brian,

operating systems can crash. Even OpenVMS systems...

But if you can provide the required information about the crashdump, those problems can be identified and solved. It's either a hardware problem, which needs to be fixed or a software problem, which needs a certain patch applied. If you would really find a bug that's never been fixed for V5.5-2H4, you're out of luck. But the chances for this are quite small.

Please set DUMPSTYLE=3 (selective and full console output) and provide the output of the crash as an attached .TXT file.

Volker.

[BrianT_1]

VH> Please set DUMPSTYLE=3 (selective and
VH> full console output) and provide the
VH> output of the crash as an attached .TXT
VH> file.

I'm trying the backup to a remote saveset. If it crashes, I'll do what you ask. If it doesn't, I'd say that the tape drive is the problem.

[GuentherF]

Brian,

try a backup to the null device which may tell that the tape drive is or is not the problem here.

...but a crash dump would mucho better!

/Guenther