Why Object Orientation for COBOL?

Rick Malek
Sep 30, 2012
50.1k
0
0
Article

Why OO?

"Why is Microsoft interested in having so many languages target the new environment? Why bother with a language as old as COBOL?" The answer lies in recognizing that most businesses do not have the luxury of rewriting their large code base every time they want to extend the use of their existing applications.

By supporting the new Microsoft .NET Framework, Fujitsu Software is endorsing Microsoft's philosophy that programmers want and need to be able to use the programming language best suited to their application. With an estimated 70 percent of production business applications written in COBOL, the answer to enhancing those applications lies not in throwing out the COBOL, but in finding better ways to make it do new things.

With that support, Fujitsu Software enhances the productivity of organizations that use COBOL. Not only will COBOL programmers have access to a wide variety of new technologies, including .NET class libraries and ASP.NET, they will be able to work seamlessly with developers of code in other languages, such as C++ and Visual Basic. Instead of having a development organization with a schism between COBOL programmers and other programmers, the new environment allows programmers to bridge the barriers using common interfaces and programming tools. The transition to OO COBOL opens up the world for COBOL to be accessed by many other languages and to open itself up as well. Within .NET an OOCOBOL program can inherit from any other language or be inherited. Business logic will no longer "have to be rewritten because it's in COBOL", but merely recompiled and made accessible.

This article reviews the processes necessary to migrate from a procedural oriented paradigm to an object-oriented one. Presented are the minimal steps necessary to convert to the object-oriented environment. We will limit the discussion to the steps necessary to convert a procedural program to an object oriented class. Let's begin...

The Beginning

The evolution of objected orientation has been occurring in all development arenas, COBOL included. Object Orientation, more commonly referred to as OO, is an evolutionary development of the paradigm of coding technology. Object orientation enables the software developer to more accurately describe the application they are working on in real-world terms, rather than in abstract terms more suited to a computer.

Our example will utilize a procedural based program to access an ISAM file and return a record. We will first convert the procedural program to an object-oriented program. This program can then be registered as a COM server and called by client programs written in COBOL or other languages, including ASP.NET or VB.NET or C#.

Procedural Code Updates

The original source code is presented in the attached Zip file and is named PROCED.COB. Please refer to it.

The program opens a data file, prompts for input from the screen, searches the data file and then displays an error message or the data returned from the file.

There are several changes that must be made to the source code to transform it into an OO COBOL module. Several new identifiers will be added to the source module, while a few will be changed to reflect a new name. In a simplified method of converting procedural source code to object-oriented source code, there are generally ten (10) items that require updating.

Class-ID. The original identifier was PROGRAM-ID. The line should be updated to read: CLASS-ID. {name} AS "{project.source}". Where {name} is the name of the COBOL program. For our example we will name our Class AREACODE, and where {project.source} are the names of our project file, which is Dotnet and the physical name of our source code file, which is areacode.
A REPOSITORY statement has been added to the CONFIGURATION SECTION. A Repository is used to list any outside classes this class may refer to.
A reference has been added to the Repository to enable us to notify the system when an exception has occurred in processing. The .NET environment has over 5,000 namespaces each dealing with a specific area within the environment. By utilizing these areas a programmer can save a great deal of time in the designing and coding of common tasks. This module will provide the interface to the exception handling built into .NET so we can easily notify the client when an exception has occurred.

The class we have added is the "System.ArguementException" class to be used to raise the exception, or error..
An Object statement has been added after the Repository section.

This defines the start of the actual object or program that will be instantiated when the NEW method is invoked.
A PROCEDURE DIVISION for the Object must be added.

We also need to insert a Method-ID statement and name the new method. We will use the name GETSTATECODE. Every class must have at least one method. You can think of a method as being similar to an Entry Point. A Class can have multiple methods and each must have a unique name.

+Tip
When naming Methods, try to use a naming convention. It doesnt matter what format you use as long as you are consistent.
An ENVIRONMENT DIVISION has been added for the Object.
Next we move to the Data Division. There are several changes that must be made to the DATA DIVISION due the change in definition of this module to a called module. The first change will be to update the WORKING-STORAGE SECTION. We will add object references and error handling variables for the module. Our new WORKING-STORAGE SECTION will now appear as thus:
The next step is to add a LINKAGE SECTION.

The LINKAGE SECTION will be used to pass parameters to and from the DLL to the calling module. For our example we will add the following LINKAGE SECTION
We need to update the original Procedure Division statement to accept the entered area code and return the State code. We also need to be able to notify the client that an error has occurred. To enable this functionality we need to update the Procedure Division header to the following:
Finally, we need to add three lines to the end of the program to end the Method, Object and class. These lines look like:

If your existing procedural code has been designed such that the User Interface (UI), business logic, file access and error handling routines are separate distinct modules then the above ten (10) items are generally the minimum amount of code you will add or update in a procedural source module to change it to an object-oriented module. In our example this was not the case. Our sample contained UI, error handling as well as file access routines. It was necessary therefore to perform some additional minor changes to the source module. We modified the source code to contain the following error handling routine

Next, we modified the source to not utilize any UI, but rather to utilize the above error routine. For purposes of demonstration the file access routines remained in the source module.

The updated program is present in the Zip file and is named AREACODE.COB. Please refer to the zip file.

It should also be noted that not all of your procedural code would need to be updated to an OO paradigm. Only those modules that would provide benefit to your application would require this conversion. In our example the file access routines could be removed and a new COBOL source module created. The code in the file access routine would not be required to be OO as it would be a called module and could remain in its procedural form. Prior to under taking a migration to OO-based COBOL a review of your application should be done to determine which modules should be converted to OO and what additional functionality could be obtained from the migration.

The move to OOCOBOL doesn't have to be a difficult one. Take a few minutes and review the sample in the attached zip file. Try it with one of your own programs and you'll see... it won't hurt.

Next Weeks Article

I will be on vacation next week so the next article of the COBOL Corner will be July 23. Have a good week!