Cobol - COBOL Books - DON'T bother to buy

Author

COBOL Books - DON'T bother to buy

James J. Gavan

2005-11-24, 6:55 pm

Dan and others,

As to the original thread asking for COBOL book recommendations,
typically for c.l.c., so much has got lost in the shuffle.

Specifically OO COBOL - here are three books you can save your money on
by NOT buying :-

Title : An Introduction to Object COBOL
Author : E. Reed Doke and Bill C.Hardgrave
Comment : Two academics, printed 1998. A lightweight, adds absolutely
nothing to what you can glean from Arranga/Coyle or Will Price. My major
objection - so much shown as Procedural programs invoking OO classes
rather than a total application in OO, flowing backwards and forwards
between classes. The only thing going for them, they were using a *real*
compiler - Net Express, as opposed to a 'theoretical' compiler.

Title : Standard OO COBOL
Author : Ned Chapin
Comment : Title says it - printed in 1996 and based on what COBOL was
supposed to be which didn't officially happen until 2002. Some examples,
lots of diagrams, not sure which compiler if any and some abominable
code even if used in Procedural, like (and abbreviated) :-

1. Open file
2. get a record
3. Close file

That of course is a technique that we all use !

Title : OO Development in COBOL
Author : Andrew Topper
Comment : Perhaps liked this one the least. Very short on examples, lots
of tables, graphs, generalizations. Does include a diagram of the Micro
Focus part of the Collection hierarchy.

With reference to the last two they were picking up tips on OO COBOL;
where else other than one of the members of the J4 Standards. So
somebody in J4 was on happy pills. I can't remember without going
through the texts, but references in 1996/1997 to, "We will soon have
OO COBOL Collections". The definition of 'soon' - don't ask me. Well we
have COBOL 2002 but NO Collection classes which are sat in the TR
(Technical Report) as Chuck indicated and they want to get it out now
'real soon', so perhaps 2007/2008. (Chuck is comparatively new to the J4
team - 2 or 3 years (?) - so he wasn't in on the original schmozzle).

But I tell yer - but for Bill Klein we wouldn't even have had a bloody
TR on Collections !!!

STOP HERE ........

Thinking on above, I got a bit incensed about the whole issue, and below
I started to rant and rave - it would have been a bit of an eye-opener
for Chuck. Then I thought, what's the point, so much water has passed
under the bridge.

So as the song was in West Side Story, "Cool..., Stay

man ....".

Jimmy

Alistair

2005-11-24, 6:55 pm

James, whish you had send this before I splashed out a whole pound
sterling on Standard O O Cobol. I thought the case for OO was not made
and the trivial examples merely served to push me away from OO;
afterall, what is the point of overly complicating a simple program and
increasing the line count by 50% just to write it in OO Cobol?

Richard

2005-11-24, 6:55 pm

> afterall, what is the point of overly complicating a simple program and
> increasing the line count by 50% just to write it in OO Cobol?

There is a point to OO, but many Cobol programs - especially batch
sequential processing programs - would not realise it.

One could write a 'class' using a called Cobol subprogram. You would
CALL using some parameters one being a function code: 'O' for Open, 'X'
for Close, 'R' to Read, etc. The subprogram would maintain data in
Working-Storage.

If the same were written in OO Cobol it would not be much different.
There would be W-S data and the functions would be done by invoking
different methods (Open, Close, ..) rather than passing a function code
as a parameter.

There would be some advantages for the OO version, but only if this was
required by the application. For example if you needed two or more
instances then the standard CALLed routine could be duplicated with a
different name, or it could be modified to hold its WS data in a table
and the application would pass an 'instance' number along with the
function code.

With the OO class the application can just create another instance and
then the methods will work on the instance data items correctly. In
fact you could have any number of objects created as long as you keep
track of them in a table or in a collection.

With standard Cobol if you have a routine that works well but you need
a somewhat different behaviour you could write another routine that
calls that one for most of the job and has code to cater for the
differences. The application can call your new routine and need not
know that it uses the other. This can get complicated if some other
part of the application also wants to use the original. With OO you do
this using the facilities provided and this avoids issues with
duplication of use.

Now as OO has a reliable way of inhereting the behaviour of one class
to form another it is possible to extract the common behaviour from a
number of routines and make one class of this that is inhereted by each
of those routines leaving just the differences. Of corse this is only
useful if you do have a number of similar called subprograms.

Take for example report programs. An application may have dozens of
report programs each of which has many simularities. If you took all
the code that was the same and put this in a report class and then each
report would use that class for the common stuff and override the code
that was unique to this particular report then the total amount of code
for a set of reports would be less.

There would also be an advantage in that changing the base class
affects all derived classes without having (usually) to change them
all, they inheret at run time, while copy and paste and COPY inheret
behaviour at edit time or compile time respectively.

However, you don't get there starting from here. Given an existing
application it is very hard to justify the change because it does mean
"more code". For one new report it is much easier and quicker to cut
and paste then it is to build with 50% more code for OO. If you were to
need 3 new reports, or 10, then OO would be _less_ code and should be
more reliable and more easily maintained. At least that is the claim.

However I agree that it is very easy to be put off by bad examples. I
once started an OO tutorial that had the line:

Bob = new Employee("Bob Smith");

WTF! Does this mean I have to rewrite the program for each new employee
in the company so I add code when Mary joins:

Mary = new Employee(..)

In any case the Payroll system works by serially reusing the Employee
record for each and every past, present and future employees one at a
time so why would that application ever need two 'Employee' objects at
the same time, just do a WRITE ?

That put me off bothering with OO for a while: OO writers do not
understand DP systems or batch processing with serial reuse of the
'object'. That is not to say that OO is not useful, nor that you
couldn't apply OO to batch, but it is difficult to see the benefits of
applying OO to 'the next bit that needs doing'. What is needed is a
view of how it could be if the whole application was OO and then cast a
path that would get there by developing classes that would be useful to
many parts of the system with the expectation of plugging those in at
the appropriate time.

James J. Gavan

2005-11-24, 9:55 pm

Richard wrote:
>
>
> There is a point to OO, but many Cobol programs - especially batch
> sequential processing programs - would not realise it.
>
> One could write a 'class' using a called Cobol subprogram. You would
> CALL using some parameters one being a function code: 'O' for Open, 'X'
> for Close, 'R' to Read, etc. The subprogram would maintain data in
> Working-Storage.

<snip>......

Well you covered that very well by your illustrations - but as back up,
take a look :-

*>-----------------FileIsam.cbl-----------------------------------

Class-id. IsamFile
inherits from FileErrors.

Class-control. IsamFile is class "fileisam"
FileErrors is class "filerror"

Richard

2005-11-25, 3:55 am

> if ws-fileStatus = "00" or "10" *> EOF

Now for my obligitory:

When testing the file status values for successful only the first byte
should be checked for "0".

James J. Gavan

2005-11-25, 3:55 am

In-Reply-To: <1132888488.263023.161610@g14g2000cwa.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 10
Message-ID: <whxhf.605134$oW2.293275@pd7tw1no>
Date: Fri, 25 Nov 2005 05:27:56 GMT
NNTP-Posting-Host: 24.71.223.147
X-Complaints-To: abuse@shaw.ca
X-Trace: pd7tw1no 1132896476 24.71.223.147 (Thu, 24 Nov 2005 22:27:56 MST)
NNTP-Posting-Date: Thu, 24 Nov 2005 22:27:56 MST
Organization: Shaw Residential Internet
Xref: number1.nntp.dca.giganews.com comp.lang.cobol:152739

Richard wrote:
>
>
> Now for my obligitory:
>
> When testing the file status values for successful only the first byte
> should be checked for "0".
>
PEESS OFF - But you can always add it :-)

Sponsored Links