Compilers and Dialects

Enterprise COBOL 6.x is the compiler behind everything on the mainframe pages. Its language grew by release, and the current facts are collected in What’s New in COBOL:

IBM keeps a table of the 2002 and 2014 standard features that Enterprise COBOL 3 and later implement (the Language Reference appendix "2002/2014 COBOL Standard features implemented in Enterprise COBOL 3 or later versions"). It is the authoritative answer to "does IBM do feature X from the standard", and the feature-support table below is built from it. Two entries of that table are worth knowing before reading on: Report Writer features are supported through an optional Report Writer precompiler, not by the compiler itself, and user-defined types (TYPEDEF and TYPE) are implemented. IBM’s documentation library page lists the manuals for 6.5 back to 3.1 and says that for versions that are no longer supported only the PDFs remain available, so check IBM’s lifecycle pages before planning around 6.3 or 6.4.

Source: IBM: 2002/2014 COBOL Standard features implemented in Enterprise COBOL

GnuCOBOL (formerly OpenCOBOL) is a source-to-C translator: cobc turns the COBOL into C and a C compiler (here gcc) builds the executable or module. Besides its own default dialect it can imitate the COBOL 85, X/Open, 2002 and 2014 standards and eight vendor compilers through the -std= option, described next. Version 3.2 added the gcos dialect, more -fformat source formats, STOP ERROR, --coverage, LINE SEQUENTIAL OPEN I-O and REWRITE, the COBOL-WORDS directive and experimental UTF-8 and FLOAT-EXTENDED support. Packaging differs by platform: Homebrew’s gnucobol is 3.2, Debian’s gnucobol3 package is 3.2 on trixie and 3.1.2 on bookworm, and the Debian gnucobol4 package is a 2020 snapshot that should not be used.

Rocket Visual COBOL and Enterprise Developer are the successors of the Micro Focus products; the old Micro Focus documentation index has been replaced by Rocket’s documentation portal. Their dialect is the one GnuCOBOL calls mf. Fujitsu NetCOBOL for Windows, per the distributor’s page, is ANSI COBOL compliant with compatibility for VS COBOL II, OS/VS COBOL and Micro Focus, embedded SQL through ODBC and Oracle, COBOL-to-XML conversion, Unicode and multi-threading; GnuCOBOL has no fujitsu dialect, so NetCOBOL programs are ported by hand. Version numbers of both products are deliberately not pinned on this page because their documentation could not be checked in full on 2026-10-20.

cobc --help lists the dialects below, apart from realia, which is documented in the manual and is accepted (the file realia.conf exists and a program compiled with -std=realia is checked against it) but is missing from the help text of 3.2. The name: column is the first setting of each file, which is what the compiler calls the dialect.

The reserved-word counts come from cobc -std=<dialect> --list-reserved | grep -c ' Yes' and are a measure of how large each language is, not a promise about any vendor’s list. The range, 350 words for COBOL 85 against 944 for the GnuCOBOL default, is why a program written for one dialect can fail in another merely because it uses a data name that is reserved in the second: -fnot-reserved=<word> removes one offending word from the list (the option is repeated for each word), and -freserved-words=<value> takes the complete reserved-word list from a different dialect than the one in -std. (The 3.2 manual spells the first option -fno-reserved; cobc --help and the compiler itself accept only -fnot-reserved.)

The -strict variants try to limit both the feature set and the reserved words to the named compiler, so that a source that compiles with cobc -std=ibm-strict is likely to compile with IBM’s compiler, and the reverse. The plain names (ibm, mf, …​) are the lax versions: they switch on the complete GnuCOBOL feature set wherever it does not conflict with the dialect, including its reserved words, so the program may then work only with GnuCOBOL. COBOL 85, X/Open, COBOL 2002 and COBOL 2014 have no lax versions.

The files make this concrete. ibm.conf is four lines long: it includes the strict file, renames the dialect, adds the extra word list ibm.words and includes lax.conf-inc, which relaxes a long list of settings (it lifts the word, literal and PICTURE length limits to GnuCOBOL’s, accepts the TYPE, SAME AS and USAGE type clauses and the level numbers 01 and 78 constants, relaxes the level-hierarchy checks, and so on). The substance is in ibm-strict.conf:

Source: GnuCOBOL Programmer’s Guide: Compiler Configuration (config/*.conf)

Some settings of the IBM and the GnuCOBOL default files, as printed in the 3.2 distribution, show what a dialect changes in practice:

The first row has a visible effect on every program that counts, so it is worth running.

WS-COPIES is a three-digit binary counter, like the number of copies of a book. The program adds one to 999. Whether the result is 000 or 1000 is exactly the difference between a binary field that is truncated to its PICTURE and one that is not.

Compiled with cobc -x -Wall and different dialect options (no warnings were printed by any of the four compiles):

Source: GnuCOBOL Programmer’s Guide: -std and compiler configuration

The default dialect truncates to the PICTURE (binary-truncate: yes), the IBM dialects do not (binary-truncate: no), and -fno-trunc ("allow numeric field overflow" in cobc --help) switches off the truncation without changing anything else. This is not a claim about what Enterprise COBOL does with the same source: on z/OS the result depends on the TRUNC compiler option, whose default (TRUNC(STD)) truncates, so -std=ibm is a close imitation of the IBM language but not of every IBM option. The full treatment of TRUNC, COMP, COMP-5 and the hardware sizes is in USAGE and Numeric Representation.

A shop that wants "the default dialect, but with IBM’s binary behaviour" does not need to edit the installed files. cobc --conf=<file> reads a user-defined configuration; the file may include any installed one by name and override single settings after it:

With the same source as above:

Source: GnuCOBOL Programmer’s Guide: --conf

The GnuCOBOL manual writes the option as -conf=; cobc --help in 3.2 prints --conf=<file>, and that is the form that was run here. The same page also says that any single configuration option can be given as its own -f flag, which is how -fno-trunc and -fformat= work.

The reference format (columns, indicator area, free form) is a configuration value too, and -fformat= or the >>SOURCE FORMAT directive selects it. 3.2 accepts nine values; -fixed and -free (alias -F) are shorthands for the first two. The details of fixed and free format are in Reference Format: Fixed and Free.

An unknown value is rejected by the compiler (-fformat=bogus and -fformat=gcos both print "invalid value …​ for configuration tag 'format'"). The IBM dialects set format: cobol85, which is why a paragraph name written in Area B is not just style, as the next example shows.

This deliberately wrong program starts the paragraph name MAIN-PARA in column 12 (Area B). The default dialect does not mind; the IBM dialects check the Area A rule that mainframe programmers are used to.

Source: GnuCOBOL Programmer’s Guide: Source format

Lax dialects turn many of the strict dialect’s errors into warnings, and a warning can be silenced with -w or -Wno-others; the strict dialect stops. Compiling with -std=ibm and -Wall and fixing every message is the cheapest way to move a GnuCOBOL program toward the mainframe.

The same four-line change shows how a dialect decides what compiles. MONEY-T is a reusable type for a price or a fine, as in the Circulation copybooks.

The program is accepted without warnings by the default dialect, by -std=cobol2014 and by -std=ibm:

The second line shows another dialect setting at work: pretty-display is off in the IBM files, so DISPLAY prints the digits of PIC 9(4)V99 without the decimal point, as Enterprise COBOL does. Under the strict IBM dialect and under COBOL 85 the program is rejected, and the first error is the one that matters, because the others are its consequences:

The ibm-strict dialect describes the older IBM compilers, where TYPEDEF is not a reserved word, so the clause is a syntax error; the lax ibm dialect keeps the extensions switched on. Enterprise COBOL itself accepts TYPEDEF from release 6.5, the base release that introduced it. Real mainframe code must therefore be compiled with the lax dialect to stay close to 6.5, or kept free of TYPEDEF if it must run on 6.4 and earlier.

Source: IBM: user-defined types (TYPEDEF and TYPE)

Tom Taulli’s Modern Mainframe Development (O’Reilly, 2022) is a useful orientation to the mainframe, and this page used it only as a consulted overview of which tools people use. Several statements about compilers have since been overtaken: Enterprise COBOL 6.3 is no longer "the latest" (6.5 has been generally available since June 2025, with PTFs through September 2026), the history it gives stops at COBOL 2002 although the standard was revised in 2014 and 2023, Micro Focus is now part of Rocket Software, and OpenCobolIDE as the PC environment is unmaintained: install GnuCOBOL 3.2 and an editor such as VS Code instead (see Modern Tooling: VS Code and Zowe). The book does not cover GnuCOBOL’s dialects or cobc at all, which is why this page takes them from the GnuCOBOL manual.