How well does GnuCOBOL handle RM/COBOL

[Brian Turner]

I have a legacy app that has over 500,000 of lines of RM/COBOL code in it spread across over 900 programs connecting with over 150 .DAT files.
Reading these forums I see lots of getting started type questions related to RM/COBOL but no sucess stories.
I don't have a grasp on how big of a project compling/porting all of this into GnuCOBOL would be.

[Vincent (Bryan) Coen]

I have just done 40+ programs and it took 4 months (off and on).
The problem here is the code was written around 1980 for small Ram systems, i,e, 640KB and floppies.

The floppy bit was simple to deal with but the system is coded to use separate modules that handle printing with one for 80 cc and the other 132 again not a real issue - took at most 4 - 6 hours.
The real issue is that it also has a modules to handle ALL screen and keyboard I/O and this module uses the oddities of RM Cobol (v1.4'ish) to accept numeric data into a pic s9(12)v9999 field where the input could be anything from 99 to 9(7v99 and it does not do it correctly at least for GC.

I have therefore had to change all such calls for numeric data input to
using an ACCEPT or a call to "ACCEPT_NUMERIC" C routine.

This during testing found a lot of errors that have needed to be fixed.

This application is OE (Order Entry) and the code base is missing some programs that handle processes outside OE but are needed such as customer maintenance (Entry, Amend, Display, Print etc), OE control file maintenance, AR (light) maintenance and a program to create all files if only as empty one's.

The idea was to migrate it over to my now Open Sourced ACAS Accounting System, but in fact the only added features it has are limited Back Order processing (no re-invoicing etc), Salesman commissions (but no Payroll that is also not supplied in ACAS as it needs to be maintained for all countries it will be used in - could be a long list).
I decided to just add in the same functionality in OE into ACAS which is complete but have also added BO processing into the invoicing program (still under testing as found a few bugs in the new code).

Some one did try and migrate the OE code just using the RM setting but with a number of issues but many of these relate to the bugs in the original code and the way it uses SCREEN module for I/O.

So you may well be a lot more successful.

You, have to decide if you with GC to work as is using the RM dialect with hopefully minimal changes OR if you have similar modules that do similar to OE SCREEN handling will need to make possibly a lot of changes.

I need to point out that the OE sources before copy books added in are around 1,000 - 1,400 lines with around 140 copy book files and I had to change a large number of them for various reasons which you might not need to do but I recommend you check them all if only to examine any usage Declaratives and use of screen handling special keyboard keys etc as these will need changing as well as possibly file error codes etc. 
Original misused the code used where some over rid others etc.

Changes to the file names and any embedded paths etc, used may well also need changes.

[Simon Sobisch]

Additional to what Vince wrote: it always depends on how much "standard COBOL" was used. The more "clean" the old code was, the less changes are needed.
Compiling with -std=rm-strict should definitely help to reduce the necessary code changes (and ignoring compiler warnings at the start).
I'd expect GnuCOBOL to compile the code - please create a bug report with a minimal example for each issue if you find that this isn't the case. Depending on the amount of code changes in GnuCOBOL these may be solved fast, helping with your migration.

If there are "special things" in fileio (including, but not limited to paths), this needs either a change in the programs or creating of an EXTFH handler which you'd need to create (that sits "between" the application and the fileio rts, so you can adjust hardcoded paths and other file attributes "dynamically") . The later is mostly useful if there would be a lot of changes to code and you prefer the sources to be unchanged.

The "biggest" part may be the .DAT files - at least for ORGANIZATION INDEXED as you likely need to "unload" those to text using the "old" environment, then load them into GC in the reverse. You may be able to read those with an EXTFH handler "unchanged" by reverse-engeneering or by external EXTFH handlers that can handle those.

Screenio can be an issue, depending what is used and how. Often people want to move away from "terminal input" in a migration process then this needs changes independent of the target compiler.

If the operating system before/after the migration is different, then you may need to adjust something related to that.

If there are missing system routines (I think that was C$ for RM, no?), they can be added either to GnuCOBOL "by someone" or written in COBOL/C and just being made available locally.

Compiling with --debug will lead to infused runtime checks which commonly shows old bugs - that may have a different execution result with GC. Those would need to be checked and decided if the result is "as expected"/"doesn't matter", or if you need to adjust the source. If you don't use it, I'd suggest to compile at least with -fsource-location so if there is a runtime error you have a good idea where it happens.

After all: just give it a try and see where this leads, in case of issues you have this discussion board (and "commercial support" for handling part of this would also be available, if you feel the need for that).

Just get started and write the success story you'd like to read :-)

[Brian Turner]

Thanks for the input. I know that it uses a lot of screens stuff. I am not looking to change that until after we get it off of the legacy OS into something safe. I may just buy RM/Cobol for windows. But we really need to be able to access the data from Excel for reporting. I know that GnuCOBOL does not do that automatically but it may change the decision process.

[Mickey White]

Brian, are your Excel files on windows or linux ? Are they MS excel files .xls ? or LibreOffice calc .ods files? Are there many of them?

[Brian Turner]

@jamesbwhite We use Excel mostly on Macs.

I tried to compiled one of our most common programs. I got several screenfulls of errors. The three most common repeating ones were:
error: 'HIGH' is a reserved word, but isn't supported
error: 'LOW' is a reserved word, but isn't supported
warning: CONTROL KEY is not implemented [-Wpending]

The first two were easy. A quick google showed that HIGH is short for HIGHLIGHT. So a global search and replace fixed those.
Googling the third one led to some threads on here that implied gnucobol does not do it yet, and that changing the code to use the normal cobol way of catching keystrokes from the user was the way to go. I don't know how to do that, but it sounds like a refactoring would be needed. Across 600,000 lines of code would take a couple man months to do manually, so writing a refactoring script would be needed. This is generally beyond my abilties, and all of this will take about $60,000 worth of time for testing the results.

So I have hit a wall that means I need to hire a cobol programmer, company, or buy RM/COBOL for windows. Each of those options is $80,000 or more for the project. But they are safer than continuing down the gnucobol path.

I was also able to confirm much of @sf-mensch comments.

Unless you guys can point me in a path around this, my gnucobol explorations are over for the time being.

[Mickey White]

Brian, I was interested when you said cobol could not access Excel. While that is true directly, you can convert MS Excel and LibreOffice Calc spreadsheet to XML and then read through the new .xml file and find all the cell information and print it out like a table or a report. And you can even update and delete or add cells. And then convert back to a spreadsheet. And more.
Good luck on finding optional ways to do screens, I have not much used the screen section, as we wrote (very simple) HTML and CGI web interfaces and then used perl and GnuCOBOL in the backend.
Later.

[Paulo Reis]

Hello Mickey,
I have an application in RM Cobol and I intended to convert it to GnuCobol with a graphical interface... This option of HTML and CGI for Web interfaces seems interesting, but I don't know how to start. Can you show an example?
Thanks

[Mickey White]

I will have to look and see if I can figure it out. It has been a few years, and I retired since then. I have not done any since, as I do not have a web server or Apache running on my home system. I will let you know , it may take a few days....

[appletonc]

Converting RM-COBOL screen IO to GNUCOBOL or MF is essentially a rewrite.

Even moving from the legacy OS to MS Windows will likely require some work.

Have considered using an OS emulator such dosemu or DOSbox.

Converting the data into CSV format (w/wo headers) for import should be relatively easy to automate do as long as the input is in DISPLAY format.

In the old days I used CSV format to import data into MS Access.

[alex bodnaru]

CSV is almost excel.

[Alain Reymond]

Perhaps this contribution is a little late...

We have a project of roughly the same size, divided into two applications, one with 150 programmes, the other with 750 programmes. It's not RM/Cpbol but MF.

We're running on Linux and use VSCode + Superbol (thanks to them!) for the write/compile/debug cycle and Codeium to make writing the code easier.

We were able to port the first part, which is in 'standard' Cobol, fairly easily. The characteristics of the code include
* free format,
* structured programming (as far as possible!)
* all keyboard/screen I/O in the screen section
* ISAM files

For the files, we simply exported the ISAM files in line sequential, reimported them and recreated the ISAM files in the Gnucobol environment.

The points of attention were as follows:
- the "accept on exception / not on exception" management had to be modified because we make extensive use of cursor up/down management with x'AF' under MF. We therefore had to restructure the 'accept' part to have the same functionality.
we were unable to make dynamic attribute changes work in the "screen section" and had to revert in some cases to accept/display sequences in procedure division.
the pic 9999/99/99 does not work, unlike MF, which is annoying when dealing with dates. Instead of

1 myDate pic 9(8).
screen section.
1 myscreen.
     2 line 1, col 1, pic 9999/99/99 using mydate.
procedure division.
accept myscreen

we had to do

1 mydate pic 9(8).
1 mydate-ymd redefines mydate.
  2 mydate-y pic 9999.
  2 mydate-m pic 99.
  2 mydate-d pic 99.
screen section.
1 myscreen.
  2 myscreen-date. 
    3 line 1 col 1 pic 9(4) using mydate-y.
    3 value "/".
    3 pic 99 using mydate-m.
    3 value "/".
    3 pic 99 using mydate-d.

• for duplicate keys in Isam files, we have noted (as previously mentioned) a very sharp increase in write times if the number of different keys is reduced in relation to the number of records.
  In the end, nothing too serious.

The second part is more complex because it uses embedded SQL for Cobol (Postgres). We use Gixsql but :
* gixsql does not support the free format,
* gixsql adds information in characters 1 to 6,
* the "declare section" part and copy management is a little different
* gixsql is case-sensitive for variable names in SQL statements.
We therefore had to develop a small Python script to modify the code before calling gixsql and then on the code generated by gixsql, but with this, the precompilation works and we can compile with gnucobol.
Managing a free format would therefore be a feature to add to gixsql.
For the graphics, we're using a library that uses apache. We're continuing with the transposition phase at this level...

In the end, it is mainly a question of making one-off changes to the code, with the essential elements remaining unchanged. Extended testing will validate all this!

[Brian Turner]

@alain Thanks for the Superbol and Codium referals. We are moving forward with a port of RM/Cobol to Windows from SCO Unix. The licensing from Rocket Software is pricy at 10s of thousands. But as I wade into the Cobol code itself and their Codewatch IDE it is not nearly as bad as I feared.
I have been able to combine VSCode and Codewatch with some degree of productivity. I use VSCode to answer questions like how many programs call Mutt? Then I use Codewatch to step through the code with debugging. I was also using Chat GPT to give me code snippets with proper syntax. I will try Codium for that.
I have not touched any of the Screens code but it looks reasonable. It clearly does a lot of things by default that are a bit of a mystery at this point.