COBOLworx Fact Sheet

History

COBOLworx is a division of Symas Corporation. The division was founded in 2015 in response to requests from industry partners for Open Source Software alternatives for current mainframe users.

COBOLworx’s first project was a prototype for a replacement for the IMS/DB (HIDAM) database subsystem. This had been specifically requested by the partner. This work led to development of the GnuCOBOL Debugging Extensions for GDB, the first instance of a source-level debugging capability for COBOL programs. This work was presented at an IBM Users Group meeting in 2018.

At the time, COBOLworx depended on GnuCOBOL as its compiler. Members of the team became committers and assisted the GnuCOBOL project to pull together GnuCOBOL 3.2.

In 2021, COBOLworx committed to developing a new COBOL compiler for inclusion in the GNU Compiler Collection (GCC). The work is based on the COBOL Language International Standard (ISO-IEC 1989:2023). In the fall of 2024 COBOLworx began the process of submitting GCC COBOL for inclusion in GCC Release 15.

Technical Rationale for Developing GCC COBOL

GnuCOBOL has been under continuous development since at least 2000. The compiler processes the COBOL program by translating it into C language. The GCC C compiler is then used to create the executable module. The C language intermediate step works well and produces small and efficient programs across the range of GCC’s portability.

Two things convinced COBOLworx that producing a true GCC-based COBOL compiler was important:

1. GCC is a large and very active project. COBOLworx recognizes that it can be difficult to introduce Open Source Software packages into larger firms, institutions, and agencies. We felt that being part of GCC would significantly reduce that concern.

2. GCC produced outputs from COBOL programs that contained all the structural information, such as line numbers, from the C-language intermediary source code. Early experience with source-level debugging with GDB was frustrating. We knew that if we started clean and eliminated that step, debugging would be simpler and easier to maintain.

There is a third factor. COBOLworx hopes that GCC COBOL, as a member of the collection, will attract outside contributors. While adding contributors always means project complexity, the long-term health of GCC COBOL would be best if the team grew.

Business Rationale for Developing GCC COBOL

COBOLworx learned from Symas. Symas has run a successful and profitable business by providing very high quality commercial technical support to users of otherwise free and open source software. Most smaller users will happily adopt and use a package for free and depend on Internet advice sources. But larger end-users are not willing to go without a dependable and capable technical support provider.

GnuCOBOL drove a few enterprises to COBOLworx for technical support, and we expect more. We also expect more COBOL shops to be interested as GCC COBOL becomes part of the GNU Compiler Collection.

GCC COBOL Design Overview

The GNU Compiler Collection supports many source languages: C, C++, Go, FORTRAN, Ada, and COBOL. Each language has a “Front End” that processes the source code and interacts with GCC’s internals so GCC can construct the Abstract Syntax Tree (AST) from which it will build machine-readable programs.

The AST is a machine-independent view of the program’s logic and data. Most modern compilers build an AST from which they construct the machine-specific code. GCC has long maintained many methods by which programs are produced from the same AST, each creating programs for specific chip architectures and operating systems.

GCC COBOL works with GCC’s intermediate representation during early source-program phases. The “Back End” then, optionally, further processes the representation for various optimizations, such as speed or program size. These are standard GCC capabilities. Finally, the program is reduced to machine instructions used by the target chip architecture and an executable is built using the operating system’s native interfaces.

As well as logic and data descriptions, the GCC COBOL front end can provide debugging information. GCC takes that information and packages it into the appropriate form for the GNU Project Debugger (GDB). The user can either request debugging information in the resulting program or not. The machine instructions of the program are identical whether or not debugging data is included.

If debugging information is included, the module is larger, but GDB can be used while it is running to sort out issues in real time if needed.

GCC COBOL is written in C++. Approximately 130,000 lines of C++ code were added during the GCC 15 development effort, along with changes elsewhere in GCC required to accommodate the new language.

The COBOL language specifies a Compiler Directing Facility, which is processed before the actual compilation of the source program. The rest of the compiler has roughly two major parts: the parser processes and deconstructs the source code, and the AST builder processes that result and feeds it into GCC’s internal processing.

In addition to the compiler itself, there are many intrinsic functions that perform date-time, financial, mathematical, and related computations specified in the COBOL standard.

For a concise overview of the compiler and its goals, see GCC COBOL.