On Tue, 23 Sep 2014 15:03:21 -0500, Paul Gilmartin <[email protected]> wrote:
>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".
#!/bin/sh
if [ $# -gt 0 ] ; then
endbyte=`tail -c1 $1 | od -tc -An | awk '{ print $1 }'`
if [ "${endbyte}" != '\n' ] ; then
echo >> $1
fi
fi
>
>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?
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
