BACKUP changes from V5.0 to V5.5

[Uwe Zessin]

That's OK, Daniel.

I just disagree with you when you are saying
"...generally not compatible..."
as that has not been my experience.

[Doug Phillips · Accepted solution]

This thread is titled:

"BACKUP changes from V5.0 to V5.5"

The release notes and new features manual for V5.0 thru V5.5 do not state anything that would cause the problem Stanley is experiencing.

Therefore it seems the problem is not due to version changes in the backup software.

TK50 & TK87 alignment difference seems a good place to start.

[Stanley F Quayle]

I suppose their TK50 drive could be misaligned/broken. But that doesn't account for the failure when using the 9-track drive.

[Upstate Rob]

IMHO, you are taking the wrong approach. Forget the tape drives. Set up a private DECnet network between the two systems and copy over all the NON-system stuff using BACKUP across the network. I am fairly certain that doing a command like this was available even back in version 4.7:
$ backup/image disk1: system2"system pw"::disk1.sav/bck
and then unpack it that new, larger system disk's disk1.bck saveset onto the new disk1 on the new system using backup over there.

[Upstate Rob]

More Opinion: when done, I would upgrade that new system to v5.5-2 if you can, as that is still kinda supported and always works well, whereas v5.5 is NOT considered a "final version" and may have bugs.

[Stanley F Quayle]

> Set up a private DECnet network between the
> two systems and copy over all the NON-system
> stuff using BACKUP across the network.

My preferred migration method is to use DECnet to do BACKUP/IMAGE on each drive to the target system. Works like a charm.

Unfortunately, the client has specified that I am to make NO changes to the original system, including configuring DECnet...

[Doug Phillips]

>>
But that doesn't account for the failure when using the 9-track drive.
<<

No, it doesn't. But according to the doc's, the v5.0 and v5.5 backup are compatible.

It doesn't seem like you're able to use the same actual tape drive on both systems, so since the v5.5 system appears not to even "see" the v5.0 tapes, there's some other problem.

Darn. The way this forum's reply works, I can't go back and read the entire thread, but can the v5.0 read a 9-track tape that's been init'ed on the v5.5?

Maybe, try backup up a small file to a save-set on the v5.5, then on the v5.0 system, use /norewind/ignore=label (or give it the label name). If the v5.0 system can't find the tape, then what's common between the v5.5's two tape drives?

I'm guessing the v5.5 system is CHARON-VAX, and you're the expert on that, so I guess you've expored all of those issues.

[Stanley F Quayle]

> upgrade that new system to v5.5-2 if you can,
> as that is still kinda supported and always
> works well

I try to get everyone to V5.5-2H4. That allows them to use newer servers, such as the 4000-106.

But first, I have to get their system migrated...

[Stanley F Quayle]

> can the v5.0 read a 9-track tape that's been
> init'ed on the v5.5?

That's a good idea to try. No one else has suggested that...

> I'm guessing the v5.5 system is CHARON-VAX,
> and you're the expert on that, so I guess
> you've expored all of those issues.

I wasn't trying to drag CHARON-VAX into the discussion, but thanks for noticing...

[Antoniov.]

Hi Stanley,
suppose backup is not changed by V5.5;
suppose tape is readable on new unit;
suppose tape is good;
message is invalid ANSI label.
I can imagine ANSI stdandard is changed, no VMS. In this case you can restore within /OVER=ACCESS qualifier.

Antonio Vigliotti