I have done a rewrite of EBCDIC support.
By adding -fsign=ebcdic -fdefault-colseq=ebcdic -febcdic-table=ebcdic500_latin1 as compiler options
I presume I can remove the following from the EBCDIC preprocessor COBOL generation.
** STRING
** 'OBJECT-COMPUTER. PROGRAM COLLATING SEQUENCE'
** DELIMITED BY SIZE
** ' IS EBCDIC-CODE.'
** DELIMITED BY SIZE
** INTO
** EBC-TEXT
** MOVE SPACES TO SRC-DATA
** MOVE EBC-TEXT TO SRC-DATA (8:65)
** WRITE NEW-DATA FROM SRC-DATA
** MOVE '1' TO PROC-SPECIAL
** MOVE
** 'SPECIAL-NAMES. ALPHABET EBCDIC-CODE IS EBCDIC.'
** TO
** EBC-TEXT
** MOVE NEW-DATA TO SAVE-NEWDATA
** MOVE SPACES TO SRC-DATA
** MOVE EBC-TEXT TO SRC-DATA (8:65)
** WRITE NEW-DATA FROM SRC-DATA
** MOVE SAVE-NEWDATA TO NEW-DATA
** WRITE NEW-DATA
Correct ?
Simon asked that I mention @nberth in this posting.
nberth did the actual implementation of -febcdic-table and -fdefault-colseq
Best suited to answer your question.
The preprocessors creates the translation program at the program level - not a copybook based translation.
It is done at the program level - it captures a "view" of the FD / Select(s) and I-O buffers - akin to a SQL view.
The original application (zOS COBOL application in my world) is also prepossessed.
Each lexed I-O statement calls the translation module - either before or after the I-O imperative.
Take a peek at the translation module I build for each program.
The translation module is called before or after each appropriate I-O call.
The translation module is called - it is not the EBCDIC enabled application program.
It understands 2 dimensional arrays.
Warns if a redefines is encountered where format is changed (it will not warn of a usage display redefined as a different usage display)
The end product of the 2 preprocessors is the original COBOL application being able to process EBCDIC data files. Process means WRITE, REWRITE, START, READ, DELETE . . . files presented to the application in EBCDIC form and retain updates to those files in EBCDIC form.
Akin to supporting Micro Focus CHARSET"EBCDIC" with GnuCOBOL.
As an aside :-)
I can't believe I create nine character program names - verboten in the zOS world.
EBCDEMO1 creates ZEBCDEMO1 (the translation member called by EBCDEMO1)
Indeed, I think that the combination of flags -fsign=ebcdic -fdefault-colseq=ebcdic -febcdic-table=ebcdic500_latin1 should make the specification of PROGRAM COLLATING SEQUENCE … EBCDIC redundant.
Note: I think even with these flags, the files manipulated by the programs compiled using GnuCOBOL should be ASCII and not EBCDIC; but that may be what you expect.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Nicolas.
I am implementing the equivalent of MF CHARSET"EBCDIC"
CHARSET"EBCDIC" enables MF COBOL programs to process zOS datasets without the need to convert the dataset to ASCII.
zOS datasets (not COBOL source programs) are typically populated with packed decimal fields and big endian binary fields. Of course there is character (usage display) data as well.
To replicate the Micro Focus CHARSET"EBCDIC" paradigm I invoke 2 preprocessors. One preprocessor does a lex for COBOL I-O imperatives. The other analyzes the file section data structures for data fields of the usage display form.
At execution of a GnuCOBOL program processed as above, file based EBCDIC data is converted to ASCII and presented to the application program. Outbound data to a file is conversely translated to EBCDIC.
The missing element was collating sequence. For instance an EBCDIC "123" must collate after an EBCDIC "ABC". I converted the EBCDIC "123" to an ASCII "123"
Hence I depend on the "collating sequence EBCDIC " to evaluate comparative expressions as if implemented by Micro Focus CHARSET "EBCDIC".
That is X'414243" to be less that X'313233' ("ABC" < "123").
There is an attachment which is a snippet of an actual zOS dataset.
The data contained in the file is "mapped" by this typical File Section FD.
Micro Focus implementation of CHARSET"EBCDIC" is defined as:
1)The data in the record area is always in ASCII.
2) If alphabet-name has been equated in the Special-Names paragraph to EBCDIC, then data affected by the CHARSET clause is translated from ASCII to EBCDIC as it is written to the file; or from EBCDIC to ASCII as it is read from the file.
3) If identifier-1 has an OCCURS clause, the CHARSET clause applies to only the first occurrence of it. If identifier-1 has a subordinate item with an OCCURS clause, the CHARSET clause applies to the whole of identifier-1.
Note: Regarding Item 3 - The GnuCOBOL version will consider every occurrence and will understand subordinate data elements
I am further enhancing my Xpeditor like animator to interface with the ASCII-<>EBCDIC implementation.
The missing element was collating sequence. For instance an EBCDIC "123" must collate after an EBCDIC "ABC". I converted the EBCDIC "123" to an ASCII "123"
Hence I depend on the "collating sequence EBCDIC " to evaluate comparative expressions as if implemented by Micro Focus CHARSET "EBCDIC".
That is X'414243" to be less that X'313233' ("ABC" < "123").
I can confirm this is exactly what the EBCDIC-related command-line options are doing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have done a rewrite of EBCDIC support.
By adding -fsign=ebcdic -fdefault-colseq=ebcdic -febcdic-table=ebcdic500_latin1 as compiler options
I presume I can remove the following from the EBCDIC preprocessor COBOL generation.
Correct ?
Simon asked that I mention @nberth in this posting.
nberth did the actual implementation of -febcdic-table and -fdefault-colseq
Best suited to answer your question.
The preprocessors creates the translation program at the program level - not a copybook based translation.
It is done at the program level - it captures a "view" of the FD / Select(s) and I-O buffers - akin to a SQL view.
The original application (zOS COBOL application in my world) is also prepossessed.
Each lexed I-O statement calls the translation module - either before or after the I-O imperative.
Take a peek at the translation module I build for each program.
The translation module is called before or after each appropriate I-O call.
The translation module is called - it is not the EBCDIC enabled application program.
It understands 2 dimensional arrays.
Warns if a redefines is encountered where format is changed (it will not warn of a usage display redefined as a different usage display)
The end product of the 2 preprocessors is the original COBOL application being able to process EBCDIC data files. Process means WRITE, REWRITE, START, READ, DELETE . . . files presented to the application in EBCDIC form and retain updates to those files in EBCDIC form.
Akin to supporting Micro Focus CHARSET"EBCDIC" with GnuCOBOL.
As an aside :-)
I can't believe I create nine character program names - verboten in the zOS world.
EBCDEMO1 creates ZEBCDEMO1 (the translation member called by EBCDEMO1)
Last edit: Ralph Linkletter 2024-09-04
Hi Ralph,
Indeed, I think that the combination of flags
-fsign=ebcdic -fdefault-colseq=ebcdic -febcdic-table=ebcdic500_latin1should make the specification ofPROGRAM COLLATING SEQUENCE … EBCDICredundant.Note: I think even with these flags, the files manipulated by the programs compiled using GnuCOBOL should be ASCII and not EBCDIC; but that may be what you expect.
Hi Nicolas.
I am implementing the equivalent of MF CHARSET"EBCDIC"
CHARSET"EBCDIC" enables MF COBOL programs to process zOS datasets without the need to convert the dataset to ASCII.
zOS datasets (not COBOL source programs) are typically populated with packed decimal fields and big endian binary fields. Of course there is character (usage display) data as well.
To replicate the Micro Focus CHARSET"EBCDIC" paradigm I invoke 2 preprocessors. One preprocessor does a lex for COBOL I-O imperatives. The other analyzes the file section data structures for data fields of the usage display form.
At execution of a GnuCOBOL program processed as above, file based EBCDIC data is converted to ASCII and presented to the application program. Outbound data to a file is conversely translated to EBCDIC.
The missing element was collating sequence. For instance an EBCDIC "123" must collate after an EBCDIC "ABC". I converted the EBCDIC "123" to an ASCII "123"
Hence I depend on the "collating sequence EBCDIC " to evaluate comparative expressions as if implemented by Micro Focus CHARSET "EBCDIC".
That is X'414243" to be less that X'313233' ("ABC" < "123").
There is an attachment which is a snippet of an actual zOS dataset.
The data contained in the file is "mapped" by this typical File Section FD.
Micro Focus implementation of CHARSET"EBCDIC" is defined as:
1)The data in the record area is always in ASCII.
2) If alphabet-name has been equated in the Special-Names paragraph to EBCDIC, then data affected by the CHARSET clause is translated from ASCII to EBCDIC as it is written to the file; or from EBCDIC to ASCII as it is read from the file.
3) If identifier-1 has an OCCURS clause, the CHARSET clause applies to only the first occurrence of it. If identifier-1 has a subordinate item with an OCCURS clause, the CHARSET clause applies to the whole of identifier-1.
Note: Regarding Item 3 - The GnuCOBOL version will consider every occurrence and will understand subordinate data elements
I am further enhancing my Xpeditor like animator to interface with the ASCII-<>EBCDIC implementation.
ralph.linkletter@wincobol.com
Last edit: Ralph Linkletter 2024-09-06
Hi Ralph,
Very interesting project indeed.
I can confirm this is exactly what the EBCDIC-related command-line options are doing.