Does anyone have information for migrating from Fujitsu to GnuCOBOL?

[Mark Campbell]

I am working on a proof of concept project to migrate from Fujtisu COBOL to GnuCOBOL. However, I am receiving many build errors. Does anyone have information on what are the best compile options to use when migrating from Fujitsu to GnuCOBOL? Also, the compiled Dlls and EXEs need to be 32-bit.

Thanks!
Mark

[Chuck Haatvedt]

Mark,

I have some experience with Fujitsu COBOL. However the person I would consider to have expertise with Fujitsu COBOL is Ralph Linkletter and he does participate on these forums.

If you would like some hands on assistance, you can contact me on Microsoft Teams, you can contact me there at chaatvedt1@outlook.com

if that does not work for you, please post some of the build errors you are encountering and I will take a look at them.

        Thanks
           Chuck Haatvedt

[Simon Sobisch]

side note: I still heavily suggest to use Jitsi for ad-hoc meetings and Matrix for possible ongoing discussions over using proprietary software (which nowadays also feeds into AI)

[Simon Sobisch]

That migration should be not problematic in general. As you want 32bit on Windows you'd want to use a 32bit build, for the POC possibly using the latest 3.x nightly generated by Appveyor (has no XML support, but that's no problem as that isn't available with Fujitsu either).

See https://sourceforge.net/projects/gnucobol/files/gnucobol/nightly_snapshots/ and use the "MinGW ready-to-use-binaries" link.
[Side note: Appveyor currently has issues so the non MinGW ones have to be selected manually]

As we still have no Fujitsu configuration (I'm waiting for someone to provide the two config files necessary for that) you possibly want to compile with cobc -frelaxed-syntax-checks and if you stumble over reserved words that were not available with Fuji add -fno-reserved=HANDLE,OTHERWORD as needed.

Possible issues you see:

• for ORGANIZATION INDEXED you'll need to unload/load the files before you can do runtime tests
• @OPTIONS is recognized but not handled -> manually set correct matching options [common ones could be added to cobc relative easily]
• Fuji presentation files are not supported - someone would have to look in detail what's needed for that, could be added, but is likely more effort (compiler and runtime)
• CONSTANT SECTION and BASED-STORAGE SECTION are not supported yet - either use the standard options or - in case for constants - the common level 78 extension instead; adding those sections to our extension support is relative easy and a parser (+ ideally dialect support option for constant section) change
• special-names can still break the parser in some places - often those can be commented out (fixing that is some more effort in the parser, but still doable)
• some runtime library calls may not be present - the screenio related one have a draft from Chuck, so his 32bit builds that he did for Ralph may be useful; overall it is relative easy to add missing ones
• external file handler is likely different - you'd either need a wrapper or replace to the "industry standard"

I'd suggest to do an "inventory compile" as noted above (with possibly several runs adjusting the reserved words), then make a list what the unclear issues and necessary changes are; and then consider to do the adjustments in GnuCOBOL (or get someone to do that, Titagone - OCamlPro and COBOLworx are options for paid changes, as well as I) to not need to do any changes in the code (that's what GnuCOBOL's goal is in nearly all places).
OCamlPro and I would also be available to help with the POC itself (which is mostly useful if you have a short time-constraint with it).

You'd likely weight the effort of changing the COBOL part and do necessary extra tests as result vs. the effort to extend GnuCOBOL as needed for each point.

You may also start doing a draft of the dialect configuration files (reserved word list + "strict" configuration, checking each point to the documentation).