Am 12.06.2022 um 19:44 schrieb W Burke Cabaniss:
I found you by Google search for a gnucobol user group.
Welcome to GnuCOBOL!
I have written COBOL for 60 years (really) and am considering use of cobc with RM COBOL source. Perhaps you can help me with two initial issues: 1. The std=<dialect> parameters include "rm". Is this Ryan McFarland COBOL?
Yes. The std files (found under "config") commonly have a comment about the details of the dialect, but the RM files actually don't have that. One thing to now: `-std=rm` will be "rm-like" but also support features from other dialects, which is not unlikely to lead to a "name clash" with the reserved words and once coded against `-std=rm` the code may not compile on the original compiler any more (because of those newer features, allowing longer user defined words, bigger literals, ...). So depending on your context you may want to use one of the following instead (or not): -std=rm-strict -std=rm -fnot-reserved=WORD1,WORD2
2. My biggest problem is screen character attributes.
Extended screenio (everything but a simple DISPLAY/ACCEPT) is one of the places where many dialects added extensions. Not all of these are supported in GnuCOBOL yet.
My RM programs have DISPLAY ...... CONTROL <data name> where the data name specifies multiple attributes (color, highlight, etc.). The gnucobol manual DISPLAY options for this are multiple and verbose. I can think of two ways to handle this: prefix the display data with hex screen controls or create a called subroutine for all DISPLAY functions.
Using hex screen controls is highly non-portable, so if you can use a different option I'd always recommend to do so. Putting _every_ user interaction into sub-programs is actually "good style" - if you want to later change from a plain text user interface to a GUI or a web frontend and you have done the user-interaction completely in sub-programs then you likely only have to adjust those - and may also be able to add a "switch" which one to use (for example by putting the screenio programs in a sub-folder or into a different library, so switching the COB_LIBRARY_PATH or COB_PRE_LOAD entry switches the UI).
I actually have done the latter, successfully, with other COBOL's. I only need four sets of screen attributes. But I am curious if others have found better ways, or if there is a cobc syntax method I missed.
Actually Christian Lademann worked display/accept attributes and also on DISPLAY ...... CONTROL <data name> last year in the "xad" branch. It looks like the parser part is completed but the actual attributes are not taken over into the runtime. I think we should get at least the CONTROL syntax into the next version (wouldn't harm as "CONTROL" is a general reserved word so can't be used in there) as "pending" (= code would compile with a warning and ignore the control value for now). @Christian: Did I miss something in the XAD branch about CONTROL being fully implemented? If yes: can you please add a testcase there to run_manual_screen.at, if not add the codegen/runtime part for CONTROL?
Please reply in any case. I will appreciate any advice.
As noted: I highly suggest using (switchable) programs that do the UI handling, passing only the command (like "request data" / "display data") and a record of the actual data - this allows you to switch easier between different COBOL dialects and also between user interfaces. Simon
