[Info-vax] Copying savesets over DECnet

[geze...@rlgsc.com]

On Wednesday, August 26, 2020 at 10:29:16 AM UTC-4, arca... at gmail.com wrote:
> I'm trying to recover some savesets from DLTIII tapes. I've got a working drive and a working tape but I seem to be hitting other issues. 
> 
> I've temporarily set up a bound volume set that I think might be big enough to hold the saveset ... but since everything else has failed, I expect that this will too. 
> 
> So my fallback was going to be to copy the saveset from tape to a remote node that has (much) more diskspace. 
> 
> My attempt was less than successful: 
> 
> $ copy/log mka500:*.* 1.51"system password"::DUA1:[DISK$USER_OBJ] 
> %COPY-E-WRITEERR, error writing 1.51"system password"::DUA1:[DISK$USER_OBJ]OBJ.BCK;1 
> -RMS-E-NETBTS, network buffer too small for 8192 byte record 
> %COPY-W-NOTCMPLT, MKA500:[]OBJ.BCK;1 not completely copied 
> 
> 
> Now I'm sure there's a way of fixing this but as I stopped using VMS on a daily basis in ~2004 I seem to have forgotten how to fix that! Any reminders would be gratefully accepted. 
> 
> For the record, I realise that COPY isn't the _correct_ way to do this, it might trip up on read errors and the like, but if it _does_ work then I will have the saveset as required. 
> 
> Many thanks for any hints, 
> 
> Antonio 
> antonio ~ acarlini ~ com <- put @ and . in the obvious places!
Antonio,

The source of the message is the size of the logical record buffer . When copying between dissimilar devices, COPY uses record mode. SEt RMS/NETWORK affects the size and number of multi-record buffers will not be productive. The problem is different. BACKUP is writing fixed size blocks on the tape. One can override the tape-label specified record size, and then probably use SET FILE to reset the record length on the target node.

I am in the middle of another task, so I cannot research it at this instant, but the experiment is fairly simple.

The limits on FAL should be documented. If not, there are a couple of approaches that I can think of. I will try to get back to this later.

- Bob Gezelter, http://www.rlgsc.com