Object Oriented Fujitsu Cobol example

[Zalek Bloom]

I am looking for any example of Object Oriented Fujitsu Cobol source.

Is it worth to convert regular batch Fujitsu Cobol to OO?

Thanks,

Zalek

[Richard]

On Mar 6, 1:38 pm, Zalek Bloom <zalekbl...@gmail.com> wrote:

> I am looking for any example of Object Oriented Fujitsu Cobol source.

Here's one that I prepared earlier.


http://groups.google.com/group/comp.lang.cobol/browse_frm/thread/41f28746f0fe0366/809a400124d02abe?lnk=gst&q=rawprint#809a400124d02abe

> Is it worth to convert regular batch Fujitsu Cobol to OO?

One real advantage of OO is that it is possible to have multiple
instances of an object, each encapsulated so that they can be operated
on in the manner they require.

Batch programs usually only require a single instance of each item and
process using serial reuse. ie they usually only require a single
record area per file and reuse that area for each record in the file.

[Pete Dashwood]

Zalek Bloom wrote:
> I am looking for any example of Object Oriented Fujitsu Cobol source.

Please take a look at: http://primacomputing.co.nz/cobol21/

In particular... The link to the COBDATA Structure analyser tool.

"This is an example of standard COBOL running on .NET. The underlying
engine was written by Robert Wagner as standard procedural COBOL. See how it
is easily converted to OO COBOL and wrapped as a COM component. Finally, a
presentation layer is added in C# and the whole application becomes a .NET
assembly.

Follow the link for full details and download of the tool itself, the COBOL
sources (both standard and OO), and the C# source. "

It is a free tool which several hundred people have found useful, but,
perhaps more importantly for you, it shows the changes needed to convert
standard COBOL into OO COBOL. The original COBOL code is provided and the OO
code is provided with the changes flagged in it.

>
> Is it worth to convert regular batch Fujitsu Cobol to OO?
>

I agree with Richard's assessment on this.

Generally, there is not much benefit in converting batch processes to OO
COBOL.

HOWEVER, if there is functionality within that batch process which could be
used elsewhere, then it certainly does no harm to extract that functionality
(CALLed module, PERFORMED subroutine, even sections of inline code) and wrap
it into an OO Component.

This means it can be easily reused in desktop or web based applications and
it can still run in a batch process. (The batch process invokes the object
methods just like any other desktop application.)

I would not advise taking a whole batch process and making it OO. Use OO
COBOL to refactor the functions and processes that you don't want to lose in
the future, and which you would like to have in any future environment you
may set up.

Please also have a read of:
http://primacomputing.co.nz/COBOL21/COBOLRelevance.aspx


Pete.
--
"I used to write COBOL...now I can do anything."