|
Cobol Developers Understanding Theory of Objects
By Fabio Alves
on August 13th, 2007
Since the Theory of Objects came up in the developers's world, I throve to
understand it estabilishing relationships between that Theory's fundaments to what I
had learned as Cobol Developer.
If you aren't a Cobol developer and you intend to read
this text to the end, you will see I am talking about obvious things. But they are
not obvious for most Cobol developers.
It is very difficult to establish a match because the Theory of Objects works with
of the concept of dynamic memory allocation (DMA), an explicit process
often implemented in languages like Pascal, C++, C#, Java, etc. DMA is virtual for the Cobol developer.
When graduating at University, I went for classes and did assignments using Pascal
language. I had a glimpse of DMA. I remember to have been cautious about writing
code getting memory from Operational System's list of available spaces
and returnning it back to avoid memory leeks.
Cobol language doesn't implement the concept of DMA. It does not give to the
developer the rights
for controlling DMA. The memory's space for variables, is
virtually allocated at run time, and in the beginning of the task for most ones. Unisys (Burroughs) Cobol compilers generate object codes that initialize the variables
with binary zeros (Low-Values) if they do not have a value clause.
Cobol also lacks the concept of contextual variables
(Variables that only exist in run time linked to a specific procedure). In other words, we cannot
create a variable that exists only while a Section of Procedure Division is running.
All file description records, working-storage variables, program interfaces areas
will
be virtually allocated in the first running steps.
Something different happens when we try to use a field
of a DMSII dataset whose database is closed, and also, when using sort record's
fields out from sort's input or output procedure. In those circumstances, the program aborts causing a "invalid operator" or "segment array error". It happens because the memory
for the buffers is not allocated yet.
It took me lots of time to understand the difference between an empty string
and a null string. The difference resides in DMA's concept. A null string does not
have space allocated or even a pointer to reference it in memory. C, empty string has
a pointer to its memory's address and its length is zero.
Related fact happens when we insert a new column
in a SQL Database Table that already has some rows in it. The table is not imediately
scanned to have all of new column's values initialized. The column value will
imediately
show null in the execution of select statements.
So, I am coming up with examples showing how the Cobol language would work if it had
DMA in it. I hope it helps Cobol developers to build the bridge and see the
equivalences. They do not cover all concepts, but they may help the
object's conceptual understanding by the time the Cobol developer writes some code
in C# or other object oriented language.
Let's suppose we have a Cobol program with the following working-storage bellow.
.....
WORKING-STORAGE SECTION.
.....
01 WS-RECORD.
03 EID PIC 9(09).
03 NAME PIC X(26).
03 BIRTH-DATE.
05 BIRTH-DATE-CC PIC 9(02).
05 BIRTH-DATE-YY PIC 9(02).
05 BIRTH-DATE-MM PIC 9(02).
05 BIRTH-DATE-DD PIC 9(02).
......
When the Cobol compiler reads the source code, it will understand the program needs to
reserve a memory area to be used while the programs runs. Virtually, the Cobol
compiler inserts
assembly instructions to the object code for allocating memory from the operational system(OS) when the program starts. Another piece of assembly code is virtually added to the program to give back the allocated
memory to OS when it will end.
To use the fields defined in working storage section, we just need to move
values from and to them. The space will be already reserved for the program.
In Cobol programs, DMA happens behind the scenes and Cobol developers don't
need to be concerned about it. The compiler helps the developers with it.
Now, let us imagine our ficticious Cobol compiler had implemented features to support the Theory
of Objects.
In the class definition section the "CS-RECORD" would be only a declaration without any memory allocated to it. Let us imagine that CS-RECORD is an object
(CLASS). In other words, CS-RECORD is only an area's format to be allocated (or
not). The memory will be allocated only if it is necessary. And more than one copy
(instances) of the class can be created along the procedure division.
The programmer will be responsible for allocating the memory to the class's
instances at run time. He/She will need addtional commands in the procedure division.
How would the code be written? For sure, there will be the need of creating the
instance.
.......
WORKING-STORAGE SECTION.
.......
CLASS-DEFINITION SECTION.
01 CS-RECORD CLASS.
03 PROPERTIES.
05 EID PIC 9(09).
05 NAME PIC X(26).
05 BIRTH-DATE.
07 BIRTH-DATE-CC PIC 9(02).
07 BIRTH-DATE-YY PIC 9(02).
07 BIRTH-DATE-MM PIC 9(02).
07 BIRTH-DATE-DD PIC 9(02).
......
PROCEDURE DIVISION.
MAIN SECTION.
ENTRANCE.
.......
CREATE INSTANCE OF CS-RECORD DEFINING "WSR1".
MOVE 881000999 TO EID OF "WSR1".
MOVE "MYNAME1" TO NAME OF "WSR1".
MOVE 20 TO BIRTH-DATE-CC OF "WSR1".
MOVE 07 TO BIRTH-DATE-YY OF "WSR1".
MOVE 08 TO BIRTH-DATE-MM OF "WSR1".
MOVE 01 TO BIRTH-DATE-DD OF "WSR1".
DISPOSE "WSR1".
.......
As you can see WSR1 only exists at run time. Any references to it before the execution
of the CREATION INSTANCE command, would cause an "Invalid operator" exception because
the class's instance was not created yet.
Let us go beyond...
Let us suppose the object has a method associated to it. How would we define
this method?
Remembering that the method code can only be used associated to the class it belongs,
it would be defined as a procedure coded in the PROCEDURE DIVISION's DECLARATIVES.
A suggested parameterization is also in the example.
Let us define a method and link it to the class.
.......
WORKING-STORAGE SECTION.
.......
CLASS-DEFINITINION SECTION.
01 CS-RECORD CLASS.
03 METHODS.
05 UPDATE-NAME TYPE IS METHOD.
RETURN TYPE IS VOID.
07 INPUT-NEW-NAME PIC X(26) BY VALUE.
03 PROPERTIES.
05 EID PIC 9(09).
05 NAME PIC X(26).
05 BIRTH-DATE.
07 BIRTH-DATE-CC PIC 9(02).
07 BIRTH-DATE-YY PIC 9(02).
07 BIRTH-DATE-MM PIC 9(02).
07 BIRTH-DATE-DD PIC 9(02).
......
PROCEDURE DIVISION.
DECLARATIVES.
UPDATE-NAME SECTION. USE AS A METHOD FOR CS-RECORD.
ENTRANCE.
MOVE INPUT-NEW-NAME TO NAME OF CS-RECORD.
END-DECLARATIVES.
MAIN SECTION.
ENTRANCE.
.......
CREATE INSTANCE OF CS-RECORD DEFINING "CS-RECORD-INSTANCE1".
MOVE 881000999 TO EID OF "CS-RECORD-INSTANCE1".
MOVE "MYNAME1" TO NAME OF "CS-RECORD-INSTANCE1".
MOVE 20 TO WS-FIELD3-CC OF "CS-RECORD-INSTANCE1".
MOVE 07 TO WS-FIELD3-YY OF "CS-RECORD-INSTANCE1".
MOVE 08 TO WS-FIELD3-MM OF "CS-RECORD-INSTANCE1".
MOVE 01 TO WS-FIELD3-DD OF "CS-RECORD-INSTANCE1".
EXECUTE METHOD UPDATE-NAME OF "CS-RECORD-INSTANCE1" USING "MYOTHERNAMEA".
MOVE NAME OF "CS-RECORD-INSTANCE1" TO REPORT-LINE-FIELD.
.......
CREATE INSTANCE OF CS-RECORD DEFINING "CS-RECORD-INSTANCE2".
MOVE 881000998 TO EID 0F "CS-RECORD-INSTANCE2".
MOVE "MYNAME1" TO NAME OF "CS-RECORD-INSTANCE2".
MOVE 20 TO WS-FIELD3-CC OF "CS-RECORD-INSTANCE2".
MOVE 07 TO WS-FIELD3-YY OF "CS-RECORD-INSTANCE2".
MOVE 09 TO WS-FIELD3-MM OF "CS-RECORD-INSTANCE2".
MOVE 01 TO WS-FIELD3-DD OF "CS-RECORD-INSTANCE2".
EXECUTE METHOD UPDATE-NAME OF "CS-RECORD-INSTANCE2" USING "MYOTHERNAMEB".
MOVE NAME OF "CS-RECORD-INSTANCE2" TO REPORT-LINE-FIELD.
........
DISPOSE "CS-RECORD-INSTANCE1".
........
DISPOSE "CS-RECORD-INSTANCE2".
........
Those examples only give a glimpse of a possible implementation.
It would be very complex to show the implementation of inheritance concepts.
By Fabio
Alves on August 13th, 2007
|
