Simon Sobisch

Opening a new thread does make sense, please do so under "contrib". In general it is important to have all three of: cob_screen_accept: get a screen that commonly has multiple fields, some function keys are not returned but handled internally for navigating through the fields, some attributes likeAUTO have a different result (for example moving to the next field)( cob_field_accept: get a single field (also called from cob_accept if extended screenio is active), provides some additional function keys...

Opening a new thread does make sense, please do so under "contrib". In general it is important to have all three of: cob_screen_accept: get a screen that commonly has multiple fields, some function keys are not returned but handled internally for navigating through the fields, some attributes likeAUTO have a different result (for example moving to the next field)( cob_field_accept: get a single field (also called from cob_accept if extended screenio is active), provides some additional function keys...

Ralph just noted what commonly used "AI" models currently tell. And as noted: there are banks and government environments where GnuCOBOL is used in production, as well as a bunch of others. The models just weren't trained with this information.

So what is exactly missing in GnuCOBOL to be able to use these programs as-is?

as you've said: Some time ago we wrote about the problems and I'm going to try to find the document. so that's one of the things I'll inspect

I highly suggest to upgrade to GnuCOBOL 3.2 (or at least 3.1.2) as this includes a lot of changes to make using GDB directly much easier. It is also needed if you possibly want to do core-dump debugging. Version 3.1.2 is also the prerequiste for COBOLworx cbl-gdb which makes the whole debugging within GDB a lot easier. If you want to run on the terminal using PuTTY and can't move from GC2 you may try to use cobgdb - while it officially asks for GnuCOBOL 3.1.2+ it is not unlikely that it works with...

Getting this to work correctly means foremost to either stick to DOS (or a "well enough" emulator) and a DOS "terminal" which can handle CP860 as well as escape sequences. To move somewhere else the assembler parts need to be rewritten. Also the encoding has to be either adjusted in the source code to match the terminal or it has to be adjusted "on the fly" which may be possible soon with the upcoming iconv-integration. Giving those sources a quick compile check with cd C:\RMCOBOL mkdir gclib cd...

I don't see documentation on most of this; I found I had to discover it through extensive testing. For ambiguous paragraph names, the IBM compiler issues a severe error (highest besides terminating) but nonetheless finishes the compile and runs the program. It actually discards the offending PERFORM or GO TO line. But I think being more permissive is ok (maybe in the IBM dialect disallow so people don't write programs that won't work on ibm). Your final questions are correct, if you don't reference...