1 Introduction
This document describes the syntax, semantics and use of the COBOL programming language as implemented by GnuCOBOL, formerly known as OpenCOBOL.
The original principal developers of GnuCOBOL were Keisuke Nishida and Roger While. Since then, many members of the community have been involved in its development.
This document is intended to serve as a fully functional reference and light user’s guide, suitable for both those readers learning COBOL for the first time as a light training tool, as well as those already familiar with another dialect of COBOL.
A separate manual — containing only the basic details of the GnuCOBOL implementation and designed for experienced COBOL programmers — has been taken from this guide. That document (GnuCOBOL Quick Reference) contains no training subject matter.
A new manual that is based on this manual (Programmers Guide) is the Programmers Reference. This will have any training material removed so it will be a detailed Reference only. There are a few issues to overcome in that it uses currently the same text for the Guide and this will need changing in some areas in order to remove any training materials creating new text documents used as input to build this manual.
Other documents that should be read is the gnucobol.pdf found in the doc directory of the compiler sources and the file NEWS supplied with the source code of the GnuCOBOL compiler, in the top-level directory. There you will find the latest COBOL language features that have been added, some of which may not be in this document due to time constraints. If you find any, please report it as a bug for the Programmer’s Guide so that it can be fixed.
Yet another document which delves deeper in to the compiler that is a must read, is the FAQ available via the GnuCOBOL Manuals and Guides, although it could do with a wee clean up to ease reading and finding required information.
1.1 Additional Reference Sources
For those wishing to learn COBOL for the first time, Gary can strongly recommend the following resources.
If you like to hold a book in your hands, I strongly recommend Murach’s Structured COBOL, by Mike Murach, Anne Prince and Raul Menendez (2000) - ISBN 9781890774059. Mike Murach and his various writing partners have been writing outstanding COBOL textbooks for decades. It’s an excellent book for those familiar with the concepts of programming in other languages, but unfamiliar with COBOL.
Another to consider is COBOL Unleashed by Jon Wessler, et al (with many other contributors) dated 1998 - ISBN 9780672312540 - 1,000 pages, which is perhaps more geared to the mainframe but with much related to other platform including for GnuCOBOL which Vincent finds very useful at times.
One more is Beginning COBOL for Programmers Paperback – 20 Mar. 2014 by Michael Coughlan - ISBN 978-1430262534 which may well be worth a read. There are many others.
Would you prefer a web-based tutorial? Try the University of Limerick (Ireland) - COBOL web site.
In addition there is the GnuCOBOL FAQ — which has now exceeded 1,400 pages — available as HTML or a downloadable .pdf file.
Along with every release of the compiler sources is the file NEWS. It contains up to the minute updates regarding the compiler and additional COBOL language elements which may well not be yet included in this manual.
1.2 Introducing COBOL
If you already know a programming language other than COBOL, chances are that language is Java, C or C++. You will find COBOL much different from those; sometimes the differences are a good thing and sometimes they aren’t. The thing to remember about COBOL is this: it was designed to solve business problems.
COBOL, first introduced to the programming public in 1959, was the very first programming language to become standardized (in 1960). This meant that a standard-compliant COBOL program written on computer “A” made by company “B” would be able to be compiled and executed on computer “X” made by company “Y” with very few, if any, changes. This may not seem like such a big deal today, but it was a radical departure from all programming languages that came before it and even many that came after it.
The name COBOL actually says it all — COBOL is an acronym that stands for “(CO)mmon (B)usiness (O)riented (L)anguage”. Note the fact that the word “common” comes before all others. The word “business” is a close second. Therein lies the key to COBOL’s success.
1.2.1 Why YOU Should Learn COBOL
Despite statements from industry “insiders”, the COBOL programming language is not dead, even though newer and so-called “modern” languages like Java, C#, .NET, Ruby on Rails and so on appear to have become the languages of choice in the Information Technology world. These languages have become popular because they address the following desired requirements for “modern” programming:
They conform to the principles of Object-Oriented Programming (OOP). This is desired for one major reason — it facilitates “code re-usability”, thus improving the productivity of programmers by allowing them to re-use previously written (and debugged) code in new applications. For one reason or another, COBOL is perceived as being weak in this regard. It isn’t (especially today), as we’ll see in the next section, but perception is important.
Those languages aren’t limited to mainframe computers, as COBOL is perceived to be. Some, like .NET and Ruby, aren’t even available on mainframes. The “modern” programming languages were designed and intended for use on the full variety of computer platforms, from shirt-pocket computers (i.e. smart phones) up to the most massive of supercomputers.
There are several excellent commercially available COBOL implementations available for non-mainframe systems (Micro Focus Visual COBOL, AccuCOBOL, NetCOBOL and Elastic COBOL, just to name a few), including Windows and UNIX/Linux systems. These aren’t cheap, however.
Universities love the “Modern” languages. In the U.S., 73% of colleges lack even one COBOL course on their curricula. COBOL, it appears, is no longer “cool” enough for students to fill a classroom.
Just because COBOL doesn’t traditionally support objects, classes, and the like doesn’t mean that its “procedural” approach to computing isn’t valuable — after all, it runs 70% of the worlds business transactions, and does so utilising over 200 billion lines of code (according to research):
Using programs that, for the most part, are much more self-documenting than would be the case with any other programming language.
Effortlessly providing arithmetic accuracy to 31 digits, with performance approaching that of well-written assembly-language programs. Don’t think this isn’t critically important to banks, investment houses and any business interested in tracking revenues, expenses and profits (duh - like ALL of them).
Integrating well with non-COBOL infrastructures such as XML, SOA, MQ, almost any DBMS, Transaction Processing platforms, Queue-Management facilities and other programming languages.
By running on almost as many different computing platforms as Java can. You can’t run COBOL programs in your smart phone, but desktops, workstations, midframes/servers, mainframes and supercomputers are all fair game.
Businesses are addressing the COBOL challenge in different ways:
By undertaking so-called “modernization projects”, where existing applications are either rewritten in “modern” languages or replaced outright with purchased packages. Most of these businesses are using such activities as an excuse to abandon “expensive” mainframes in favour of (presumably) less-expensive “open systems” (mid frame/server) solutions.
Many times these businesses are finding the cost of the system/networking engineering, operational management and monitoring and risk management (i.e. disaster recovery) infrastructures necessary to support truly mission-critical applications to be so high that the “less-expensive” solution really isn’t; in these cases the mainframe may remain the best option, thus leaving COBOL in play and businesses seeking another solution for at least part of their application base.
Training their own COBOL programmers. Since colleges, universities and technical schools have lost interest in doing so, many businesses have undertaken the task of “growing their own” new crop of COBOL programmers. Fear of being pigeon-holed into a niche technology is a factor inhibiting many of today’s programmers from willingly volunteering for such training.
By moving the user-interface onto the desktop; such efforts involve running modern-language front-end clients on user desktops (or laptops or smart phones, etc.) with COBOL programs providing server functionality on mainframe or midframe platforms, providing all the database and file “heavy lifting” on the back-end. Solutions like this provide users with the user-interfaces they want/need while still leveraging COBOL’s strengths on (possibly) downsized legacy mainframe or midframe systems.
It’s probably a true that an IT professional can no longer afford to allow COBOL to be the only wrench in their toolbox, but with a massive code base still in production now and for the foreseeable future, adding COBOL to a multi-lingual curriculum vitae (CV) and/or resume (yes — they ARE different) is not a bad thing at all. Knowing COBOL as well as the language du-jour will make you the smartest person in the room when the discussion of migrating the current “legacy” environment to a “modern” implementation comes around.
You’ll find COBOL an easy language to learn and a FAR EASIER language to master than many of the “modern” languages.
The whole reason you’re reading this is that you’ve discovered GnuCOBOL — another implementation of COBOL in addition to those mentioned earlier. The distinguishing characteristic of GnuCOBOL versus those others is that GnuCOBOL is FREE open-source and therefore FREE to obtain and use. It is community-enhanced and community-supported. Later in this document ( 1.3 So What is GnuCOBOL?), you’ll begin to learn more about this COBOL implementation’s capabilities.
1.2.2 Programmer Productivity
Throughout the history of computer programming, the search for new ways to improve of the productivity of programmers has been a major consideration. Other than hobbyists, programming is an activity performed for money, and businesses abhor spending anything more than is absolutely necessary; even government agencies try to spend as little money on projects as is absolutely necessary.
The amount of programming necessary to accomplish a given task — including rework needed by any errors found during testing (testing is sometimes jokingly defined as: that time during which an application is actually in production, allowing users to discover the problems) is the measure of programmer productivity. Anything that reduces that effort will therefore reduce the time spent in such activities therefore reducing the expense of same. When the expense of programming is reduced, programmer productivity is increased.
Sometimes the quest for improved programmer productivity (and therefore reduced programming expense) has taken the form of introducing new features in programming languages, or even new languages altogether. Sometimes it has resulted in new ways of using the existing languages.
While many technological and procedural developments have made evolutionary improvements to programmer productivity, each of the following three events has been responsible for revolutionary improvements:
The development of so-called “higher-level” programming languages that enable a programmer to specify in a single statement of the language an action that would have required many more separate statements in a prior programming language. The standardization of such languages, making them usable on a wide variety of computers and operating systems, was a key aspect of this development. COBOL was a pioneering development in this area, being a direct descendant of the very first higher-level language (FLOW-MATIC, developed by US Naval Lieutenant Grace Hopper) and the first to become standardized.
The establishment of programming techniques that make programs easier to read and therefore easier to understand. Not only do such techniques reduce the amount of rework necessary simply to make a program work as designed, but they also reduce the amount of time a programmer needs to study an existing program in order how to best adapt it to changing business requirements. The foremost development in this area was structured programming. Introduced in the late 1970’s, this approach to programming spawned new programming languages (PASCAL, ALGOL, PL/1 and so forth) designed around it. With the ANSI 85 standard, COBOL embraced the principles espoused by structured programming mavens as well as any of the languages designed strictly around it.
The establishment of programming techniques AND the introduction of programming language capabilities to facilitate the re-usability of program code. Anything that supports code re-usability can have a profound impact to the amount of time it takes to develop new applications or to make significant changes to existing ones. In recent years, object-oriented programming (OOP) has been the industry “poster child” for code re-usability. By enabling program logic and the data structures that logic manipulates to be encapsulated into easily stored and retrieved (and therefore “reusable”) modules called classes, the object-oriented languages such as Java, C++ and C# have become the favourites of academia. Since students are being trained in these languages and only these, by and large, it’s no surprise that — today — object-oriented programming languages are the darlings of the industry.
The reality is, however, that good programmers have been practising code re-usability for more than a half-century. Up until recently, COBOL programmers have had some of the best code re-usability tools available — they’ve been doing it with copybooks and subprograms rather than classes, methods and attributes but the net results have been similar. With the COBOL2002 and the COBOL 2014 standards, the COBOL programming language has become just as “object-oriented” as the “modern” languages, while preserving the ability to support, modify, compile and execute “legacy” COBOL programs as well.
1.3 So What is GnuCOBOL?
GnuCOBOL is a free and open sourced COBOL compiler and runtime environment, written using the C programming language which itself is free to use and can be used in all forms including for commercial purposes - there is no restrictions. GnuCOBOL is typically distributed in source-code form, and must then be built for your computer’s operating system using the system’s C compiler and loader. While originally developed for the UNIX and Linux operating systems, GnuCOBOL has also been successfully built for computers running OSX (a OpenBSD implementation) and Windows utilizing the UNIX-emulation features of such tools as Cygwin and MinGW. Also see the GNU website for more information. Pre built Implemeations for Windows can also be found at https://www.arnoldtrembley.com/GnuCOBOL.htm.
The MinGW approach is a personal favourite with the author of this manual because it creates a GnuCOBOL compiler and runtime library that require only a single MinGW DLL to be available for the GnuCOBOL compiler, runtime library and user programs. That DLL is freely distributable under the terms of the GNU General Public License. A MinGW build of GnuCOBOL fits easily on and runs from a 128MB flash drive with no need to install any software onto the Windows computer that will be using it. Some functionality of the language, dealing with the sharing of files between concurrently executing GnuCOBOL programs and record locking on certain types of files, is sacrificed however as the underlying operating system routines needed to implement them aren’t available to Windows and aren’t provided by MinGW. The current version for MinGW is available at the download link along with various other platforms at the GnuCOBOL https://sourceforge.net/projects/gnucobol/files/gnu-cobol, download website.
GnuCOBOL has also been built as a truly native Windows application utilizing Microsoft’s freely-downloadable Visual Studio Community package to provide the C compiler and linker/loader. This approach does not lend itself well to a “portable” distribution.
The GnuCOBOL compiler generates C code from your COBOL source programs; that C code is then automatically compiled and linked using your system’s C compiler (typically, but not limited to, gcc).
GnuCOBOL fully supports much of the ANSI 85 standard for COBOL (the only major exclusion is the Communications Module) and also supports some of the components of the COBOL2002 and COBOL2014 standards, such as the SCREEN SECTION ( 6.7 SCREEN SECTION), table-based SORT ( 7.8.42.2 Table SORT) and user-defined functions. There are others with more being added almost weekly.