Very interesting! I stand corrected, there is already a way to accomplish the task, and both DISPLAY-OF and NATIONAL-OF will raise a runtime error on conversion-stopping errors. I never looked at NATIONAL-OF combined with DISPLAY-OF but it makes perfect sense now that I read about them further.
Thank you, Paul F.! Peter From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Feller Sent: Friday, January 2, 2026 7:17 PM To: [email protected] Subject: Re: Please vote for COBOL "idea" for reverse character translation I don't have access to the IBM site to read the information. I lost my IBM ID when I retired. I did play some with doing EBCDIC to ASCII (and the other way) under COBOL before I retired. I started with an example from one of the COBOL manuals. I adjusted the code to see what I could do. Following information was from the Enterprise COBOL for z/OS 6.3 Programming Guide chapter 6 page 114. Converting from one code page to another You can nest the DISPLAY-OF and NATIONAL-OF intrinsic functions to easily convert from any code page to any other code page. For example, the following code converts an EBCDIC string to an ASCII string: 77 EBCDIC-CCSID PIC 9(4) BINARY VALUE 1140. 77 ASCII-CCSID PIC 9(4) BINARY VALUE 819. 77 Input-EBCDIC PIC X(80). 77 ASCII-Output PIC X(80). . . . * Convert EBCDIC to ASCII Move Function Display-of (Function National-of (Input-EBCDIC EBCDIC-CCSID), ASCII-CCSID) to ASCII-output This a cut down version of my test code to go from ASCII to EBCDIC. I’ll say again this was me just playing around to see what I could do. This code was NEVER put into any production environment. I don’t think the data I used was anything fancy or special. Probably just characters and numbers. DATA DIVISION. FILE SECTION. FD EBCDIC-FILE RECORD CONTAINS 150 CHARACTERS RECORDING MODE IS F LABEL RECORDS ARE STANDARD DATA RECORD IS EBCDIC-GRP. 01 EBCDIC-GRP. 05 EBCDIC-DATA PIC X(150). FD ASCII-FILE RECORD CONTAINS 150 CHARACTERS RECORDING MODE IS F LABEL RECORDS ARE STANDARD DATA RECORD IS ASCII-GRP. 01 ASCII-GRP. 05 ASCII-DATA PIC X(150). WORKING-STORAGE SECTION. 01 WS-START-HERE PIC X(30) VALUE 'Working storage OMVSTST3 start'. *==============================================================* * Change the CCSID to match what conversion you want to do * *==============================================================* 01 WS-VARIABLES-XXX. 05 EBCDIC-CCSID PIC 9(4) BINARY VALUE 1140. 05 ASCII-CCSID PIC 9(4) BINARY VALUE 819. 01 WS-END-HERE PIC X(30) VALUE 'Working storage OMVSTST3 end '. *==============================================================* * PROCEDURE DIVISION * *==============================================================* PROCEDURE DIVISION. 000100-START-PROGRAM. *==============================================================* * Open the files we need. * *==============================================================* 000200-OPEN-FILES. OPEN OUTPUT EBCDIC-FILE. OPEN INPUT ASCII-FILE. *==============================================================* * Begin the process of read/writing the data * *==============================================================* 000300-PROCESS-DATA. READ ASCII-FILE AT END GO TO 002000-OUTPUT-DONE. *==============================================================* * Convert ASCII to EBCDIC * * I took the original example from the IBM COBOL manual and * * flipped things around. * *==============================================================* MOVE FUNCTION DISPLAY-OF (FUNCTION NATIONAL-OF (ASCII-DATA ASCII-CCSID), EBCDIC-CCSID) TO EBCDIC-DATA. WRITE EBCDIC-GRP. GO TO 000300-PROCESS-DATA. *==============================================================* * We are done so close the files. * *==============================================================* 002000-OUTPUT-DONE. CLOSE EBCDIC-FILE. CLOSE ASCII-FILE. *==============================================================* * That's it we are now really done. * *==============================================================* STOP RUN. 999900-LAST-EXIT. EXIT. Paul -----Original Message----- From: IBM Mainframe Discussion List <mailto:[email protected]> On Behalf Of Phil Smith III Sent: Friday, January 2, 2026 5:09 PM To: mailto:[email protected] Subject: Re: Please vote for COBOL "idea" for reverse character translation Showing my ignorance of COBOL: Does a MOVE from EBCDIC->UTF-8 mean "Here's a variable defined as n EBCDIC characters, please move it to this other variable defined as (at least) n UTF-8 characters"? If so, as Gil intimated, I wouldn't say there "is no technical reason". I can think of at least one problem: A UTF-8 string that contains characters from multiple UTF-8 blocks. For example, x'52' in EBCDIC 410 (Cyrillic) is a њ; in 420 (Arabic) it's ؤ. There's no reason a UTF-8 variable cannot contain њؤ but if it does, you can't convert back to EBCDIC. That's far from a rare issue--every EBCDIC code page has overlapping characters (if it didn't, it wouldn't be needed). -----Original Message----- From: IBM Mainframe Discussion List <[email protected] <mailto:[email protected]> > On Behalf Of Mike Schwab Sent: Friday, January 2, 2026 5:48 PM To: mailto:[email protected] <mailto:[email protected]> Subject: Re: Please vote for COBOL "idea" for reverse character translation How about character 160 inverted Exclamation mark? On Fri, Jan 2, 2026 at 3:05 PM Paul Gilmartin <[email protected] <mailto:[email protected]> > wrote: > > On Fri, 2 Jan 2026 18:56:13 +0000, Farley, Peter wrote: > > >Currently Enterprise COBOL allows PIC X alphanumeric EBCDIC group and elementary items to MOVE to UTF-8 (PIC U) and NATIONAL (PIC N) group and elementary items with automatic character set translation, but the reverse MOVE is not allowed. There is no technical reason why the reverse MOVE should not be allowed, since the character set translation logic is already in place for a PIC X MOVE into PIC U and PIC N. > > ... > I suspect this uses internally something similar to: > <https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/3.2.0?topic=functions-iconv-code-conv__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KUPHiHZOP3Fk3ohDqGSoj1ATq_p6vYmIFR_IKHUZEbMLtLwyv590y3elyvIX3KAA-zbuHAAlzqKvQ7f9ynivDvJh-nApk_5p2tCPrd-M$ > ersion> > > How should COBOL handle/report all the errors described there, some of > which occur only in the "reverse" (from U) direction? > > >I have a bit more detail on the subject in the "idea" summary, please read those details at the "ideas" page and vote for it. > > > >https://urldefense.com/v3/__https://ideas.ibm.com/ideas/COBOLVUE-I-427__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!KUPHiHZOP3Fk3ohDqGSoj1ATq_p6vYmIFR_IKHUZEbMLtLwyv590y3elyvIX3KAA-zbuHAAlzqKvQ7f9ynivDvJh-nApk_5p2oMU5zzd$ > > > >TIA for your votes. > > - > gil -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
