This looks good and if you put it into a single source it will compile, so we'd need more context.
But you may want to compile with cobc -std=acu-strict -Wall prog.cob first to check if it compiles then and if not if there are any warnings (or even errors) before the diagnostic shown above.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you please share the source lines around the first two errors? Those look quite interesting (and the first one possibly can be easily "skipped" (= pending), if it isn't yet).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's an error in GC 3.2 preview versions (not there in GC 3.1.2) and tracked with [bugs:#880], should be fixed before the next (and hopefully last) 3.2 pre-release; there's also a patch available already (not re-checked/integrated yet).
It was either deemed to be to complicated to "easily add", or was deemed to be an error; the check was added in [r996], not sure if @edward-h remembers the details.
In theory typeck,c could emit multiple DISPLAY (always when the type switches), but this may be a change that isn't easy...
Something that is always possible is to apply a search-and-replace with an regex on the sources (the DISPLAY tNNN could be split to a separate statement this way), as an alternative to manually doing this.
sure; but please check to not report the same issues - and please copy+paste code instead of pictures (ideally you could edit your previous image-posts in this thread and replace them with text-posts).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2023-03-22
I am from Brazil!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That seems to be [feature-requests:#414], as I've worked on something similar sine that was created, there is now an option to change parser.y as follows to get this parsed and likely also working:
line_number:
- LINE _number num_id_or_lit+ LINE _number pos_specifier_value {
- /* FIXME: arithmetic expression should be possible, too, only numeric literals! */ $$ = $3;
}
;
column_number:
- column_or_col_or_position_or_pos _number num_id_or_lit+ column_or_col_or_position_or_pos _number pos_specifier_value {
- /* FIXME: arithmetic expression should be possible, too, only numeric literals! */ $$ = $3;
}
;
I'll need to do some testing / adjusting (with this change test 416 fails, so a bit more to do), then should be able to commit this and the other change.
Hi,
I'm new to gnucobol
but i have experience in acu-cobol.
I'm trying to compile some acu-cobol programs to gnu-cobol and I'm having a hard time getting used to compiling.
I have this error
from source:
I'm looking at the documentation and I still don't understand what it could be.
the programs normally run in acu-cobol. But I want to migrate to GnuCobol 64-bit.
Last edit: Simon Sobisch 2023-03-22
This looks good and if you put it into a single source it will compile, so we'd need more context.
But you may want to compile with
cobc -std=acu-strict -Wall prog.cobfirst to check if it compiles then and if not if there are any warnings (or even errors) before the diagnostic shown above.invalid option -- 'a' ??
it is an uppercase "W" you want to use.
it seems to me that there is a lot of adaptation to do
I didn't think there would be so many
What version of GC is that (
cobc -V)? If it is older than GC 3.2rc2, then definitely update that, then check again.Windows 64-bits
Can you please share the source lines around the first two errors? Those look quite interesting (and the first one possibly can be easily "skipped" (= pending), if it isn't yet).
Error Line 1017
As I've expected the code is quite easy to get parsed with GnuCOBOL after a minimal change to cobc/parser.y:
and
... now you only have to wait for a (possibly nightly) windows binary that has the change included...
Error line 2463
That's an error in GC 3.2 preview versions (not there in GC 3.1.2) and tracked with [bugs:#880], should be fixed before the next (and hopefully last) 3.2 pre-release; there's also a patch available already (not re-checked/integrated yet).
Related
Bugs:
#880Error line 2945
For now you'd have to split this into two
DISPLAYstatements as follows:or - which from a quick glance possibly is what you want here - drop the t22, t23, ... variables and instead use
which should work with acu-cobol, too
it's a shame, because the "display t23", clears the entire line 23 and I use this system wide.
this should work, is there no way to report it as a change in GnuCobol to accommodate this?
It was either deemed to be to complicated to "easily add", or was deemed to be an error; the check was added in [r996], not sure if @edward-h remembers the details.
In theory typeck,c could emit multiple
DISPLAY(always when the type switches), but this may be a change that isn't easy...Something that is always possible is to apply a search-and-replace with an regex on the sources (the
DISPLAY tNNNcould be split to a separate statement this way), as an alternative to manually doing this.Related
Commit: [r996]
can I compile and report more problems with the Acu-cobol I use today with GnuCobol 3.2 64-bit?
wanted to switch from acu-cobol to 64-bit GnuCobol in the near future.
sure; but please check to not report the same issues - and please copy+paste code instead of pictures (ideally you could edit your previous image-posts in this thread and replace them with text-posts).
I am from Brazil!
please login, that removes the moderation queue and you can add information like this to your profile...
warning: WITH MASS-UPDATE is not implemented
does it mean it will be implemented?
I can leave it like this with-update for now in the sources?
It possibly will implemented someday, for now this means that you get normal locking behavior and performance - the
[RE-]WRITEwill work as expected.error: syntax error, unexpected +
"w-col + 4" error
That seems to be [feature-requests:#414], as I've worked on something similar sine that was created, there is now an option to change parser.y as follows to get this parsed and likely also working:
I'll need to do some testing / adjusting (with this change test 416 fails, so a bit more to do), then should be able to commit this and the other change.
Related
Wish List:
#414Last edit: Simon Sobisch 2023-03-23