Hi Jorge and welcome to GnuCOBOL,
Am 06.10.2024 um 11:48 schrieb Jorge Humberto Goncalves Lola:
I would like to ask for help from anyone who can and wants to help me.
As you kindly asked, I'm giving it a try.
First of all, I want to tell you that I have a lot of difficulty with
English, and I only learned a little English when I fell in love with
programming and Cobol, so if you help me, I will later translate into
Portuguese what I don't understand.
What is my problem?
I started using ACucobol85 in 1989, and using Acucobol's AcucobolGT as
soon as it became available, and my small company was the first to use
Acucobol85 outside the USA. I stopped updating the Compiler when
Microfocus bought Acucobol. I really need to update the compiler and I
thought about using GNUCobol, but despite it being written everywhere
that GnuCobol is compatible with AcuCobolGT, I can't generate a version
of GNUCobol that accepts the GUI syntax of AcuCobolGT, such as "display
window, display button, display label, display combo-box, pop-up list,
etc., etc.".
My questions:
1) Is GNUCobol compatible with AcuCobolGT or not?
Yes, in general, but it doesn't support all extensions itself (more
later) and at least potentially can have some differences that were not
catched yet.
In the past there were people contributing to GnuCOBOL to cater for
those differences as part of the compiler dialect, in this case for
ACUCOBOL-GT.
It does not support the VISION file types that ACUCOBOL-GT uses for
ORGANIZATION INDEXED (but if really needed you may be able to use
ACUCOBOL-GTs EXTFH interface from GnuCOBOL - obviously that still needs
an ACUCOBOL-GT license and adds one extra layer - so you likely want to
unload the data to text files, then create new files "native" to GnuCOBOL).
It currently also does not support producing the exact same io-status
codes (that's planned but not implemented), so for everything that is
not in ANSI85 or has a different status code in ISO COBOL 2023, you may
have to adjust the check (most easy: check for both ACUCOBOL and
GnuCOBOL returned codes). The "common" ones never changed, so that
change should not be "all over the place".
Some people prefer to convert to EXEC SQL on the way to store everything
in the DB, but that would mean a bunch of changes, potentially including
in the application logic.
Concerning screenio you also have the keyboard codes that _potentially_
are different - the adjustment of the key codes at runtime like ACUCOBOL
does is not supported.
ACUCOBOL-GT GUI also makes heavy use of (either explicit or implicit)
threading, which is not implemented in GnuCOBOL.
2) Can GNUCobol be used with the AcuCobolGT GUI or not?
GnuCOBOL supports a bunch of the ACUCOBOL-GT TUI extensions (and a bunch
of others), but the ACUCOBOL-GT GUI is out of scope for the next years
to come (apart from someone coming up and provide the implementation,
but that would be a lot of work).
That said, the goal for GnuCOBOL is to be able to _compile_ the GUI
extension code, raising an unimplemented warning, and execute the rest
correct.
3) If it is and can be used, how can I generate this version?
As noted: GnuCOBOL should be able to _parse_ all of those extensions and
compile and execute everything else. As it has only a limited amount of
exposure to that, this is quite likely not the case for all usages. I do
know that one application was compiled and works fine as long as it
doesn't try to use the extensions (it was an application that mixed
logic and GUI together in single programs that could either get the
input via GUI or "externally" - and as long as the data got in that way
it "just worked" - after we made several adjustments to GnuCOBOL).
I'd like to help with the parts where GnuCOBOL 3 (current development
version) does not compile ACUCOBOL-GT compatible programs.
4) Can someone help me by instructing me how to do it, step by step?
For the compile part:
1 get current GnuCOBOL 3.3 dev (either from version control or from a
nightly build - both source snapshots "tarballs" and binaries are
available) on your machine
2 compile your programs with "cobc -std=acu-strict" and other options
matching your old environment - check the docs and ask _specific_
questions on the mailing list or the discussion boards or get someone
paid to support you with that mapping directly
If you then get compile errors try to create a minimal example out of
this and send it either to the bug mailing list or open a bug ticket
with the necessary source, command line used and error you receive.
As noted: I'm happy to help with these kinds of issues.
I would be eternally grateful.
I am a person with very little education, but I have become an excellent
programmer (Currently in Cobol Mainframe for my clients in the Banking
sector).
I need GNUCobol to convert my company's software, because the version I
have in AcucobolGT has already started to give me problems.
Please, I would prefer that if you want to help me, you send me the help
by email to: jorge.lola@xxxxxxxxxx <mailto:jorge.lola@xxxxxxxxxx>
Thank you!
/*Jorge H. G. Lola*/
To be able to convert your application you need (apart from compile and
ORGANIZATION INDEXED parts and the potential io and screen io status
values - the two later mostly be relevant when you start to test the
generated result) to do "something" about the use of ACUCOBOL-GT GUI.
The following two are most reasonable approaches:
1 change to a different and portable option, for example a browser
frontend or some GUI libraries (like COBJAPI)
2 write a pre-processor (or get someone to write it) that reads in the
COBOL program, replaces the ACUCOBOL-GT GUI specific parts by data
definitions and CALLs to one of the above, then compile the resulting
code with GnuCOBOL
3 "modernize" your application:
* if not done already: completely split any GUI from the logic
(that's always a good thing, for any programming language)
* if not available yet: create "start" programs that get all necessary
data as input, and return the relevant data, if any back
* write a GUI from scratch in any language, then call the programs
above either "directly" (works from most languages via the C ABI
and with work-in-progress code also from/to Java) or via REST/
microservices/...
In any case: good luck and I'd like to see some of those "does not
compile" examples as bug reports, if there are any.
Kind regards,
Simon
