It is based on COBOL-85 including the amendmend Intrinsic Funtion Module, adds concatenation operator and national literals and parts for extended DISPLAY/ACCEPT.
It additional removes some parts including the Debugging Module and Report Writer Module.
We now have -std=xopen as the last compiler dialect for 2.2 (more to come later).
The first X/Open test (which uses an extended NIST85 tests suite) will likely be done in the next weeks (I currently try to get access to the test suite).
Last edit: Simon Sobisch 2017-07-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Simon
I am freer again and I have been thinking about how to put GNUCOBOL into operation.
The only solution that I consider viable given the resources we have, our total ignorance of Windows and other COBOL compilers, is to make a version that fully supports the X/OPEN standard with the clean (rewritten) SCREEN SECTION compatible only with MicroFocus Cobol, and only for linux (Rated Distributions) with ESQL,BDD,VBISAM, clarifying the internationalization of characters and the use of UTF.
This could be done by opening a branch of the GNUCOBOL project or with files that replace the generic version at the time of compiling the compiler.
How do you see this path?
Waiting for your response, receive cordial greetings
Juan Carlos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, from the organization I work for, I myself have a very rusty C and very little time. But I would not like to separate from the GNU COBOL project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You don't need to "separate", you could work on the changes and once the initial thing works for you we may create an official branch.
But the main question is what this branch should contain, it seems to me that this would not really be about X/Open but about SCREEN SECTION handling "per Micro Focus" - in this case the first question would be what issues you see that currently mismatch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a quick way
Alt-Clear Full Field key doesn't work
Cursor-UP and Cursor-Down do not work
The insert key does not work, it does not move the field to be able to write
PgUp, PgDn, PrtSc (ImPan)
Does not display special characters correctly
Numeric fields are not treated well by the screen section
The date field of the screen section is blocked
Scrolls are not resolved
Same keys return different values depending on whether they are called from the screen section or normal display
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For "normal" ACCEPT s to do any "extended" handling (plain stdin has no extended support [on GNU/Linux you could run a program within rlwrap to get a bunch of those an history]).
You may want to start with an "extended" screen-io, for example something like DISPLAY " " EOS AT 0101, which will lead to all follow-up screen-io to be handled "extended".
Scrolling is not handled, that's true; it would be reasonable to create a feature request with explicit note what you understand about that giving example code and expected behavior.
Part of the keys have a different result if you have a SCREEN accept with multiple fields (field navigation). I think the part of the manual Non-standard extensions, ACCEPT special keys (unchanged since a while) should still cover which special keys are handled which way.
ACCEPTing and DISPLAYing non-7bit characters depends on the terminal capabilities, settings, source encoding matching runtime expectations, and matching screenio library (= those are not portable, if you don't use terminals with similar capabilities and matching settings and matching screenio libraries). This is a completely separate issue from the rest and you'll find working solutions in the discussion board for that.
Numeric treatment is a known old issue, with chucks pre-work this likely get improved this year.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The X/Open CAE Specification is free available at
https://www2.opengroup.org/ogsys/catalog/c192
It is based on COBOL-85 including the amendmend Intrinsic Funtion Module, adds concatenation operator and national literals and parts for extended
DISPLAY/ACCEPT.It additional removes some parts including the Debugging Module and Report Writer Module.
We now have
-std=xopenas the last compiler dialect for 2.2 (more to come later).The first X/Open test (which uses an extended NIST85 tests suite) will likely be done in the next weeks (I currently try to get access to the test suite).
Last edit: Simon Sobisch 2017-07-04
Dear Simon
I am freer again and I have been thinking about how to put GNUCOBOL into operation.
The only solution that I consider viable given the resources we have, our total ignorance of Windows and other COBOL compilers, is to make a version that fully supports the X/OPEN standard with the clean (rewritten) SCREEN SECTION compatible only with MicroFocus Cobol, and only for linux (Rated Distributions) with ESQL,BDD,VBISAM, clarifying the internationalization of characters and the use of UTF.
This could be done by opening a branch of the GNUCOBOL project or with files that replace the generic version at the time of compiling the compiler.
How do you see this path?
Waiting for your response, receive cordial greetings
Juan Carlos
I don't understand what you want to actually do. You want to do these (whatever) changes yourself, correct?
Well, from the organization I work for, I myself have a very rusty C and very little time. But I would not like to separate from the GNU COBOL project.
You don't need to "separate", you could work on the changes and once the initial thing works for you we may create an official branch.
But the main question is what this branch should contain, it seems to me that this would not really be about X/Open but about
SCREEN SECTIONhandling "per Micro Focus" - in this case the first question would be what issues you see that currently mismatch.In a quick way
Alt-Clear Full Field key doesn't work
Cursor-UP and Cursor-Down do not work
The insert key does not work, it does not move the field to be able to write
PgUp, PgDn, PrtSc (ImPan)
Does not display special characters correctly
Numeric fields are not treated well by the screen section
The date field of the screen section is blocked
Scrolls are not resolved
Same keys return different values depending on whether they are called from the screen section or normal display
That's all unrelated to X/Open, no?
For "normal"
ACCEPTs to do any "extended" handling (plain stdin has no extended support [on GNU/Linux you could run a program within rlwrap to get a bunch of those an history]).You may want to start with an "extended" screen-io, for example something like
DISPLAY " " EOS AT 0101, which will lead to all follow-up screen-io to be handled "extended".Scrolling is not handled, that's true; it would be reasonable to create a feature request with explicit note what you understand about that giving example code and expected behavior.
Part of the keys have a different result if you have a
SCREENaccept with multiple fields (field navigation). I think the part of the manual Non-standard extensions,ACCEPTspecial keys (unchanged since a while) should still cover which special keys are handled which way.ACCEPTing andDISPLAYing non-7bit characters depends on the terminal capabilities, settings, source encoding matching runtime expectations, and matching screenio library (= those are not portable, if you don't use terminals with similar capabilities and matching settings and matching screenio libraries). This is a completely separate issue from the rest and you'll find working solutions in the discussion board for that.Numeric treatment is a known old issue, with chucks pre-work this likely get improved this year.