This thread looks to have played out, but I wanted to add that I would not love raising an error on a MOVE. It just feels like that's at the wrong level; it's not a data exception per se (well, I guess it COULD force one, but that would be kinda bogus) and so what is it? In other words, here's a program that works 99% of the time, but fails occasionally because you're throwing user input at it and hey, somebody managed to mix characters. That's going to be a nightmare to document, and users are going to get it wrong.
Far better IMHO to force the user to call a conversion function which itself has documented failure modes, which they'll (hopefully) test for (and if they don't, then it's on them). Not sure I'm getting my point across here; it's sort of like "This instruction works except on alternate Thursdays"--nobody is going to grok that properly and handle it cleanly. Sounds like you have a solution, anyway; just had to get this in there. Unicode/UTF-n are amazing achievements, but going between UTF-n and EBCDIC is always fraught! -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Farley, Peter Sent: Friday, January 2, 2026 6:59 PM To: [email protected] Subject: Re: Please vote for COBOL "idea" for reverse character translation I personally would be satisfied for the runtime logic to just raise an LE error condition and dump for any sort of conversion-stopping error. So long as normal “character not defined in the requested EBCDIC CCSID so make it SUB in the output” issues are just done without asking, I am perfectly willing to scan the result for SUB characters myself and use application-dependent error logic to handle or ignore the result as needed. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
