[Info-vax] fixing a saveset's attributes: attachment, not ftp

[David Froble]

I haven't seen the sources, so this is some guesses.

JF Mezei wrote:
> I a curious on what "blocksize" means in a Backup saveset ?

The size of an I/O buffer?

> Does this have to do with the size of the "Blobs" of data that are
> checksummed ? (aka: x bytes of data followed by checksum for those x
> bytes). ?
> 
> I can understand the desirability of having the checksumed blobs fit in
> their individual data blocks when on tape devices, and that different
> tape devices may have different optimal block sizes.
> 
> But on disk savesets, couldn't backup simply fetch the first few bytes
> to get the saveset attributes, including block size and then read the
> raw data from the disk file to build individual blobs of the right size ?

To do I/O, you need buffer(s) in which the data is moved into or out of.

> Or is the IO done by backup done on a "record" (eg: SYS$GET intead of
> SYS$READ) basis which does require the file have the correct record size
> RMS attribute to feel BACKUP a full "blob" for each read ?
> 
> Aldo, when creating a disk saveset, would't the blocksize always be the
> same by default ? Couldn't one just apply standard attributes to those
> files when fixing them ?

The default blocksize for disk save sets is 32256.  Tape is different. 
larger, I think.

> (I realise that BACKUP/REPAIR makes this moot, but trying to understand
> the underlying need to have proper RMS attributes for a file when backup
> could just read the raw data irrespective of attributes).
> 
> 
> You can do a $READ of 4096 bytes even if the LRL is 512 bytes, right ?
> 

I have no idea how to do that, without an appropriately sized buffer. 
You're correct, you can specify the number of blocks (512 byte) to read, 
but you have to have some place to put the data.

With the LRL:32256 BACKUP knows how large of buffer(s) to allocate so it 
can read the data without any pesky things such as partial reads and such.


And yes, it would be rather trivial for BACKUP to "fish" for some info 
in the saveset and then set things up to operate correctly without 
manual intervention.  But who has been responsible for that the last 10+ 
years?  Perhaps that will tell you why VMS has been neglected.