On Tue, 23 Sep 2014 09:23:54 -0500, Bill Godfrey wrote: > >I have seen the very misleading 451 message when attempting this with a USS >file in which the last line does not end with hex 15. > >If that is the case with your chars.a2e file, if you try the multi-byte >transfer again after appending hex 15 to it, it should work. > Yes, it worked. But it raises a number of questions.
o Is there a utility that will append "\n" only if the file doesn't already contain one? I tried a simple "sed" script. It failed on z/OS because my test case, intentionally containing every EBCDIC code point, contained a NUL. On Solaris, "sed" quietly discarded the NUL (which is hardly better); complained about the incomplete last line and supplied the "n". o So it's possible to have data errors in a text file. It would be the least courtesy to the programmer to report the point of error; byte offset in a UNIX file, line and column in a legacy data set. TCP/IP supports multi-line messages; this is a good application for such. o Unterminated last lines are endemic in Windows; it may be a convention. Will a Windows to Windows FTP transfer preserve them? o What FTP agents enforce the LINE_MAX limit when transferring text files? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
