On Thu, 19 Sep 2019 19:45:08 +0000, Statler, David wrote: >My terminal emulator was using a setting called "Default Code Page". I went >and changed it to "1047 USA, Canada" and now the character is displaying >correctly! > >Thank you very much!! > You're welcome.
But I'm curious. Does IND$FILE for ASCII transfers automatically convert according to those terminal emulator settings? I assume the translation would be performed by the emulator if at all. If the target is a new z/OS UNIX file, does IND$FILE set the CCSID in the metadata tags correctly? If the host file is an existing tagged UNIX file, does IND$FILE verify that the CCSID agrees? How does it report disagreement? Likewise, does FTP set or verify the CCSID of UNIX files according to the SBDATACONN value/ Lately, the FTP client accepts an allocated DDNAME as the local file. Does it set or verify FILEDATA according to the allocation? The FILEDATA, RECFM, and LRECL have many possibilities of conflict with the TYPE, MODE, and STRU in FTP commands. Are these detected and reported? I have used "pax" options to convert EBCDIC to ASCII. But if I have an EBCDIC file tagged with conventional linebreak=NL and convert it with "pax" to ASCII (I presume it uses UNICODE services) the NLs are converted to LFs, but the target file is still tagged NL. I took that to SR. WAD. I understand that if "pax" converts CCSID of a file tagged as FILEDATA=RECORD it mindlesslhy translates octets in the RDWs. I haven't tried SR for that. I'd expect WAD. I hate EBCDIC! -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
