Object-Oriented COBOL - University of Wisconsin-Platteville

glintplainvilleΛογισμικό & κατασκευή λογ/κού

18 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

82 εμφανίσεις

Simpson

Page
1

CS411

Object
-
Oriented COBOL?



Trevor Simpson

Department of Computer Science

and Software Engineering

University of Wisconsin
-
Platteville

simpsont@uwplatt.edu


Abstract


Surely the title of this presentation is given in jest. We all realize that COBOL cannot
po
ssibly be considered Object
-
Oriented…or can it? Even though we all perceive COBOL as
a language written in ancient times by ancient programmers this perception is flawed. The
latest ANSI COBOL Standard


COBOL 2002 provides elements which allow COBOL to
be
fully Object
-
Oriented and also handle Unicode, XML parsing and generation, calls to and
from non
-
COBOL languages and even the ability to run COBOL in the .Net environment.
Obviously COBOL continues to grow and support for it is necessary. I plan to pr
ovide you
with a small background of COBOL, inform you how COBOL functions as an Object
-
Oriented language and what we can expect in the future.

Simpson

Page
2

CS411

Intentions


Let’s look at the topic of this paper


“Object
-
Oriented COBOL?”


Why is there a question
mark at
the end?

Unless you are a well informed reader you have probably never considered
the possibility that the COBOL language could be considered object
-
oriented, well I am here
to tell you that it can. Now on top of this you are probably also thinking, “but

isn’t COBOL
a dead language.” Well again you are a bit misinformed. Current estimates place the number
of lines of COBOL code in use as high as 200
billion!

[6]
Obviously this indicates that
COBOL is far from dead, so let’s move forward with an explanat
ion of object
-
oriented
COBOL.



Background


COBOL is a language that was created in 1959 by a joint taskfor
ce referred to as the “Short
Range Committee”, whose goal was to create a common business language. This taskforce
was composed of
members represent
ing six computer manufacturers and three government
agencies. In particular, the six computer manufacturers were Burroughs Corporation, IBM,
Minneapolis
-
Honeywell (Honeywell Labs), RCA, Sperry Rand, and Sylvania Electric
Products. The three government agen
cies were the US Air Force, the David Taylor Model
Basin, and the National Bureau of Standards (Now NIST).

Six members of this committee
formed a sub
-
committee and it was this sub
-
committee who created the standards for
COBOL.

The full short range commit
tee

approved the standards created by the sub
-
committee on January 3, 1960. These standards were then sent by the government for
printing and became known as COBOL 60
[5]
. Since this time the ANSI(American National
Standards Institute) has produced four m
ajor revisions of COBOL.



COBOL 68



COBOL 74



COBOL 85



COBOL 2002

We are interested in the latest of these revisions as it adds keywords and capabilities
necessary for object
-
oriented programming.



COBOL Purpose


The purpose of the COBOL programming language

is a common business language that can
be used across many platforms. Its roots lie in business computing and the file handling and
transaction capabilities required in the business world. This led the language to be verbose
by current standards but the

inherent wordiness of COBOL does have an advantage, correctly
structured and
well written COBOL code is self
-
documenting. It requires little to no
commenting for its intent to be evident even
to

the most novice COBOL programmer.

COBOL standards create a

language that is tightly structured, strongly typed, highly secure,
extremely stable, and designed for batch processing.

Simpson

Page
3

CS411

COBOL structure is inherent in the language itself. Keywords for Divisions and record
descriptions are required to begin in column
eight. Columns one
through

six are reserved for
sequence numbers and column seven is reserved for special characters such as “*” to indicate
a comment line and “
-
“ the line continuation character. Also anything past the 72
nd

character
is ignored by most
COBOL compilers as this area is also reserved.


COBOL owes its strong typing to the lack of casting. This practice is common in most 4
th

Generation Languages and can often lead to incomprehensible code and unforeseen
nearly

impossible to debug runtime e
rrors due to the way the casting is handled. Compiled COBOL
code is nearly un
-
hackable and given that the language was designed with business
transactions in mind it is extremely stable. Finally COBOL was originally designed as a
procedural language, but

the latest standard adds object
-
oriented elements. What are the
differences?



Procedural vs. Object
-
Oriented


A procedural language is a programming language whose instructions are ordered in nature.
A good example of the procedural paradigm is a recip
e. A recipe has steps which are to be
completed in a specific order to produce the end result. Procedural languages are much the
same. Instructions are executed in a specific order to reach the end of the program. Purely
procedural languages have funct
ions, a set of instructions grouped together to perform a
specific task, often one that is to be repeated. Then there are modules, a set of functions
grouped together to perform a specific process. These modules are “called” from larger main
driver progr
ams. Finally data in procedural languages
is

referred to as variables.


An object
-
oriented language is a programming language whose instructions are a series of
communications between objects and the interactions between these objects. An object is a
spe
cific collection of data pertaining to a certain item or task and any methods dealing with
the object. Methods are object
-
oriented programming’s way of handling the messages from
other objects or performing the necessary operations to create its own messa
ges and handle
changes to its data. Data in object
-
oriented languages is referred to as members.



The Object
-
Oriented Paradigm


To help us better understand how the COBOL 2002 standard supports the object
-
oriented
paradigm let’s go through a brief descri
ption of the four main tenets

of the object
-
oriented
paradigm
.



Inheritance


Inheritance is the ability of an object to assume the methods and data of another object. This
relationship is referred to as the parent


child relationship. A child object in
herits from the
parent object. Normally inheritance is used to create more specific objects type from general
Simpson

Page
4

CS411

types. The idea of inheritance is expressed through the “is a” statement. For instance
“House
IS A

Building” this would indicate that object “H
ouse” inherits from object
“Building”. The House object has all of the properties and methods of the Building object,
general items like “roof”, “walls”,
and “
rooms” and also
its own special items like
“bedroom”, “kitchen”, and “furniture”. Note that the

members of an object can be objects
themselves.



Abstraction


Abstraction refers to hiding the actual implementation of an object

s method from the users
of that object. For instance
,

it is of no consequence to the user of an object how the method
perfo
rms its necessary instructions, nor

should we provide this information to users as it
would most likely confuse them. The cornerstone of abstraction is the ability of an object to
have data that is private to itself
,

data that only the object itself can m
odify or even knows
that it exists.



Polymorphism


Polymorphism is a concept related to inheritance. Polymorphism literally translated means
“many faces.” This concept
is exemplified by the parent


child relationship property “a
child can be used whe
re a parent is expected.” What this means is that if we have objects of
different types such as dog and cat
child
object
s

and a parent object animal all

with methods
for speak and we place these objects in a list and at some point call the speak method we

do
not have to explicitly indicate

which
object

we are dealing with
. The compiler will
determine at run
-
time whether the object is of type dog
,
cat
or animal
and call the correct
speak method.

This is a particularly useful concept that is used in many p
laces within object
-
oriented programs. For instance the “+” operator can indicate two very different instructions
based upon the operands. If the operands are numeric then it indicates mathematical
additions, but in many languages if the operands are str
ings or literals it indicates
concatenation.



Encapsulation


Encapsulation is the principle of placing all the necessary data for an object in the same place
as any methods used to manipulate the object. This is used to ensure that a programmer has
all
the necessary information regarding an object in the most convenient place to reduce the
number of errors and difficulty of maintaining the code once in production.



COBOL 2002 Standards


The latest revision to the ANSI COBOL standards
,

referred to as COB
OL 2002
,

provides the
necessary keywords and changes to allow programmers to create object
-
oriented COBOL
Simpson

Page
5

CS411

code. It also adds several significant improvements that help COBOL continue to be the
most used programming language on the planet. Let’s look at a

few of the updates.



Updates


Exciting updates to COBOL included in the 2002 standards allow COBOL functions to be
called recursively. This adds to
the flexibility of the language and also makes the use of
more complex and efficient algorithms possible.

Other updates include: A Boolean datatype,
i
nline comment special character “*>”, compiler directive for free format, common exception
handling, file sharing and record locking, support for XML parsing and generation, and of
course keywords and mechanism
s

necessary for object orientation
[6]
.



Specific Object
-
Oriented Elements


The Factory keyword was added to the language. This keyword refers to a special portion of
an object class definition. This portion is used to create methods and data which are g
lobal to
all instances of an object. For instance, if you wish to maintain a counter of the number of
instances of objects which have been created you would define the name for this variable in
the Factory section of the class definition. To increment th
is counter you would define in the
Factory section a portion of code referred to as a constructor in the object
-
oriented world.


This code

s purpose is to initialize the values of members of a class and perform any
necessary methods to prepare an object
for usage when it is first created. The constructor for
an object is the first method that is called when a new instance of an object is created. You
would also define the destructor for a class in the Factory section. An object

s destructor is
the last

method that is called before an instance of an object is deleted. Often you perform
instructions like decrementing counters and garbage collection in destructors.


Obviously keywords Object and Class have been added to the language definition. Other
key
words that implement the object
-
oriented principle of inheritance are Inherits and
Interfaces. Also added was support for Parameterized classes, a special class similar to the
Java Interface class that is used as a skeleton class as the basis of an inheri
tance chain. The
most common usage of this is for Collection classes, classes that are used to hold collections
of other objects and keep them in some type of order either on the basis of a key or some
sorting algorithm. The Interface keyword is used to
implement the object
-
oriented principle
of abstraction. Interface is used to define the parts of an object that are accessible by users of
that object, thereby hiding the exact details of the object

s implementation.


Perhaps one of the most intriguing ne
w elements of COBOL 2002 is the “Usage Object
Reference” clause. This clause is applied to the definition of a dataname within the program
and causes the dataname to be utilized as an object pointer. These object pointers are
referred to as “handles.” W
hen an instance of an object is created in COBOL and its name is
assigned as a handle what this does is make the handle a pointer to the object instead of the
actual object itself.

Simpson

Page
6

CS411


Most other object
-
oriented languages require you to create a special cla
ss of pointers to
achieve this functionality. The important benefit this provides is that it instantly implements
the interface of an object without the programmer having to perform any extra steps
. This
increases the abstraction of the program and prote
cts the program from unwanted user
interaction with an object. The other feature of the clause is the ability to allow a reference
to accept objects of only a specific type or be universal. This allows for polymorphism and
can help enforce correct inheri
tance. Now that we know some of the changes let

s examine
some example code.



COBOL 2002 Examples


First we will look at two classes called driver and student. These are written to demonstrate
simple inheritance and object creation and definition using
the new standards. The driver
class is the main calling class, it creates an object of type student and calls students methods
CalcGPA and GiveRating. CalcGPA accepts an input parameter and calculates a simple
GPA based upon this and returns this value.

GiveRating accepts an input GPA and returns a
rating based upon the value.



IDENTIFICATION DIVISION.


PROGRAM
-
ID. DRIVER.


*>


ENVIRONMENT DIVISION.


INPUT
-
OUTPUT SECTION.


FILE
-
CONTROL.


SELECT GRADE
-
FILE



*> ASSIGN TO DISK "J:
\
CS423
\
ASSIGN4
\
HW4.DAT"


ASSIGN TO UT
-
S
-
INPUT


ORGANIZATION IS LINE SEQUENTIAL.


*>


CLASS
-
CONTROL.


STUDENT IS CLASS "STUDENT".


*>


DATA DIVISION.


Figure 1: Cla
ss Driver(Partial)


The most important thing to notice in this code piece is the Class
-
Control Section. Notice
that it creates the reference to a class student with the dataname “student.” The next code
snippet will show the usage of the Usage Object Ref
erence clause.



01 STUDENTHANDLE OBJECT REFERENCE.


Figure 2: Handle Example


Simpson

Page
7

CS411

This single statement creates a variable with the name “StudentHandle” which is an Object
Reference. Now let’s look at the code in the Procedure Di
vision used to create a Student
Object and call the methods of that object.




INVOKE STUDENT "NEW"


RETURNING STUDENTHANDLE.


Figure 3: Invoke “New” Example


The above statement creates an instance of the Student object and assigns

it to the
StudentHandle Object Reference dataname. Note the Invoke keyword, this keyword is used
to reference any methods of an Object. The “New” method is the default constructor that is
created for you.



INVOKE STUDENTHANDLE "CALCGPA"



USING WS
-
PASS
-
VARS


RETURNING WF
-
GPA


*>


INVOKE STUDENTHANDLE "GIVERATING"


USING WF
-
GPA


RETURNING WF
-
RATING


Figure 4: Invoke Method Examples


The above two Invoke statements are used to

call the CalcGPA and GiveRating methods

of
Student. You can see that their general form is the same and it is easy to note which values
are passed into the methods and which are returned. The important thing to note is the use of
the StudentHandle datan
ame in the Invoke statement. This indicates we are calling a specific
object instance and
NOT

the class itself, this is an important distinction to make! Now let’s
look at some of the code for the Student class.



IDENTIFICATION DIVISION.


C
LASS
-
ID. STUDENT


INHERITS FROM BASE.


*>


ENVIRONMENT DIVISION.


OBJECT SECTION.


CLASS
-
CONTROL.


STUDENT IS CLASS "STUDENT".


*>


OBJECT.


*>


DATA DIVISION.


*>


PROCE
DURE DIVISION.

Simpson

Page
8

CS411


*>


METHOD
-
ID. "CALCGPA".


*>


WORKING
-
STORAGE SECTION.


01 WS
-
DATA.


*>


LINKAGE SECTION.


01 LS
-
DATA.


01 LS
-
GPA PIC 9V99.


*>


PROCEDURE DI
VISION USING LS
-
DATA


RETURNING LS
-
GPA.


Figure 5: Student Class(Partial)


There are several important points to note in this code. First notice the Inherits keyword, this
class is inheriting from the base class for all Objects in

COBOL 2002 which is aptly named
Base. Next notice the Object Section clause, this tells us we are now defining the elements
of an Object
.

T
hen the Object keyword indicating we are defining a specific Object
. Notice
also that we then have a Data Division

where we can define datanames to be members of the
object. This is how we define members private to the instance of a class, giving abstraction
functionality to the object. Finally we have the Procedure Division where we provide the
method implementatio
ns. Notice another important feature within the individual methods
themselves
:

we have Working Storage sections where we can declare temporary members
that exist only while that method is executing. The Linkage Section provides the ability to
pass values

to and from the method.


These two classes provide a basic demonstration of the
improved
capabilities of the COBOL
2002 standard

with regards to object
-
oriented programming.



COBOL and .Net


Perhaps one of the most exciting recent developments brought a
bout by the COBOL 2002
standard is the introduction of COBOL.NET. MicroFocus has introduced a version of its
popular Net Express compiler called MicroFocus Net Express for .Net which effectively
integrates support for COBOL in Microsoft’s venerable .Net f
ramework. This instantly
allows the industry to leverage the power of the .Net framework and its distribution
capabilities to quickly produce COBOL code that can be easily widely distributed
. What this
also allows is for developers to more easily develop

COBOL code that will be cross
-
functional with the newer more visual based development of the 4
th

GL’s.


For instance you can use the .Net IDE(Integrated Development Environment) to create a
form project using any of the available .Net languages such as
J#, C#, Visual Basic, then
create a project using COBOL and have it do the heavy data processing and transactions that
COBOL is known for and seamlessly integrate these two seemingly dissimilar projects into
Simpson

Page
9

CS411

one solution. One of the classic complaints with

regards to COBOL has always been the lack
of a fully featured, powerful IDE. With this development that point becomes moot. The .Net
IDE is arguabl
y

the most fully featured, powerful IDE on the market. Calls to and from
COBOL code are a simple matter of

new syntax that is readily available
,

easily learned
, and

requir
es

little special consideration from the programmer.



COBOL and XML


One of the fastest growing programming environments is the internet and one of the
cornerstones of providing information
to users on the internet is the XML standard. COBOL
2002 addresses the creation and parsing of XML through the addition of several new
keywords and
context sensitive definitions. Let’s look at a simple example of the power of
COBOL and XML. First I will

show you the XML definition of a simple document used to
provide online insurance quotes given a customer

s name, age, and the value of the policy.



<?xml version="1.0" encoding="utf
-
8"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefau
lt="qualified">


<element name="customer">


<complexType>


<sequence>


<element name="cust
-
name" type="string"/>


<element name="cust
-
age" type="string"/>


<element name="cust
-
policy
-
value" type="string"/>



<element name="cust
-
policy
-
cost" type="string"/>


</sequence>


</complexType>


</element>

</schema>


Figure 6: XML Schema Definition


Here are examples of some of the specific keywords added to support XML, the first
statement show
s how to correctly refer to the above schema in the File Division and the
second set of statements illustrates assigning COBOL datanames to the elements of the XML
Schema.


select quote
-
info assign to "myfile", file status is filestat,


organization is

xml, access mode is xml,


type is external schema



"http://www.schemalocation.com/my_schema".


FD quote
-
info

01 x
-
customer identified by "customer".


02 cust
-
name pic X(30) identified by "cust
-
name".


02 cust
-
age pic 9(3) identified b
y "cust
-
age".

Simpson

Page
10

CS411


02 cust
-
policy
-
value pic 9(12)




identified by "cust
-
policy
-
value".


02 cust
-
policy
-
cost pic 9(12)




identified by "cust
-
policy
-
cost".


Figure 7: XML Examples

Lastly I will show you a snippet of code that will generate th
e XML file from information
provided interactively by the user and then use the contents of the created XML file as
parameters for a method to calculate the
quote.


format
-
request.


open output quote
-
info


open document quote
-
info


move correspond
ing customer to x
-
customer *>create XML document for Customer


write x
-
customer


close document quote
-
info


close quote
-
info.

send
-
request.


call "calc
-
quote
-
xml". *>no argument, use XML file


Figure 8: XML Generation in COBOL code



COBOL’s F
uture


As I indicated previously estimates place the number of lines of COBOL code currently
running at 200 billion. COBOL is alive and strong and with the changes implemented in the
2002 standard it continues to move forward. Beyond the 2002 standard th
e COBOL
Standards Committee is already discussing potential changes to be made in a standard set for
finalization in 2008. Some of the changes being discussed include specific support for
Collection classes, more XML support and several others. The conti
nued evolution of
COBOL and its widespread use indicate a bright future for the language. Are your
sunglasses ready?

Simpson

Page
11

CS411

References


[1]
Arranga, Edmund C. (1996).
Object
-
Oriented COBOL
. New York : SIGS Books &
Multimedia


[2] Flint, E. S. (1997). The COBOL

jigsaw puzzle: fitting object
-
oriented and legacy
applications together.
IBM Systems Journal, 36(1), pp 49
-
65.
Retrieved March 10, 2007 from
Wilson Database.


[3] Glass, Robert L. (1997).
Cobol
--
a contradiction and an enigma.
Association for
Computing Mac
hinery. Communications of the ACM

40(9) pp 11
-
14
.

Retrieved March 3,
2007 from ABI/Inform Database.


[4] Hardgrave, Bill C. (Mar/Apr 2000). Cobol in an Object
-
Oriented World: A Learning
Perspective.
IEEE Software, 17(2), pp 26.
Retrieved March 10, 2007 fro
m Academic Search
Elite Database.


[5] Sammet, Jean E. (1985).
Brief Summary of the Early History of COBOL.

Annals of the
History of Computing

7(4) pp 288.
Retrieved March 3, 2007 from ABI/Inform Database.


[6] Schriker, Don. (Mar/Apr 2000). COBOL for the
Next Millenium.
IEEE Software, 17(2).
Retrieved March 10, 2007 from Academic Search Elite Database.


[7
] Sokol, Marc. (1990).
Reader Viewpoint: Why 4GLs Cannot Kill COBOL
.

Journal of
Systems Managemen
t, 41(5) pp 35
-
37.
Retrieved March 13, 2007 from ABI/In
form
Database.


[8]

COBOL Standards
. (n.d.) Various pages from www.cobolstandards.com