cobc: too many errors
An entry in Special-Names that GnuCOBOL does not recognize causes the scanner to emit a gazillion errors. Is there a list of Special-Name entries that are meaningful to GnuCOBOL ? What I would like to do is preprocess a source COBOL program and comment out any Special-Names entries that causes the GnuCOBOL scanner to get lost.
Are there Special-Name entries that are required of a GnuCOBOL program to compile without errors ?
Hey Ralph, hope your work on the MVS/Zos simulation xpeditor ide is going well.
Did you look in the Appendix B - Reserved Word List in the programmer ref guide for gnucobol? I see the argument-number and all listed there.
Good Day Sir !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Windows
Version 3.1.2 from Arnold's web site.
Vincent here is all of Special-Names.
The diagnostic terminates the compile with too many errors.
Every statement after the diagnostic is in error as the scanner searches for
Procedure Division.
Micro Focus Compile:
Compiling ARTBATCH.COB...
Compilation complete with no errors Build finished with no errors.
Completed in 0 seconds
Fujitsu Compile:
DIAGNOSTIC MESSAGE (ARTBATCH)
JMN2540I-W 414 PARAGRAPH INCLUDING EXIT STATEMENT MUST CONSIST OF ONLY PROCEDURE-NAME AND EXIT STATEMENT. EXIT STATEMENT IGNORED.
**HIGHEST SEVERITY CODE = W **
Last edit: Ralph Linkletter 2021-07-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All of the references you are using are NOT available under Special Names.
Please read the PG manual (v3.1.2) for possible replacements.
You could request via the requesting a new feature these via the Feature
reporting facility if they are important however the first four are
available via ACCEPT.
For SYMBOLIC constant you can use 88 level vars and set these up for
each prog but again you could request this as a feature request and the
first four 'should' be easy to implement sans @Simon.
Vince
mod edit to remove some reply-to
Last edit: Brian Tiffin 2021-07-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
::text
-fmax-errors=<number> maximum number of errors to report before
compilation is aborted
* default: 128
And yes, the combination of COBOL with the plethora of reserved words, and the current Bison/Flex sources for GnuCOBOL, makes for less than optimal compile time error reporting. Always getting better; good, but not yet best.
For the now, comment out ARGUMENT-NUMBER, ARGUMENT-VALUE, ENVIRONMENT-NAME and ENVIRONMENT-VALUE from the SPECIAL-NAMES clause. These are already defined as root words.
Cheers,
Blue
Last edit: Brian Tiffin 2021-07-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is a detail rich area of GnuCOBOL configuration.
There is also,
::text
cobc ...
-list-reserved display reserved words
-list-intrinsics display intrinsic functions
-list-mnemonics display mnemonic names
-list-system display system routines
that should match any givencobc -std= or -conf= compiler options.
Those outputs will take some, but not much, twiddling to get to a machine readable form to feed a preprocessor.
Another alternative might be brute force. Run cobc, snag the first error, use vim or similar errorformat to read the standardized error messages (filename, line-number, message), comment out the code on the given line-number, save, rinse, repeat.
If you use vim, I can see this being a fairly fun macro to record using quickfix commands. If not, then a script and some mucky muck will probably do for the rinse and repeat part.
Cheers,
Blue
Last edit: Brian Tiffin 2021-07-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why not just regard the whole of special names as comments? If deeper in the code a reference is made to an item declared in the Special-Names section I would think that a more focused diagnostic would be issued.
At a minimum tolerate known / required elements within Special-Names.
Entries like these mean nothing to GnuCOBOL but are significant to other COBOL compilers.
I think it a matter of first impressions.
For instance a Micro Focus or Fujitsu COBOL programmer attempting to use GnuCOBOL compiles a Fujitsu or Micro Focus program that has entries within the Special Names section supported by MF or Fujitsu. The GnuCOBOL compile of these programs results in "too many errors". The first impression might be "not ready for prime time". At which point GnuCOBOL is discarded as a viable alternative to MF / Fujitsu.
Historically GnuCOBOL seems intent upon appealing to the hobbyist / tinkerer.
There are exceptions obviously.
I consider GnuCOBOL to be a viable alternative - with limits - and especially requires perseverance and patience.
Ralph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"...none may be used as any user-defined name.
This list includes ALL reserved, intrinsics, mnemonics and system and shows some 1100+
words in total." we use argument-value and aurgement-number all the time.....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cobc: too many errors
An entry in Special-Names that GnuCOBOL does not recognize causes the scanner to emit a gazillion errors. Is there a list of Special-Name entries that are meaningful to GnuCOBOL ? What I would like to do is preprocess a source COBOL program and comment out any Special-Names entries that causes the GnuCOBOL scanner to get lost.
Are there Special-Name entries that are required of a GnuCOBOL program to compile without errors ?
The compilation erroneously flags every statement after an invalid Special-Names entry.
The result is cobc: too many errors.
Ralph
Last edit: Ralph Linkletter 2021-07-23
Hey Ralph, hope your work on the MVS/Zos simulation xpeditor ide is going well.
Did you look in the Appendix B - Reserved Word List in the programmer ref guide for gnucobol? I see the argument-number and all listed there.
Good Day Sir !
Is the Special names section terminated by a period as it is not shown
in the example provided and this will cause the compiler to spew error msgs.
What version of GC are you using and on what platform?
The PG does NOT show this as an option i.e., ARGUMENT-NUMBER as the
index shows but is a part of the DISPLAY and ACCEPT functions ONLY.
VInce
?
mod edit to remove some reply-to
Last edit: Brian Tiffin 2021-07-24
Windows
Version 3.1.2 from Arnold's web site.
Vincent here is all of Special-Names.
The diagnostic terminates the compile with too many errors.
Every statement after the diagnostic is in error as the scanner searches for
Procedure Division.
Micro Focus Compile:
Compiling ARTBATCH.COB...
Compilation complete with no errors
Build finished with no errors.
Completed in 0 seconds
Fujitsu Compile:
DIAGNOSTIC MESSAGE (ARTBATCH)
JMN2540I-W 414 PARAGRAPH INCLUDING EXIT STATEMENT MUST CONSIST OF ONLY PROCEDURE-NAME AND EXIT STATEMENT. EXIT STATEMENT IGNORED.
**HIGHEST SEVERITY CODE = W **
Last edit: Ralph Linkletter 2021-07-23
All of the references you are using are NOT available under Special Names.
Please read the PG manual (v3.1.2) for possible replacements.
You could request via the requesting a new feature these via the Feature
reporting facility if they are important however the first four are
available via ACCEPT.
For SYMBOLIC constant you can use 88 level vars and set these up for
each prog but again you could request this as a feature request and the
first four 'should' be easy to implement sans @Simon.
Vince
mod edit to remove some reply-to
Last edit: Brian Tiffin 2021-07-24
As an aside:
And yes, the combination of COBOL with the plethora of reserved words, and the current Bison/Flex sources for GnuCOBOL, makes for less than optimal compile time error reporting. Always getting better; good, but not yet best.
For the now, comment out
ARGUMENT-NUMBER,ARGUMENT-VALUE,ENVIRONMENT-NAMEandENVIRONMENT-VALUEfrom theSPECIAL-NAMESclause. These are already defined as root words.Cheers,
Blue
Last edit: Brian Tiffin 2021-07-24
Edward added some features, slowly expanded on and tuned by all for compile time reserved word handling.
This is a detail rich area of GnuCOBOL configuration.
There is also,
that should match any given
cobc -std=or-conf=compiler options.Those outputs will take some, but not much, twiddling to get to a machine readable form to feed a preprocessor.
Another alternative might be brute force. Run cobc, snag the first error, use vim or similar errorformat to read the standardized error messages (filename, line-number, message), comment out the code on the given line-number, save, rinse, repeat.
If you use vim, I can see this being a fairly fun macro to record using quickfix commands. If not, then a script and some mucky muck will probably do for the rinse and repeat part.
Cheers,
Blue
Last edit: Brian Tiffin 2021-07-24
Why not just regard the whole of special names as comments? If deeper in the code a reference is made to an item declared in the Special-Names section I would think that a more focused diagnostic would be issued.
At a minimum tolerate known / required elements within Special-Names.
Entries like these mean nothing to GnuCOBOL but are significant to other COBOL compilers.
I think it a matter of first impressions.
For instance a Micro Focus or Fujitsu COBOL programmer attempting to use GnuCOBOL compiles a Fujitsu or Micro Focus program that has entries within the Special Names section supported by MF or Fujitsu. The GnuCOBOL compile of these programs results in "too many errors". The first impression might be "not ready for prime time". At which point GnuCOBOL is discarded as a viable alternative to MF / Fujitsu.
Historically GnuCOBOL seems intent upon appealing to the hobbyist / tinkerer.
There are exceptions obviously.
I consider GnuCOBOL to be a viable alternative - with limits - and especially requires perseverance and patience.
Ralph
"...none may be used as any user-defined name.
This list includes ALL reserved, intrinsics, mnemonics and system and shows some 1100+
words in total." we use argument-value and aurgement-number all the time.....