Problem restoring backup taken in higher VMS version

[Shay Cohen]

I've done a standard backup on a MicroVAX 3100 (on TK50 tape) running OpenVMS V7.2 (before the backup command i've initialized the tape).
When trying to restore the save-set on a V5.5-2 VMS version, the OLD save-set that was on the tape before the Init command is restored. There are no signs for the new save-set on the tape.

[Art Wiens]

Mount the tape back on your 3100 - Files-11 ie. not /foreign and do a directory listing.

eg.
$ mount/over=id muaxxx:
$ dir/date=(cre,modi) muaxxx:[]*.*;*

What does that show you? Did you do the backup in batch? ie. do you have a log file to verify you actually did a successful init and backup?

Cheers,
Art

[Hoff]

The situation as described is never supposed to arise, barring cases of run-time errors with the INITIALIZE command, or a DLT cartridge mix-up or other such.

This particular day-one behavior of tape processing is entirely version independent.

A successful INITIALIZE clears off the contents of the tape.

Whether or not the INITIALIZE command was accepted and processed, that detail can involve the particular model of drive involved, and in which model DLT drive the cartridge was first written to.

Many of the TK-series drives can read media written in TK50, but can't write to these CompacTape series DLT cartridges, and some cases can require degaussing prior to writing. This media density incompatibility case should produce a write error of some sort, should this case arise. INITIALIZE should fail, or should overwrite the structures.

The particular BACKUP and INITIALIZE commands used for creation and for restoration can be very useful for purposes of troubleshooting.

Outside the matter of whether or not the INITIALIZE command was accepted and processed, it is entirely possible to have multiple files -- BACKUP savesets or otherwise -- with the exact same filename on the exact same tape. Though the INITIALIZE should clear this tape off.

And FWIW, if you specify the saveset restore by filename (and you don't have to specify the filename, you can also restore by saveset tape position), BACKUP will find the first saveset that matches the specification, and restore it.

[Shay Cohen]

I've done the INIT and BACKUP command interactively. The BACKUP command done with /VERIFY and there were no errors. I've mounted the tape later with MOUNT/OVER=ID and did a COPY drive:*.* and I've got only one file (=saveset) - the old one.

[Jon Pinkley]

Shay,

What you are describing sounds to me like an incompatibility of the two tape drives involved.

I didn't think TK50s allowed multiple partitions, but what you describe sounds like that is effectively what your are seeing.

Andy Goldstein (if I am remembering correctly) once described a similar situation in a VMS Magic session, it involved 9-trk tape and two different drives, a small saveset and a tape that had two "start of volume" markers (the little pieces of reflective foil applied to the start of the tape, and end of tape).

One tape drive scanned forward looking for beginning of tape, the other wound a good bit of tape on the take-up reel, then found the beginning of tape while it rewound.

The effect was that one tape drive was able to create a small saveset between the two beginning of tape marks, and the second drive skipped past it while it was loading the tape. This took engineering a while to determine what the underlying cause was.

I would not expect the same type of problem to be possible with a serpentine tape like TK50.

However, I would try using a different tape to see if the problem goes away.

Jon

[Jon Pinkley]

Perhaps someone with more hardware knowledge about the TK50 can say if this is a possibility. Perhaps the alignment of the two tape drives is enough different that each can read the tracks it writes, but not the tracks written by the other drive.

Do you have a third TK50 drive? Which saveset does it see?

Jon

[DECxchange]

Hello,
Did you do try a backup/list command on the tape? I don't know how this could be possible since you intialized the tape, but maybe the backup of the 7.2 system ended up being put on AFTER the OLD save set. I would be interested in finding out what a backup/list command does on BOTH your VAX-VMS 7.2 system and on your VAX-VMS 5.5-2 system.

[Steven Schweda]

> I've done the INIT and BACKUP command
> interactively. The BACKUP command done with
> /VERIFY and there were no errors. I've
> mounted the tape later with MOUNT/OVER=ID
> and did a COPY drive:*.* and I've got only
> one file (=saveset) - the old one.

Show me a transcript instead of a vague
description, and I might believe it.

After INITIALIZE, BACKUP, if it does anything
at all, should put your new save set onto the
tape, at the beginning. What makes you
believe that what you have is "the old one"?

Many things are possible, but extraordinary
claims require extraordinary evidence.
_Some_ evidence, at least, would be nice in
this case.

[Wim Van den Wyngaert]

Also try dir a.b.c to see if error messages are enabled. Check help set mes if no message.

Wim

[Shay Cohen]

Sorry for the delay. The machines are on differents sites.

I've tried to read again (backup/list) the tape on the V7.2 machine and failed. The tape driver could not find the start-of-tape (it's an internal TZ30 and after I inserted the tape and close the door, the small lamp was blinking in orange and didn't stop for some minutes until I pressed the Release button).

I took another tape, backup something on it in the V5.5-2 machine (let's call the saveset NARKIS) and took it to the V7.2 machine. Mounting the tape didn't recognize the tape label nor the saveset. I've INIT the tape on the last machine and did a backup. Going back to the V5.5-2 machine and trying BACKUP/LIST, I saw the NARKIS (!!!) saveset (although this tape was initialized on the V7.2 machine).

It's the second tape with the same phenomenon.