On Tue, 7 Feb 2012 00:06:09 -0600, Alan Altmark wrote:
>
>The FTP standard REQUIRES the use of CRLF (0x0d0a) on the wire to identify
>end-of-line. That said, Unix FTP programs are notorious for their use of
>plain LF. The users of said programs are just as notorious for not pressuring
>the vendors to fix them. (Why have standards if no one will follow them?)
>
Which ftp server(s) or client(s) do you know that violate this standard when
transferring files in ASCII STREAM mode? This is usually PEBKAC, where the
user attempts to transfer a text file between UNIX and Windows as IMAGE.
Standards? IMO, IBM is one of the worst offenders. I take this as
a residue of behavior from circa 1980, when when IBM could
glibly ignore any external standards.
Nowadays, when I submit a PMR on a transgression of standards
by IBM, the response I expect is either WAD or "submit a Requirement."
>If the file is simply EBCDIC strings separated by NL, use the POSIX
>translation table.
>
I believe the OP had EBCDIC strings separated by LF, where OMVS
expects NL. Which translation table will fix this?
And, speaking of standards, this is a conspicuous violation by z/OS.
You know CMS. CMS Pipelines correctly translates:
IBM-1047 ISO8859-1
NL 0x15 NL 0x85
LF 0x25 LF 0x0a
iconv(1) on Ubuntu Linux correctly does likewise. (What do the
various Linuxen for z do?)
iconv(1) on z/OS does:
IBM-1047 ISO8859-1
NL 0x15 LF 0x0a
LF 0x25 NL 0x85
Try to point this standards violation out to IBM and see what happens.
I have a similar problem with the misbehavior of LC_COLLATE=En_US
in z/OS LE. IBM is trying to tell me it's an ASCII vs. EBCDIC problem.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
