This is the command format: IND$FILE PUT fn ft fm ( ASCII CRLF RECFM F LRECL 1024
Pete -----Original Message----- From: Peter Borton Sent: 01 September 2009 21:04 To: 'The IBM z/VM Operating System' Subject: RE: Retrieving a VM Packed file All I can say is 'It works for me' - as long as the CMS file was text in the first place of course (sorry forgot that bit in my first response! Why would you pack a binary file anyway ?). I've just tested it and it works fine. It definitiely WON'T work for binary files. VM packed files are Fixed 1024 bytes so I believe the <CR><LF> is ignored because you've said the LRECL is 1024. All I can suggest is you try it yourself !! Pete -----Original Message----- From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Alan Altmark Sent: 01 September 2009 18:27 To: [email protected] Subject: Re: Retrieving a VM Packed file On Tuesday, 09/01/2009 at 12:54 EDT, Pete Borton <[email protected]> wrote: > I have successfully retrieved IND$FILE files transferred to a PC as > text by > using LRECL 1024 on the IND$FILE RECEIVE options. There are three problems inherent in transferring binary data as text: 1. Non-reversible translations. 2. Data loss due to CRLF add or delete 3. Loss of "structural integrity" (and, no, Scotty can't reinforce it by rerouting auxilliary power) When you transfer a MODULE, for example, as text, the remote host will add CRLF sequences at the end of each line of the MODULE and translate all characters to ASCII. Imagine that the code contains BASR R2,R5 Which is, in hex, 0x0D25 ... EBCDIC CRLF. It will be changed to 0x0D0A (ASCII CRLF). Now you have an extra "line". When the file is uploaded, the transfer program assumes CRLF means "end of line" and will strip the CRLF from the data stream and create new line in the CMS file. You are now missing an instruction and you have no way to correct it - the data was irretreivably lost the moment the file was downloaded to the PC. The upload simply gives you a program with missing instructions. Structural integrity has to do with record boundaries and record formats. Again, those nasty CRLFs create havoc, breaking a record where no break was intended. > Not sure about FTP though. IND$FILE, FTP, NFS .... it doesn't matter. This is why things like base-64 encoding were invented - to allow binary files to flow as text without damage. Alan Altmark z/VM Development IBM Endicott
