Saveset blocksize on tape to allow COPY to disk

[Art Wiens]

I know that I've read (and experienced) that a saveset on tape can only have a maximum blocksize if at some point you want to mount the tape files-11 and copy the saveset to disk. I thought this value was /block=32768. I've searched for about an hour now but for the life of me can't find that reference.

I have such a saveset from a VAX v6.2 system disk that I want to get off tape and onto another disk on my test v7.3-2 Alpha. I want to do this because I will need to restore it into an LD disk a few times and don't want to wait on tape restore each time.

The disk was originally backed up on a TZ88 with:

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

The error I get is:

$ copy mkc300:[]060225.bck dkb400:[vax_disks]
%COPY-E-OPENIN, error opening MKC300:[]060225.BCK;1 as input
-RMS-F-IRC, illegal record encountered; VBN or record number = 0

I'm fairly certain this is the message when the blocksize on tape is too big.

What's the "magic" number?

Thanks in advance,
Art

[Art Wiens]

Man they should make this thing Courier font!!

For clarity ...

mkc300:[ no spaces in here ]060225.bck

It's not a "box",
Art

[Bill Hall]

Art,

The "magic" number is 32256.

Bill

[Bill Hall]

Art,

Backup writes a saveset to disk with a record format of "Fixed length 32256 byte records". The "magic" number is 32256.

Bill

[Bill Hall · Accepted solution]

Art,

Backup writes a saveset to disk with a record format of "Fixed length 32256 byte records". The "magic" number is 32256.

Bill

[Jim_McKinney]

32767 is the max - and I think that BACKUP rounds up to then next increment of 512 so you should probably specify 32000 or 32256 if you want to be able to copy to disk.

[Uwe Zessin]

- /block=32768

RMS uses a signed word (16-bit value) on disk to maintain the record length, because -1 (and -2 ?) are used for special meanings. 32768(10) = 8000(16) gives an error as it does not fit into a signed 16-bit value (-32768..0..32767).


- mkc300:[ no spaces in here ]060225.bck

the "[]" is not necessary, unless your "SET DEFAULT" is on a search list. In that case, you will end up with several copies on disk, because RMS takes the directory default from the search list.

Many people are aware of this by now - a typical call from somebody new to VMS is when he does a:
$ directory tape:
while logged in to SYSTEM. The workaround is easy:
$ directory tape:[] ! ;-)

[Uwe Zessin]

Ah, and why 32256?

Easy: it's 32768 - 512

[Phillip Thayer]

If you just want to move the .BCK file to disk then why don't you do:

BACKUP MKC300:[]060225.BCK dkb400:[vax_disks]060225.BCK/LOG

This might work. I'm not sure.

Phil

[Art Wiens]

%BACKUP-F-ONEF11DEV, both input and output must not be save sets

Art

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

[John Gillings]

Art,

>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

Note, there is a BIG difference between a saveset on DISK and a saveset on TAPE. When BACKUP was architected, tape drives lacked many of the error detection and recovery features of disk subsystems of the day, so BACKUP had to compensate. See all the extra stuff BACKUP has /CRC, /GROUP etc... (and a few more "under the hood"). That a tape created by BACKUP looks like a "real" Files-11 tape is almost a coincidence.

The unsupported COPY issue is just for savesets on *TAPE*. Once the saveset file is on a disk, yes, it's just a file, and you can do what you like with it, with whatever utilities and programs you like.

Please make sure you understand the distinction here.

FWIW, I believe that magnetic tape technology has reached its use by date. The only reason it was ever worthwhile was price. You traded cheap media for long save and recovery times.
Given the cost of hard disk drives and optical media is almost as cheap as those expensive tape cartridges, I'd recommend everyone stops considering a tape drive as a requirement and seriously considers a backup strategy that is entirely disk based. Huge advantages, just plug the disk module into the shelf and go. No messing around with arguments like this thread, no waiting for restores, no potential broken tapes or dropouts.

[Uwe Zessin]

> That a tape created by BACKUP looks like a
> "real" Files-11 tape is almost a coincidence.

Yep, I recall from a discussion with Andy G. some years back that it was rather meant for debugging purposes.

Ho, btw: I'd be very careful when creating savesets over a DECnet link. It's been a number of years now (10+), but I had a situation when BACKUP did create corrupted savesets that way - better use a /VERIFY.

[Art Wiens]

Peter:

That's _exactly_ what I did with the exception of the last image backup of the LD disk.

The reason this whole thing came up is I did _exactly_ that and I ended up with a "corrupt" restore. Both VMS$COMMON.DIR and all the SYSCOMMON.DIR aliases were broken - No such file message if any of them were referenced. The only thing that "worked" was a DIR/FILE which showed they were all one in the same FID.

I fixed the above "corruption". I was very tempted to start another thread entitled "Unsupported action, LD Driver bug, Bad source disk or Bad tape/drive" but I wanted to try it a few times to see if it was consistent and/or if it behaved differently if I restored from a saveset on disk. Plus the title was too long ;-)

Cheers,
Art

[Art Wiens]

John:

Thanks for even more insight! I understand.

I'm with you on pitching out tape technology ... have a look at my personal quote in my profile ;-)

I haven't had a chance to try the tape with the smaller block size yet. I'll load it up before I go home and give it a whirl tonight.

Art

[Ian Miller.]

RE: "Unsupported action, LD Driver bug, Bad source disk or Bad tape/drive"
why not report it here
http://www.openvms.org/phorum/list.php?f=5

and the author may reply.