Geez, IBM no wonder ppl have file xref issues, I worked for another vendor in file xref, Lu 6.2 , We had one of the best ones on the market many moons ago. We never these file xref issues as the releases matured. Someone told me nowadays new world order on software and support............no comment
Sent from my iPad Scott Ford Senior Systems Engineer www.identityforge.com On Feb 7, 2012, at 10:42 AM, Paul Gilmartin <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
