gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUCobol with GUI AcuCobolGT compatibility.


From: Simon Sobisch
Subject: Re: GNUCobol with GUI AcuCobolGT compatibility.
Date: Sun, 6 Oct 2024 12:53:40 +0200
User-agent: Mozilla Thunderbird

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@trivial.pt <mailto:jorge.lola@trivial.pt>


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]