Does Cobol Still Have Teeth?

Most people will have heard reference to Cobol at some stage. Quite often it’s spoken of in the context of being an outdated programming language that’s difficult to learn and is only used in antiquated systems. The reality is that Cobol itself is one of the most straight-forward, intuitive and easy to learn coding languages and it is still more than capable of meeting the processing demands of most modern businesses. This article isn’t attempting to teach anybody how to code in Cobol but aims to show that you could learn to code in Cobol if you wanted to. Equally importantly it aims to show non-technical managers how Cobol is still relevant within their businesses and how easy it could be to create and manage Cobol development teams both now and in the future.

The first thing to admit is that, whilst Cobol itself is quite straightforward, the mainframe environment in which it most commonly lives can often appear slightly less enticing. I first logged onto a mainframe back in 1986 and the non-mainframe devices that I used didn’t have Windows or use a mouse, with the keyboard controlling all input. It wasn’t a great transition to move from these other devices to the mainframe, as the input processes were pretty similar. Jump forward to the present day and the user interface of the average PC has progressed phenomenally, with most processes controlled by a mouse within a Windows style environment. The user interface for the mainframe, however, has been relatively unchanged over that same period. In many cases the navigation is carried out via the keyboard, either typing in commands or entering the values for menu options. For somebody familiar with the PC, the transition to a mainframe is now a much bigger step than it was all those years ago. There are new products on the market that allow mainframe source code to be accessed within a more familiar Windows based environment and these are specifically aimed at more recent Computer Science graduates. Such changes may help to chip away at some of the stigma associated with Cobol and mainframes and that should bode well for the future.

Once you get past the rather cumbersome feel of the mainframe, the next issue that people often have with Cobol is that it seems to have a rather complex and rigid structure that needs lots of different pieces of code to be in place before you even start creating functionality. There’s an element of truth in this, as there are several different Divisions and Sections that have to be created, with certain values needing to be entered in specific places. However, the reality is, in the real world at least, that you never actually code a Cobol program from scratch. In the vast majority of cases you’ll simply find an existing program and use that as the starting point for your new program, ripping out all the bits that you don’t need and then adding the logic that you do want. Some developers also create skeletons programs that that they use as the starting point for every new program, giving little thought to many of the control values that they’ve pre-populated. Depending upon the type of program that you’re creating, the chances are that you’ll make minimal changes to two of the four divisions, so the amount you have to focus on is greatly reduced right from the outset. The main point is that you quickly get to code the actual business functionality without having to spend time on lots of technical specifications. 

In addition to actually writing the code itself we’ll also have to define the variables that we need to use. If you’re not familiar with coding, then these variables are simply places where we can store the values that the programs need to use. These variables, known as Working Storage, are used in a variety of ways including storing the results of a calculation, a text value such as a name or a count of processes applied. There’s a specific area in the program, prior to the actual functionality, that these variable are defined in and developers simply add new values in there as they find a need for them when coding. As well as giving a variable a unique name you also say what type of information it should store, such as alphanumeric or numeric, and the size that you want it to be, such as five characters or four digits. It’s useful to start out by considering data, as Cobol is extremely good at processing all forms of business data, particularly in large volumes. What it’s not so good at doing is creating pretty screens, but the functionality of Cobol can be readily coupled with technologies that are much more focused on the user interface. This can be an effective combination, as innovation is continually driving the evolution of the user interface and the means by which it is delivered, which puts continuing pressure on the technologies which manage that interaction. Stabilising the underlying, and relatively static, business requirements in a commercially oriented language such as Cobol gives an element of continuity in an otherwise fluid environment.

We can look at the way that these data elements are used by considering a very simple business scenario. In this case invoices are being processed and each contains a value that indicates the type of payment associated with the invoice. All we want to do is look at the payment type and use it to count the total number of invoices that were for cash. The following is a very simple way in which we may accommodate this.

01 WORKING-STORAGE-WS.

   05 PAYMENT-TYPE-WS            PIC X.

   05 CASH-COUNT-WS              PIC 9.

We don’t need to worry at this stage about the layout and format of these definitions, as this is just an illustration. All we need to know is that we’ve defined a variable called PAYMENT-TYPE-WS and this can store a single alphanumeric value. The term PIC is short for PICTURE and simply means that we’re defining the format of the variable. A PIC of ‘X’ means alphanumeric and a PIC of ‘9’ means numeric.   This means that the variable CASH-COUNT-WS can store a single numeric integer, i.e. 0 through 9. What we now need to do, in a separate division of our program is create some logic to process our new variables. When the new variables were first defined there were no values assigned to them and we start by assigning values using the MOVE statement that we can see below.

   MOVE 0                       TO CASH-COUNT-WS.

   MOVE ‘C’                     TO PAYMENT-TYPE-WS.

   IF PAYMENT-TYPE-WS = ‘C’

       ADD 1                    TO CASH-COUNT-WS.

The MOVE statement, like much of Cobol, is fairly logical to follow. You simply state which value you want to move to which variable. After this we now introduce a condition in the form of the IF statement. Again, this is quite logical and allows us to compare two values, in this case a variable with a literal. We can actually refine this slightly by using more options within variable definition. A logical operand can be added to a variable that will be considered true when the variable contains the stated value. In this case, the statement PAYMENT-IS-CASH will be true when the variable PAYMENT-IS-CASH contains the value ‘C’, as shown in the modified definition below.

01 WORKING-STORAGE-WS.

   05 PAYMENT-TYPE-WS            PIC X.

       88 PAYMENT-IS-CASH            VALUE ‘C’.

   05 CASH-COUNT-WS              PIC 9.

   MOVE 0                       TO CASH-COUNT-WS.

   MOVE ‘C’                     TO PAYMENT-TYPE-WS.

   IF PAYMENT-TYPE-WS = ‘C’

   IF PAYMENT-IS-CASH

       ADD 1                    TO CASH-COUNT-WS.

As stated at the outset, this isn’t intended to be a full Cobol tutorial, but the example of this logical operand was included to highlight some of the features that can be used to make Cobol code easily readable, even to the less experienced eye. We’ve used the intelligent naming of our variables to create readily understandable statements that read like plain English.

The example above is relatively pointless, as it always has a constant value. What is more likely is that multiple values will be processed sequentially from an external source, such as a file or a database. At this stage we don’t need to worry exactly how we get data from an external source, but we can put a placeholder in the code to highlight where this would take place and we’ll signify this using lower case descriptions.   The following code shows a basic scenario in which we read every record on some form of input file and count the number of cash records, the result of which is displayed when we finish. The fields on the input file, regardless of its format, will also be defined as variables and this is where FILE-INPUT-TYPE is specified, so FILE-INPUT-TYPE will be refreshed every time that a new record is read from the file.

   MOVE 0                       TO CASH-COUNT-WS.

A100-READ-PAYMENT-FILE.

   Read input file

        at end GO TO A200-END-OF-PAYMENT-FILE.

   MOVE FILE-INPUT-TYPE         TO PAYMENT-TYPE-WS.

   IF PAYMENT-IS-CASH

       ADD 1                    TO CASH-COUNT-WS.

   GO TO A100-READ-PAYMENT-FILE.

A200-END-OF-PAYMENT-FILE.

   DISPLAY ‘TOTAL NUMBER OF CASH PAYMENTS : ‘ CASH-COUNT-WS.   

There are many different ways in which a very simple piece of logic such as this can be implemented in Cobol and the preferred option will be driven by site standards and the discretion of the developer (many developers will bemoan the use the GO TO command but that would miss the point of this exercise). In this example we’ve introduced labels that are used to branch the code, either conditionally or automatically. These labels, which can have different formats and meanings, are key to program navigation. Meaningful label names further add to the readability of code. What’s increasingly important is that the code is not only appropriate for the defined requirement but is also easy to read, which, by implication, should also make it easy to maintain. 

What any developer should immediately say about this code is that as soon as we get more than 9 cash payments our logic is useless, as we can only count up to 9. What we can do here is simply allow the field to store a larger number and the updated version below now allows our counter to store a four digit numeric value, i.e. up to 9,999. To be extra careful we might also add a simple statement that checks if the counter reaches 9,999 and, if so, generate an error message saying that we’ve exceeded the maximum.

   05 CASH-COUNT-WS              PIC 9(04).

The important point to recognise at this stage is that the input file could actually contain large numbers of records, millions if needed, and the code would happily continue on until all were processed. Additionally, there could be far more data in each record and we could carry out a range of calculations. The records could, for example, contain a currency code and a monetary value along with a payment status, a payment due date and tax code. From this, using logic only a little more complicated than we see in our example, we could create a set of total values in each currency, create debtors lists for overdue payments, tax payment schedules and a consolidated set of totals in a single base currency. To achieve this we’d create new variables to store the additional values, most likely using arrays, which allow variables to store multiple indexed values, along the lines of entries in a spreadsheet. By using intelligent variable names and carefully structuring the code, the end result would still be simple and straightforward to read, and easy to maintain.

 A useful point to raise at this stage is that Cobol programs can be Batch, On-Line or Batch/On-Line subroutines. Batch refers to programs that are intended to run automatically without any manual user input. Often these are automatically run at a scheduled time during the day but can also be triggered by some other event taking place, such as a user entering certain input data. This is where Cobol really comes into its own, running large volumes of transactions in a relatively short period of time. A key selling point of mainframe systems is their reliability, with systems rarely having unscheduled downtimes. This reliability has made the mainframe an ideal choice for organisations that rely upon the processing of high volumes of business critical transactions every day. On-Line programs are those that involve interaction with a user through some form of interface in order for functionality to be applied. The final type of program is the batch/on-line subroutine, with subroutines simply being programs that are designed to be called by other programs, rather than controlling a transaction themselves. All business functionality should ideally be placed in these subroutines as it means that the same logic is readily available if it is called by a user through a screen or applied a thousand times during an overnight batch run. 

As has already been mentioned, the ability to process mass volumes of data is a key feature of Cobol programs and there are a variety of ways in which external data can be accessed through the code. An important part of many applications is the use of a database, which is a specialised way of storing and accessing large volumes of data. The database will use allocated data storage areas to define and store the records that the system needs and then instructions are used to access the data. On IBM mainframes Db2 is the most common database and it uses its own language, known as SQL or Structured Query Language. There are various ways in which both technical and business users can issue SQL commands directly, without even needing a Cobol program, but these SQL statements are most commonly embedded within a Cobol program to access, insert and modify the stored data as needed.  At the simplest level SQL is also very straightforward and you can SELECT any of a number of stored fields by telling the database how to find the information that you need. Most records will have a key value that uniquely identifies them, such as a client number or a product code, and this can be entered to instantaneously retrieve all information associated with that key.

One of the advantages of Cobol’s structure is that it can help a developer think in terms of the business process as the code can potentially read along the lines of how a business process may actually be described. By comparison with some other programming languages this can seem a little verbose, but it can actually help the mindset of the developer. It’s also important to remember at this stage that Cobol is a compiled language, which means that once you’ve completed a program the system then converts it to a format that it understands, which means that the size of field names and labels are irrelevant due to the system converting them to something that it finds more efficient to process. With all programming languages, learning the syntax of the language is only the starting point and being able to use that syntax to deliver the solution to a business requirement is the end goal. The closer the coding language is to the actual business language then, for many developers, the easier it is to bridge the gap between the two.

Ultimately, Cobol is a logical, readable programming language that can be well structured and readily mapped to a wide range of modern business transactions. Although it is most commonly associated with mainframe environments it can actually be deployed across a variety of technical platforms and utilise the powerful features of a number of modern databases.  Whilst it’s not capable of creating impressive modern presentation layers that’s primarily because it simply isn’t trying to do so. There are a variety of channels through which modern business transactions are conducted, and potentially more still to come, and there are a variety of languages that are well suited to each of these and all are capable of communicating to the core business functionality contained within a Cobol program. As long as there are clear business requirements there’ll be a distinct benefit in developing and maintaining Cobol code.