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.
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. ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Sunday, November 15, 2020 8:14 PM To: [email protected] <[email protected]> Subject: Re: FTP converting between UTF-8 and EBCDIC On Mon, 16 Nov 2020 02:28:06 +0000, Frank Swarbrick wrote: >We don't use Unix for any of our production business applications. If we were >"starting from scratch" I imagine we might choose to use Unix files for many >things, but I can't see us going this direction now. > >This is an existing process with an existing MVS data set, and up until a >couple of days ago it was treated (on the remote side) as just a standard >"ASCII" file. A couple of days ago a user entered as last name with a >lower-case 'a' with an accent, causing a two-byte character to be used where >it had always been a single byte before. ๐ > Did that (รข?) cause the last name to overflow a field? If not, what's the problem? No single SBCS code page can accommodate all characters you're likely to encounter. You might filter on input to acceptable, SBCS-translatable characters. Expect accusations of ethnic bias if you do that. -- 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
