You could send it in binary and then use iconv to transform to EBCDIC. Sent from my iPhone
> On Nov 16, 2020, at 4:27 PM, Frank Swarbrick <[email protected]> > wrote: > > Originally (current production mode) there is no SBDATACONN/MBDATACONN > specified, so z/OS is not treating the file as UTF-8. It works fine when we > specify "site mbdataconn=(ibm-1140,utf-8) encoding=mbcs". > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Charles Mills <[email protected]> > Sent: Monday, November 16, 2020 2:14 PM > To: [email protected] <[email protected]> > Subject: Re: FTP converting between UTF-8 and EBCDIC > > If you tell FTP that the non-EBCDIC file is UTF-8 then FTP *should* convert > accented characters and such to EBCDIC SUB (X'3F') rather than to two bytes. > Should. YMMV. > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Frank Swarbrick > Sent: Monday, November 16, 2020 10:16 AM > To: [email protected] > Subject: Re: FTP converting between UTF-8 and EBCDIC > > The record is made up of multiple fixed-length fields. I guess the field in > question technically didn't overflow. But rather it "expanded" the field by > one byte, pushing every other field one byte to the right. Likely the > program that creates the file is treating the "field length" as the number > of characters, rather than the number of bytes. I've actually asked them to > create the file as ISO-8859-1 instead of UTF-8, and if they're willing/able > to do that then this entire discussion is moot. But I wanted to have this > as a backup solution. > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > Paul Gilmartin <[email protected]> > Sent: Monday, November 16, 2020 10:55 AM > To: [email protected] <[email protected]> > Subject: Re: FTP converting between UTF-8 and EBCDIC > >> On Mon, 16 Nov 2020 17:26:12 +0000, Frank Swarbrick wrote: >> >> Yes, it "overflowed" a fixed-length field. x'C3A1' in the source file was > treated as two separate "ASCII" characters, x'C3' and x'A1'. Since those > don't exist in the EBCDIC code page I am using they just get converted to > two "nonsense" characters. >> > How wide is that field? You must have been on the bitter edge of the limit. > What happens if a client enters an actual surname exceeding the limit? > >> I agree that ideally the input source would restrict the input. But since > that's on another team, and this workaround is likely "good enough", that's > probably unlikely to happen. >> > What was the workaround you chose, converting to which EBCDIC CCSID? > Is there no possibility of a client's entering a character not in that > CCSID? > What happens if someone does? Can you fuzz test or would that intrude > "on another team"? > > I'd expect you need to do some filtering, perhaps to preclude SQL injection > downstream. But that might be achieved by encoding. > > (I guessed wrong: "á", not "â". Spellcheck flags both.) > > -- 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 > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
