I use iconv too. Had to jump through some hoops to get ASCII event binds to new environments.
I use something along the lines of iconv -f IBM-1047 -t ISO8859 FIX1 > $5 This is done after a sed command to do some string conversion.. On Tue, Nov 17, 2020 at 11:06 AM Cameron Conacher <[email protected]> wrote: > 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 > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
