BACKUP changes from V5.0 to V5.5

[Stanley F Quayle]

I have a client trying to migrate their system, running VMS V5.0, to another VAX running VMS V5.5.

The backup seems to complete normally (they even specify /VERIFY).

When they put the tape on the V5.5 system, BACKUP gives an error about the tape not being ANSI labelled.

The command to write the tape on V5.5 is (excuse the wrap):

$ backup/image/ignore=inter/log/buffer_count=5-
dua0: (tape-drive):ddmmmyy.bck/label=fullbk/rewind

To attempt to put a label on the tape first, they even tried:

$ initialize (tape-drive): fullbk
$ mount/for (tape-drive): fullbk

The command on the V5.5 system is:

$ MOUNT/FOR DUA1:
$ BACKUP/IMAGE MUA0: DUA1:

[David B Sneddon]

What type of device is on each system?

Dave

[Kris Clippeleyr]

Can they mount the tape foreign on the 5.5 system?
And shouldn't the "restore" command be:
$ backup/image mua0:ddmmmyy.bck/sav dua1:

Kris (aka Qkcl)

[Stanley F Quayle]

The V5.0 VAX (a MicroVAX II, by the way) has both a 9-track tape drive (1600 BPI) and a TK-50 drive.

The V5.5 system has an Overland 9-track drive and a TZ87 (TK50 read-only) drive. Actually, we've tried two 9-track drives and *three* TZ87's. All return the same result.

> $ backup/image mua0:ddmmmyy.bck/sav dua1:

I'm not sure they've tried the /SAVE qualifier. Wouldn't I have to do a

$ MOUNT/OVER=ID MUA0:

first?

[David B Sneddon]

If there is only one save set on the tape, you should
not need the /SAVE qualifier.
With regard to the 9-track tapes, when was the last
time the heads were serviced/aligned?
I recall (many years ago) having issues with tape
drives on different VAXen where heads had gone out of
alignment.
Not sure if alignment is an issue on TK50/TZ87.
Is it possible to write the tape on the V5.0 system
then use that drive on the V5.5 system to do the
restore?

Dave

[Martin Vorlaender]

>>>
> $ backup/image mua0:ddmmmyy.bck/sav dua1:

I'm not sure they've tried the /SAVE qualifier.
<<<

With tapes, the /SAVE is the default.

>>>
Wouldn't I have to do a
$ MOUNT/OVER=ID MUA0:
first?
<<<

No. If the saveset name is the same as the label, yu can let backup mount the tape (foreign) for you. Otherwise, you have to do it:

$ MOUNT /FOREIGN MUA0:
$ MOUNT /FOREIGN DUA1:
$ BACKUP /IMAGE MUA0:saveset_name DUA1:

HTH,
Martin

[Uwe Zessin]

If I recall correctly, you can even do a:
$ backup/image tape: disk:

and BACKUP will open the next saveset from tape, but I don't think this is the problem.


I have a vague memory that there was a problem with tape headers and Y2K. Is the system really Y2K safe?

[Stanley F Quayle]

> Is it possible to write the tape on the V5.0 system then use that drive on the V5.5 system to do the restore?

That's what we're trying to do. It doesn't work.

> I have a vague memory that there was a problem with tape headers and Y2K. Is the system really Y2K safe?

Hmmm. I'll have them set the date back to 1999, and see what happens...

[Stanley F Quayle]

>> Is it possible to write the tape on the V5.0
>> system then use that drive on the V5.5
>> system to do the restore?
>
> That's what we're trying to do. It doesn't
> work.

Sorry -- I misread your posting. The MicroVAX doesn't have a SCSI interface. The target VAX only has SCSI.

The client doesn't want to make any changes to the MicroVAX, so adding a SCSI card is out of the question.

We would have been done quite some time ago if I could have convinced them to configure DECnet and used it for the backups...

[Doug Phillips]

You did do a $MOUNT/FOR MUA0: first, or not? I don't think backup did an auto-mount back then. Assuming you did, though:

Looking at the v5.5 release notes (okay, I'm a packrat;-), which is cumulative for all 5.n, there is nothing that would explain this. The date problem was with the /tape_expiration qualifier.

Support was added for the TA90A tape drive with /media_format=compaction, and some TLZ04 performance issues were mentioned.

I don't know what tape drives were supported with 5.0 that had hardware compaction, but if the 5.0 drive compacted and the 5.5 drive doesn't support it, it seems you might get an error like that.

I must have missed the type of drives you're using, but I recall having TK50's that had problems moving between systems.

[Doug Phillips]

Okay, I re-read and I see you did post your drive types. Also, it looks like maybe backup did auto-mount in 5.n, so never mind that. Looking at New Features manual, nothing there to explain the problem. Sorry.

[John Gillings]

Stanley,

Could you please post the EXACT error message?

[Antoniov.]

Stanley,
ANSI labelled error does happen when software can't read header record of tape. Your vms command are right!
Check for hardware.

Antonio Vigliotti

[Daniel Fernandez Illan]

Stanley
I think that BACKUP command is a feature generally not compatible between versions or releases of OS.
For me, the best solution to migrate is generate a STABACKIT in a box, mount both disks
and use BACKUP/IMAGE to copy the system.
Saludos.
Daniel

[Uwe Zessin]

> generally not compatible

I strongly disagree! While there have been some incompatibilities, BACKUP usually shines in this area.

[Antoniov.]

generally not compatible


Strongly disagree, too.
I backuped and restored throght different OS version, from V4.6 until V7.3-2

Antonio Vigliotti

[Bojan Nemec]

Stanley,

I agree with Antonio that this is probably a tape reading error. And also agree with Uwe and Antonio about BACKUP incompatibilities. Backup is compatible with previous versions and in most cases (what I have try in all) forward compatible.

Try to check the tape with:

$ mount/over=id mua0:
$ dir mua0:

If it works (but probably will not) this means that the tape is OK. If you have enought space on a spare disk you can copy the saveset to the disk with the copy command and than restore from there.

Bojan

[Robert_Boyd]

I'm still confused about which drive(s) you're trying to use to create the backup on the V5.5 system.

I also don't really understand about why you said the TZ87 is read only. One possibility I haven't seen mentioned relates to tape format incompatibilities -- I don't have enough grasp of exactly which equipment you're using to be sure.

If you're trying to write tapes on the TZ87 that were previously initialized on a TK50 you very likely will have some difficulties.

Are the tapes that you're trying to use "virgin" tapes, or ones that have been used before on another device?

Robert

[Stanley F Quayle]

> I'm still confused about which drive(s)
> you're trying to use to create the backup on
> the V5.5 system.

That's because I'm trying to do the backup on the V5.0 MicroVAX II. It has a built-in TK50 drive, and a non-SCSI 9-track tape drive.

On the new VAX side, I'm using a TZ87 drive. TZ87 drives can read TK50 and TK70 tapes, but can't write to them. It detects the tape type by encodings in the plastic case.

The client doesn't have any new TK50 tapes, because no new tapes have been made in years.

[By the way -- TZ87N drives don't have the capability to read TK50 or TK70 tapes, in case you're looking for that functionality.]

[Daniel Fernandez Illan]

Sorry Antonio & Uwe

I had a similar problem with "LABEL TAPES" - tape not being ANSI labelled - (TK50) between versions of VMS (5.5 and 6.2) with a microVAX 3100. If I executed a BACKUP/IMAGE in 5.5 version then the error message referent to tape label was show when I executed restore in 6.2 version. If the version was the same, logically the error didn't exist.

Saludos.
Daniel.

[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.