VMS save sets and FTP

[Ed Day]

I recently backed up a directory I created in VMS to send to a customer. I tested the save set on the VMS machine and it worked fine. But when I FTP'd it to the customer, he reported he could not load it. I went back and tested and found that, sure enough, the original file was corrupted. In checking further, I did a dir/full on the original file and the file I FTP'd back and found the record formats were different:

Original: Fixed length 32256 byte records

FTP's: Fixed length 512 byte records

Id there any way to keep the record format from being altered?

Regards,

Ed Day

[Craig A Berry · Accepted solution]

If you are using one of the TCP/IP stacks from Process Software, then yes, you can preserve VMS file structure through an ftp operation. I forget the exact qualifier but it might be /STRUVMS or similar.

The easiest way in any case is to do a zip -"V" to the save set before transfer and have your customer unzip it on the other end. This preserves the VMS file attributes inside the zip archive. It's possible to create a self-extracting zip if the customer can't be relied on to have unzip handy.

As long as the save set record lengths are a multiple of 512 (and you can control this on the backup command, going as low as 2048 I think), then you may be able to twiddle the file attributes on the receiving end:

$ set file/attr=lrl=32256

There are probably a dozen other ways to skin this cat but those should get you started.

[Scott Belviso]

Following is a modified version of a command file that was on one of the freeware disks. It will take the saveset as the P1 paramater, look at the first record to find the block size and set the file accordingly.

(note: the file wrapped when I cut/pasted it)


$! RESET_BACKUP_SAVESET_ATTRIBUTES.COM
$!
$! P1 is the specification of the BACKUP saveset
$!
$! This procedure resets the record format and record
$! length attributes of a BACKUP saveset -- savesets
$! can get "broken" during certain sorts of file
$! transfers -- such as FTP. This procedure reads the
$! (undocumented) saveset record attributes directly
$! out of the target file.
$!
$! First render the saveset readable, and implicitly
$! check that the file exists.
$!
$! The origin of this utility is from the [000tools] freeware directory
$! of VMS software.
$!
$! History:
$! 06/27/03 - sjb - Added check for P1
$!
$!
$ If "''p1'" .eqs. ""
$ then
$ write sys$output "A saveset filename is required as the P1 Paramater"
$ exit
$ endif
$!
$!
$ Set File -
/Attributes=(RFM:FIX,MRS:512,LRL=512,ORG=SEQ,RAT=NONE) -
'p1'
$
$ Open/Error=whoops/Read BckSaveset 'p1'
$ Read/Error=whoops/End=whoops BckSaveset Record
$ Close/Nolog BckSaveset
$
$! Find the blocksize from within the record...
$
$ BlockSize = 0
$ BBH_L_BLOCKSIZE = %x28*8
$ BlockSize = F$CVUI(BBH_L_BLOCKSIZE, 32, Record)
$ If BlockSize .lt. 2048 .or. BlockSize .gt. 65535
$ Then
$ Write sys$output "Unexpected block size"
$ Goto whoops
$ Else
$ Set File /Attributes=(RFM:FIX,LRL='BlockSize', -
MRS='BlockSize',RAT=none) -
'p1'
$ Write sys$output "''p1' has been corrected"
$ endif
$ exit
$WHOOPS:
$ Write sys$output "Error"
$ exit

[Malcolm Robertson]

When you FTP'd the file did you use binary transfer? That should keep the format

[Sheldon Smith]

If the directory is of any size at all, then zipping the directory is going to speed up the transfer if nothing else. And binary mode in FTP sends a .ZIP cleanly.

Personally, I've had excellent luck with Info-Zip over the years (http://www.info-zip.org/pub/infozip/). The price is right (freeware), and the command is identical regardless of what platform its run on. I *think* the latest versions are on the VMS Freeware CDs.

As said above, use the VMS "-V" option....

[Ed Day]

Thanks for the answers thus far. To Malcom, I can confirm that the transfers were done in binary mode. I will try the freeware ZIP utility and report back.

[Martin P.J. Zinser]

While I wholeheartedly agree with the recommendations for Zip, for a one time effort
the following command should rescue the
saveset:

SET FILE/ATTRIB=(lrl:32256,mrs:32256,rfm:fix)

This does assume you have a version of VMS that supports set file :-)

[Ed Day]

The SET FILE/ATTRIB command worked for me (I will assign points once I find out if it works for my customer).

I did try the zip utility program but could not get this to work. This might be a better long term solution, so I am still interested in it. I got the following when I tried to zip:

$ zip -V asn1cvms.zip spe51$dka0:[asn1c]
zip warning: name not matched: spe51$dka0:[asn1c]

zip error: Nothing to do! (SPE51$DKA0:[000000]ASN1CVMS.ZIP;)

Anyone have any ideas on this?

Regards,

Ed

[Craig A Berry]

You aren't specifying everything zip needs to know. To pack up a "foo" directory tree do something like:

$ zip -"Vr" foo.zip [.foo]*.*

The double quotes are necessary unless you are on a very recent version of VMS and have taken steps to preserve case in command line arguments.

[Dale A. Marcy]

To further clarify, the *.*;* for the filenames is also required. I discovered this recently on my own. It does not default to all files in the directory.