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
