Roger Bowler

Changed !cb_call_extfh to !f->extfh, hopefully this is correct. Added a new test case 0990 INDEXED file using EXTFH without database in run_file.at:13489:0 which tests that compilation+run works with -fcallfh and compilation fails without -fcallfh. These tests are skipped if the compiler is not built with the --without-db configuration option. Please review pull request https://github.com/OCamlPro/gnucobol/pull/271 thanks.

I am using -fcallfh=my_extfh to access both sequential and indexed files. In this scenario there is no need for a separate database product. However if gnucobol is configured with --without-dbthen the compiler produces this message when compiling a COBOL program that has an indexed file: error: runtime is not configured to support ORGANIZATION INDEXED; FD ACCTFILE-FILE [-Werror=unsupported] I could of course suppress the message by compiling with -Wno-unsupported, but this would potentially mask...

@sf-mensch: I would tend to agree with you that ENTRY should be in Area B. ref; https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=format-area I prepared a merge request which enforces that rule: https://github.com/OCamlPro/gnucobol/pull/264 With this change, all of the merge check tests still pass, even though some of them have ENTRY in column 8. This must be because they are compiled with default.conf which has areacheck:no. However if you prefer that ENTRY should be permitted in either Area A or...

In GnuCOBOL (at least in versio 3.3) an ENTRY statement in column 12 produces this error: error: ENTRY should start in Area A The error is triggered by this line in parser.y: entry: ENTRY {check_area_a_of ("ENTRY"); }; I think this is wrong. The COBOL Language Reference manual doesn't include the ENTRY statement in the list of statements that have to be in area A. I know this can be bypassed by -fno-areacheck but I nevertheless think ENTRY should be in area B. Is this a mistake or is there a reason...

Hi Ralph, thanks for your comments. I think what you are saying is that a COMP-5 PIC 99 scale is 2 bytes on zOS and only one byte with GnuCOBOL. I am, but that's a separate issue. https://sourceforge.net/p/gnucobol/bugs/1000/ which will be fixed by https://github.com/OCamlPro/gnucobol/pull/197 What I am addressing here is the fact that GnuCOBOL stores COMP-5 fields in a different byte order than COMP or COMP-4. Change the comp-5 to comp-4 Add -fnotrunc to the compile script Yes that would work in...

I would like to contribute a new feature: an configuration option to store COMP-5 fields in big-endian format. The purpose is to enable mainframe COBOL programs that rely on the byte format of COMP-5 fields to be run by GnuCOBOL without source code changes. The proposed changes and full description are in this pull request: https://github.com/OCamlPro/gnucobol/pull/249 I would welcome feedback and suggestions, thanks.

I see that this has already been raised as a bug and is being addressed by https://github.com/OCamlPro/gnucobol/pull/197 https://sourceforge.net/p/gnucobol/bugs/1000/ Simon Sobisch simonsobisch@gnu.org BUG #1000: Wrong binary size computed for COMP-5 PIC 9 and PIC 99 when binary-size=2-4-8

I see that this has already been raised as a bug and is being addressed by https://github.com/OCamlPro/gnucobol/pull/197 https://sourceforge.net/p/gnucobol/bugs/1000/2024-10-29 Simon Sobisch simonsobisch@gnu.org BUG #1000: Wrong binary size computed for COMP-5 PIC 9 and PIC 99 when binary-size=2-4-8