Saveset blocksize on tape to allow COPY to disk

[Uwe Zessin]

Does not work. BACKUP will try to extract all files from the save-set on tape and name them "060225.BCK". And even if it did COPY - you would see the same problem, because the record size is too large.

The product named "saveset manager" (or something like this) might be able to do this, though.

[Art Wiens]

I changed the command procedure that does the tape backup to /block=32256 .

I'll have a new tape on Monday to try.

Thanks all,
Art

[John Abbott_2]

> The product named "saveset manager" (or something like this) might be able to do this, though.

Indeed it can. SSMGR V1.8 latest.
$ SAVESET input-ss output-ss[x5]
Interestingly you can create up to 5 output save sets from a single input save set in one go.

There is also a /BLOCK_SIZE qualifer that allows you to specify a new output-ss block size ranging from 2048~65024 (rounded up to 512) but limited to 32256 on disk.

Kind Regards
John.

[Rudolf Wingert]

Hello,
you did not write anything about the previous mount command. AFIAK you have to specify the blocksize during mount, so that you can copy the file. If you have a linces for the saveset manager utility, this would be the better way to copy savesets. But you should specify the blocksize also:
SAVE COPY tape:saveset /BLOCK=32768 disk:saveset /BLOCK=32256.
Best reagrds Rudolf Wingert

[John Abbott_2]

SSMGR /BLOCK_SIZE is only valid for the output save set. The input save set is already formed and by reading the frist few bytes it can determine the actualy input save set size automatically.

Don't remember off the top of my head, but a single use product license is very reasonable. It's also been/being ported to I64

Kind Regards
John.

[John Gillings]

Art,

Sorry, you probably don't want to know this...

FYI, there are only two supported utilities for accessing backup savesets on tapes - BACKUP and Saveset Manager.

Although you may be able to get COPY to "work" with sufficient fiddling, it's not supported. You experiences give an insight into why...

[Art Wiens]

Mounting a tape "files-11" isn't supported?! That's a surprise!

From HELP MOUNT MOUNT_Examples :

1.$ MOUNT MTA0: MATH06 STAT_TAPE
%MOUNT-I-MOUNTED, MATH06 mounted on _MTA0:
$ COPY ST061178.DAT STAT_TAPE:

This MOUNT command requests the magnetic tape whose volume label is MATH06 to be mounted on the device MTA0 and assigns
the logical name STAT_TAPE to the volume.

Subsequently, the COPY command copies the disk file ST061178.DAT to the magnetic tape.

Sounds like it is,
Art

[John Gillings]

Art,

>Mounting a tape "files-11" isn't supported?!

That's not what I said. Of course you can mount files-11 tapes and copy files to and from them. However, backup savesets are not just ordinary files-11 tapes and files.

It's not even to say that COPY won't work, just that it isn't supported, and there are circumstances where it will fail. For example, BACKUP must *preserve* errors from the original disk, and restore them. COPY can't do that.

If you want to use COPY on a saveset, you must use BACKUP/INTERCHANGE when you create it, but I' not sure if it's allowed with /IMAGE (which is required for a system disk saveset). If you do use /INTERCHANGE, don't expect stellar performance!

Here's the best I could come up with for a reference at short notice. Yes it's very old, but I don't believe the restriction has ever (or can ever) be relaxed:

VMS V5.2 Release Notes page 3-7 section 3.4.5,
"Magnetic-Tape Save Sets - Restriction",

"Only magnetic-tape save sets created with the /INTERCHANGE qualifier can be copied successfully to disk or tape using the DCL command COPY. In general, Digital does not recommend using the DCL command COPY to copy magnetic-tape save sets to disk or tape. This is because BACKUP's default error correction methods will not be used, and the file created with the COPY command may contain inconsistent data."

[Art Wiens]

10 points for being able to pull something from 5.2 at "short notice"!! ;-)

I guess I realize a saveset is a "special" file, but in the end, one could argue a file is a file. If savesets can be resurrected after an "unsanctioned" zipping and transportation, you wouldn't think two supported device subsystems by one vendor would have an issue.

Thanks for the insight though ... very interesting.

I'll have to cost out SSM. Sounds like the ticket for a lot of reasons!

Cheers,
Art

[Peter Weaver_1]

Art,

If you want to make it easier and supported;

On your VAX;
$ backup -
/image -
/ignore=(interlock,nobackup) -
$40$DIA5: -
MKA200:060225.bck -
/save /noinitialize -
/label=060225 -
/media_format=compaction -
/block=32768

On your Alpha;
$ ld create vaxdsk/size=? ! size in blocks
$ ld connect vaxdsk lda1:
$ mount/for lda1:
$ backup mkc300:060225.bck lda1:/image
$ dismount lda1:
$ mount lda1: label
$ backup lda1:/image -
dkb400:[vax_disks]060225.bck/save

Then you will have your LD disk and your saveset on disk without having to do an unsupported copy or worry about block sizes.

Or if you have DECNet running on the VAX at the time

$ backup -
/image -
/ignore=(interlock,nobackup) -
$40$DIA5: -
alphaname::dkb400:[vax_disk]060225.bck -
/save

will work if you have a proxy setup on the Alpha.