HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Saveset blocksize on tape to allow COPY to disk

 
SOLVED
Go to solution
Art Wiens
Respected Contributor

Saveset blocksize on tape to allow COPY to disk

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
26 REPLIES
Art Wiens
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

Art,

The "magic" number is 32256.

Bill
Bill Hall
Bill Hall
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Bill Hall
Honored Contributor
Solution

Re: Saveset blocksize on tape to allow COPY to disk

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
Jim_McKinney
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

- /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
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

Ah, and why 32256?

Easy: it's 32768 - 512
.
Phillip Thayer
Esteemed Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Once it's in production it's all bugs after that.
Art Wiens
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk


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

Art
Uwe Zessin
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Esteemed Contributor

Re: Saveset blocksize on tape to allow COPY to disk

> 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.
Don't do what Donny Dont does
Rudolf Wingert
Frequent Advisor

Re: Saveset blocksize on tape to allow COPY to disk

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
Esteemed Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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.
Don't do what Donny Dont does
John Gillings
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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...
A crucible of informative mistakes
Art Wiens
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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."
A crucible of informative mistakes
Art Wiens
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Frequent Advisor

Re: Saveset blocksize on tape to allow COPY to disk

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
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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.
A crucible of informative mistakes
Uwe Zessin
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

> 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
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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
Respected Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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.
Honored Contributor

Re: Saveset blocksize on tape to allow COPY to disk

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.
____________________
Purely Personal Opinion