There are many specifications for COBOL due to its long history. If one wanted to write software that would be acceptable for use in about 75% or more of existing COBOL projects on mainframes or minicomputers, what specification should one follow? An important point is (I imagine) that many of these software projects may be written in an older style, but perhaps use newer compilers that support features not in the existing specification. Or perhaps object code can be shipped in a way that somewhat ameliorates differences between library code specification version and application code specification version.

I realize this may be a moving target, so perhaps in 5 years, a new answer may be warranted. I also realize this is probably hard to gauge (particularly for me, an outsider in the world of COBOL and mainframes).

  • 13
    What exactly are you trying to do? I've worked on several mainframe COBOL software projects over the years (mainly automotive and public sector), and none of them has used pure COBOL. Practically everyone used platform-, vendor- and/or client-specific frameworks, pre-processors, or extension libraries. Commented Dec 25, 2021 at 19:29
  • 2
    @MichaelGraf is correct. Most implementations have extensions. IBM documents theirs pretty well. As a rule of thumb, pick a COBOL version and be aware to not use vendor extensions.
    – Hogstrom
    Commented Dec 25, 2021 at 19:33
  • 4
    It's not only a moving target, but also seems to be a question about today's use of COBOL in today's projects . So not fit for RC.SE. Not to mention that whatever version to be used in a project is predefined by your customers existing environment, soft- and hardware wise. Like with any other customer base, some are cutting edge, while others prefer not to change anything. [And as an experience from many years of mainframe (and smaller) development: the language doesn't really matter. Learning it is neglectable to learning the environment]
    – Raffzahn
    Commented Dec 25, 2021 at 19:34
  • 2
    @Raffzahn true, I thought about that, though a similar question was not well received on Software Engineering ... the question seems too vague for Stack Overflow, so I'm not really sure where would be a good fit, other than here (mainly due to the experience of the readers) - and I would argue, that there are still tie-ins to retro. Ideally I'd be able to target older systems as well, as long as they aren't so old that the features I need in COBOL are unsupported. But I may need to edit the question slightly to reflect that.
    – bbarker
    Commented Dec 25, 2021 at 19:50
  • 3
    @bbarker Yeah, this is a common phenomena we experience with such questions. Mentioning a language like COBOL, FORTRAN or BASIC(or fwiw mentioning anything no longer in the glossy pages) makes most SO reader rejecting it as outdated following by a shortcut to call it to be moved to RC.SE. Not really a situation we enjoy. Then again, tweaking a questions wording, just to make it on-topic by the letters is rather worse.
    – Raffzahn
    Commented Dec 25, 2021 at 20:40

1 Answer 1


[Preface: While the basic question may seem to be off-topic, as it's about today's use of COBOL, I like to see it as asking in help to educate about COBOL. The noble effort to keep the language alive and spoken might be worth an exception]

What is a good COBOL specification to target

Quick answer: The one your customer already uses.

In software engineering it's almost never about the tools or great ideas, but to fit in. This is especially true in long running settled environments. Here the use of COBOL may be a safe indicator that it's not only a long running one, but also a huge code base one got to fit in. In fact, it's usually way less effort to learn any new language for a project than it needs to lean the environment.

Having said that, I understand the question may be about what to suggest to students, or what to use as a base for teaching.

If that's the case, then it's all about sticking to the basics. Basic language structure, concepts and data definition.

Especially as the later is quite often done in custom, project specific tools, making it even more important to understand what the language (the compiler) sees (*1). The Mainframe/COBOL world is not ruled by hello-world type command line tools, but highly integrated packages sitting on top of what might be 'the language'. Macro like copy chains and preprocessors - of such I may have seen way more for COBOL than languages are on Rosetta Code.

So if it's strictly about teaching the basics to enable people to grow into understanding and maintaining COBOL code COBOL85 (including the 1993 revision) might be the best bet. It is a modest but useful extension of COBOL74 and made to cover everything learned since then without sacrificing compatibility.

Using COBOL85 will give the best over all base to understand the language and how features originated. Also, pre COBOL85 sources are rare, even in real old applications (read financial/accounting).

Beside that, a good peek should be taken at COBOL2002, as it does standardize many things essential today, even for COBOL, like wide character sets (Unicode) or new data types, which are quite important for interfaces to non COBOL applications.

A guideline about what newer feature is worth to be included in a course might be to separate between function and paradigm:

  • New Functionality (like charsets oder datatypes) is quite welcome by maintainer of existing applications, as it simplifies their life without making them throw away 50 years of codebase. Thus it helps if a student has basic knowledge.

  • New Paradigms may not be worth the time - or worse add confusion. True, Object COBOL new ways of functions and so on have added much, but are only worth it when doing rather large restructuring work or new projects - both not as common in COBOL. Students will learn the basics about OOP anyway, so no need to add the COBOL way. That's something they can do on their own when needed later on.

Long story short: Use a solid foundation of COBOL85 (1993 revision) and useful functional parts of later standard to give your students a fine base to ask the right questions and deliver the right answers when applying for a COBOL based job.

*1 - The relation of structures in a data division (and the way PERFORM works - the stackless structure in general) may be the most important part to teach. Spend more than just an hour on that, as it's absolute alien to today's students, grown up in an ALGOL mindset.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .