Conference hydra::axp-developer

From:	HYDRA::AXPDEVELOPER "[email protected]" 24-FEB-1997 17:20:49.61
To:	SMTP%"[email protected]"
CC:	AXPDEVELOPER
Subj:	RE: ftping Alpha Backup and .EXE files

Sean,

The trouble is that the VMS record attributes on the file are lost.
Assuming you are using TCPIP Services for OpenVMS (UCX), see the help files:

$ ftp
FTP> help get/fdl

GET

  /FDL

     Optional. Default: no secondary file created.

     Creates a secondary file with the copied file's OpenVMS RMS
     record attributes (if you previously issued a PUT/FDL command).
     The SET TYPE command determines the type of file:

     o  Specifying ASCII results in a sequential file with variable
        records. Select this type when transferring ASCII text files.

     o  Specifying IMAGE results in a sequential file with fixed
        records of 512 bytes. Select this type when transferring
        non-ASCII files such as executable image files.

Similarly, see the help for the PUT command.

With this information, you should be able to put files on your server:

ftp> put/fdl image.exe

and have others copy  IMAGE.EXE and IMAGE.EXEFDL from the server
and convert them back on their VMS systems:

ftp> get/fdl image.exe


Please let me know how this works.

Mark Schafer

Greetings!

  Since the customer specifically mentioned BACKUP savesets, I suspect that
the files aren't truly "corrupt" when they arrive (via ftp) on a U*ix/Windows,
but instead got their file attributes all set back to what RMS refers to as
"Sequential" (1 of 3 possible file orginizations) w/ "Fixed-Length, 512-byte 
records" (1 of 4 possible record formats).  BACKUP savesets (created on disk)
are usually "Sequential", "Fixed-Length, 32256 byte records" and ftp chunks 
everything up into 512-byte pieces.

  You will have similar problems whenever you ftp "Indexed" files or "Relative"
files from OpenVMS/RMS to a non-OpenVMS destination.  FWIW, transfer of non-
Sequential files directly between two OpenVMS systems (w/ UCX installed) doesn't
have a problem, you only get into trouble when the file being ftp'ed from the 
OpenVMS system lands on another operating system whose file system doesn't know
a thing about the multiple file organizations/record formats that RMS allows.

  There are two approaches to solving this:

1) Convert any OpenVMS RMS file with File/Record characteristics other than the 
   ones noted above to a file with those characteristics (FWIW, a lot of "com-
   pression" tools do this for you), "ftp" the file to wherever and then re-
   convert it back a file with the original file characteristics.

   The nice part about using this technique is that by compressing the file
   first, it transfers quicker (since it's usually smaller) and the compressor
   creates a simple Sequential file which doesn't get hosed when it lands on
   a target (or intermediate) system that doesn't support all the file organiz-
   ations/record formats supported by RMS.  Running the decompressor (once the 
   file makes its way back to (presumbly) the final target OpenVMS destination
   usually restores the the original RMS file attributes.

2) If you chose not to bother with compressing things like savesets, indexed
   files, etc. before ftp'ing them to a non-OpenVMS target, then you can use
   UCX's FTP "PUT" command with the "/FDL" qualifier to create a secondary
   file with the RMS file/record attributes that can later be used by the
   CONVERT Utility to restore the file's original RMS file/record attributes.
   Fire up ftp on a system with UCX installed, and see the help for "/FDL" and
   the examples.

  I assume the customer realizes that the actual saveset is pretty useless on
any system other than OpenVMS, since to my knowledge only the "BACKUP" Utility
knows what to do with the file.

  As far as transferring .EXE files, I'm surprised the customer is having any
trouble, since the LINKER creates these and the file/record attributes on image
files are already correct for transfer to a non-OpenVMS system (at least on
OpenVMS VAX).  In any event, if the source file (on OpenVMS) is anything *other*
than "Sequential" and "Fixed-length 512 byte records", you need to follow one
of the procedures outlined above, cheers...



						Tony Swierkowski
						Digital Equipment Corporation
						Software Partner Engineering
						Palo Alto, California
						(415) 617-3601
						"[email protected]"

What I do with BACKUP savesets is the following:

1)  Use DIRE/FULL to find the length of the records (e.g., 32256 bytes)

2)  Use "SET FILE/ATTR=LRL=512" to change the file attributes

3)  Use FTP in IMAGE mode to transfer the file.

4)  Use "SET FILE/ATTR=LRL=" to restore the correct record length (obtained
    in step 2)

The advantage of this over CONVERT is that it's faster and doesn't create a
second copy of the file.

								-- Chuck Newman