| 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 doesn’t 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.
Happy Coding! |
