Cobol - [NOT OT] Collection Classes

Author

[NOT OT] Collection Classes

William M. Klein

2007-02-02, 6:55 pm

Given the recent (ongoing) threads about Java, C#, C++ etc in comp.lang.cobol, I
thought I would mention that J4 has *finally* turned over the "OO Collection
Classes Technical Report" to the ISO people. I expect to get an announcement
soon about when the "official" national body ballot will be happening. If you
are interested in reading the draft, it is available at:

http://www.cobolstandard.info/j4/files/06-0201.doc

The relevance (to me) of this to the ongoing comp.lang.cobol threads is that the
Micro Focus position (which I agree with, but others certainly may NOT) is:

Object Oriented COBOL does not (and probably never will) live in an "Object
Oriented vacuum". It would be much, MUCH better if COBOL provided all (any
missing) facilities to interact with the "collection classes" (as well as other
objects, classes, and methods) provided by more popular (dominant?) OO languages
than to provide its own language-specific collection classes. Therefore, as
previously mentioned here (and at J4), Micro Focus will be opposing this draft
Technical Report *and* adding this language specific solution to a future COBOL
Standard.

If anyone who reads this comp.lang.cobol post would like me to "keep them
informed" (off-list) of the progress of this TR and/or how to send their
comments (PRO *or* CON) to the appropriate national Standards body, please send
me an email "off-list".

P.S. Nothing in this note should be read as a personal "endorsement" of the
current (or past) ANSI/ISO COBOL process. However, as this *IS* an "ongoing"
process, I still believe that getting "real world user" input is a good thing -
whether it actually has any impact is simply another matter <G>.

--
Bill Klein
wmklein <at> ix.netcom.com

Frank Swarbrick

2007-02-02, 9:55 pm

William M. Klein<wmklein@nospam.netcom.com> 02/02/07 5:36 PM >>>
>Given the recent (ongoing) threads about Java, C#, C++ etc in
comp.lang.cobol, I
>thought I would mention that J4 has *finally* turned over the "OO
Collection
>Classes Technical Report" to the ISO people. I expect to get an
announcement
>soon about when the "official" national body ballot will be happening. If
you
>are interested in reading the draft, it is available at:
>
> http://www.cobolstandard.info/j4/files/06-0201.doc
>
>The relevance (to me) of this to the ongoing comp.lang.cobol threads is
that the
>Micro Focus position (which I agree with, but others certainly may NOT)
is:
>
>Object Oriented COBOL does not (and probably never will) live in an "Object

>Oriented vacuum". It would be much, MUCH better if COBOL provided all (any

>missing) facilities to interact with the "collection classes" (as well as
other
>objects, classes, and methods) provided by more popular (dominant?) OO
languages
>than to provide its own language-specific collection classes. Therefore,
as
>previously mentioned here (and at J4), Micro Focus will be opposing this
draft
>Technical Report *and* adding this language specific solution to a future
COBOL
>Standard.
>
>If anyone who reads this comp.lang.cobol post would like me to "keep them
>informed" (off-list) of the progress of this TR and/or how to send their
>comments (PRO *or* CON) to the appropriate national Standards body, please
send
>me an email "off-list".
>
>P.S. Nothing in this note should be read as a personal "endorsement" of
the
>current (or past) ANSI/ISO COBOL process. However, as this *IS* an
"ongoing"
>process, I still believe that getting "real world user" input is a good
thing -
>whether it actually has any impact is simply another matter <G>.

Does this mean that "OO COBOL" *must* be dependant on things such as the
..NET framework or Java in order to support collections? While certainly
interaction with those other languages/frameworks is desirable, it rubs me
the wrong way to say that in order to have a useful OO COBOL environment you
*must* have something other than just COBOL.

Do I have a solution? No. Just a comment.

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

LX-i

2007-02-03, 6:55 pm

Frank Swarbrick wrote:
>
> Does this mean that "OO COBOL" *must* be dependant on things such as the
> .NET framework or Java in order to support collections? While certainly
> interaction with those other languages/frameworks is desirable, it rubs me
> the wrong way to say that in order to have a useful OO COBOL environment you
> *must* have something other than just COBOL.

Think of it as "code reuse" on a really large scale. :) Or maybe a
really big subclass...

public class OOCobol extends Java1_5 {
IDENTIFICATION DIVISION.
....
}

> Do I have a solution? No. Just a comment.

What does it matter if the COBOL compiler writes code to run in a JVM or
CLR? I understand from a COBOL purist's view ("Hey, if I wanted to run
Java, I'd *WRITE* Java!"), but I can also see MicroFocus's perspective
too. They could provide a lot more functionality to their users by
basically giving up the custom run-time, and building translations of
their code into a widely distributed, common format.

Which one would I go with? Hard to say. As a COBOL specialist, I'd
probably lean toward a third option - COBOL that did everything else
those "other guys" do. :) But, I suspect that convergence is
unavoidable. For over 5 years now, we've been writing XML and HTML
using COBOL; we have applets that act like clients; and we've oftentimes
struggled to adapt quickly, while restricted to the old release
processes. (Should it require a special release to change "hte" to "the"?)

Of course, I'm a realist too. Less than 20% of software I've ever used
worked "as advertised", and it's luck of the draw as to what works.
Among seams I've found with our compilers or runtime are things like not
being able to define an independent "index" variable if you use "is
initial" after the program-id; database date conversions not working;
even program aborts because of an error in the database runtime. And
this is just SQL with COBOL! The difference is, it's proprietary. We
were exercising parts of their code that no one else ever had.

It's this that makes me wonder. Nothing's 100%, but would development
and execution be *more* predictable if, instead of a narrow runtime
environment, a wider environment was used. It could be a mutually
beneficial relationship for both COBOL and Java/.NET. :)

I'm still glad I'm not the one making the call for an entire
corporation, though...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine

Howard Brazee

2007-02-05, 6:55 pm

On Fri, 2 Feb 2007 18:36:36 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:

>Does this mean that "OO COBOL" *must* be dependant on things such as the
>.NET framework or Java in order to support collections? While certainly
>interaction with those other languages/frameworks is desirable, it rubs me
>the wrong way to say that in order to have a useful OO COBOL environment you
>*must* have something other than just COBOL.

On the other hand - it irks me that so many OO environments tend to be
single-language. The libraries should be tool chests with each tool
designed to do what it does best.

Frank Swarbrick

2007-02-05, 6:55 pm

Howard Brazee<howard@brazee.net> 02/05/07 8:17 AM >>>
>On Fri, 2 Feb 2007 18:36:36 -0700, "Frank Swarbrick"
><Frank.Swarbrick@efirstbank.com> wrote:
>
me[color=darkred]
you[color=darkred]
>
>On the other hand - it irks me that so many OO environments tend to be
>single-language. The libraries should be tool chests with each tool
>designed to do what it does best.

True enough. That's something that the CLR does very nicely is it works
with many languages. Then again, those languages have "tweaks" to work with
the CLR so that they are no longer the standard version of that language
(see COBOL, C++, Java (J#)). (Other than C#, of course, which has always
been based on the CLR and does not work without it (I think!).)

Seems like a no-win situation...

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

William M. Klein

2007-02-05, 6:55 pm

Frank,
I agree that there are "philosophical implications" of the Micro Focus (and
my) personal opinion on this subject.

Let me give an example that MAY "hit home" to you. (I can't remember if DOS/VS
COBOL supported the Communications Section, but I know that OS/VS COBOL did).

The "Communications Section" was a "native COBOL" way to handle some (not all)
of what CICS does. At least for the MVS environment, you could (a few customers
actually DID) code "native COBOL" interfaces to TCAM. On the other hand, CICS
proved a "language neutral" way of doing this (and much more).

Which would you think was "better" to use the native-language COBOL-only
solution - or to use a "generic interface"?

To me, this is similar to what is happening with OO Collection Classes. So far,
I don't know of ANY OO COBOL implementation that works in an environment where
this isn't one or more OO non-COBOL languages (usually if not always MORE
commonly used). It is true that theoretically, there may (some day) be an OO
COBOL without C++, C#, Java, or whatever also available, but I doubt it.

Therefore, it seems important to me that OO COBOL work *with* not outside those
classes, object, methods, etc that are in "common" usage. There *are*
classes/objects that handle things like "dictionaries" (see other thread) today.
I few it as important that COBOL work using those methods (and native COBOL
syntax for working with objects/methods) RATHER than COBOL defining its own
classes/methods to do the same thing.

***

Again, this is a personal opinion (and that of Micro Focus) and I understand
that others may have different views. Whatever their views, I do hope that SOME
"real world COBOL users" do communicate them to the national Standards bodies
that are having to make decisions about this.

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:52i797F1p29k7U1@mid.individual.net...
> William M. Klein<wmklein@nospam.netcom.com> 02/02/07 5:36 PM >>>
> comp.lang.cobol, I
> Collection
> announcement
> you
> that the
> is:
>
>
> other
> languages
> as
> draft
> COBOL
> send
> the
> "ongoing"
> thing -
>
> Does this mean that "OO COBOL" *must* be dependant on things such as the
> .NET framework or Java in order to support collections? While certainly
> interaction with those other languages/frameworks is desirable, it rubs me
> the wrong way to say that in order to have a useful OO COBOL environment you
> *must* have something other than just COBOL.
>
> Do I have a solution? No. Just a comment.
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA

Pete Dashwood

2007-02-05, 9:55 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:nsOxh.1257$dB4.108@fe08.news.easynews.com...
> Frank,
> I agree that there are "philosophical implications" of the Micro Focus
> (and my) personal opinion on this subject.
>
> Let me give an example that MAY "hit home" to you. (I can't remember if
> DOS/VS COBOL supported the Communications Section, but I know that OS/VS
> COBOL did).
>
> The "Communications Section" was a "native COBOL" way to handle some (not
> all) of what CICS does. At least for the MVS environment, you could (a few
> customers actually DID) code "native COBOL" interfaces to TCAM. On the
> other hand, CICS proved a "language neutral" way of doing this (and much
> more).

I remember writing a Communications application using the COBOL facility,
but it was in MicroFocus COBOL... (at least I think it was...)
>
> Which would you think was "better" to use the native-language COBOL-only
> solution - or to use a "generic interface"?

I think the same is true for the XML interface. These are attempts to solve
problems that are not a problem.

I've been using XML from COBOL for around 3 years now; it isn't a problem.
(In C# it is a delight :-))

> To me, this is similar to what is happening with OO Collection Classes.
> So far, I don't know of ANY OO COBOL implementation that works in an
> environment where this isn't one or more OO non-COBOL languages (usually
> if not always MORE commonly used). It is true that theoretically, there
> may (some day) be an OO COBOL without C++, C#, Java, or whatever also
> available, but I doubt it.

So do I.

So, what SHOULD COBOL be doing?

I honestly believe COBOL missed the boat. There wasn't the uptake of OO
COBOL that there needed to be to ensure the survival of the language. People
now are starting to wake up to the advantages of an OO approach but it is
far too late. The (non-COBOL) world has already voted with its feet and
COBOL is now a niche enclave of procedural programming that only has
relevance in a batch environment. (CICS implementations will be slowly but
surely replaced by networked applications, and when this process is largely
complete, there will be no need even for OO COBOL.)

Perhaps the answer is in platform independent runtimes like DotNET that
don't care about the source code. However, COBOL is pricing itself out of
this market, too. (Both the Fujitsu and MicroFocus products are just too
dear to make them viable for development in this environment. Why would you
pay large sums of money, when you can change your mind, learn a new language
that is simple and elegant, comes with an IDE that is light years ahead of
anything we've seen for COBOL, and do it for free?)

I don't think anything is to be gained by trying to enhance COBOL so it can
do what other languages do, in an environment that other languages were
designed to run in. Just use the other languages...

It all comes down to "mindsets".

There was a time when development could be done in one language. There was
only one platform (usually, a central mainframe.). Source code was
everything. People could make a relatively easy living, learning a single
English-like language that was in great demand by industry to enable them to
computerize their businesses. Life for COBOL programmers, was pretty good.

Those days are over but there are still people who can't let go of them.
("We've always done it like this..." "Everything I want to do, I can do in
COBOL..." "All this new-fangled stuff is just a new look at what we've
always done in COBOL..." ""OO is just modular programming re-invented...
nothing to see here...")

Meantime, the rest of the world, backed by Acadaemia, was looking for better
ways to do things.

The COBOL Religion, with its rigid mindset and resistance to change was
simply bypassed.

New languages emerged that were better suited to the new environments
(hardware and software). Objects became a better paradigm. The High Priests
of COBOL simply never got it. There was no attempt to really understand the
new concepts. The Voices who cried in the Wilderness were, for the most
part, simply dismissed and ridiculed. (So we stopped crying :-))

Now, it is too late.

There is nothing I can do in COBOL that I cannot do at least as well in
another language. And the cost of ownership of those other languages is a
fraction of the cost of ownership of COBOL.

OK, I don't have any current requirement to do batch processing on a
centralised mainframe; if I did, I'd probably do it in COBOL, but I cannot
think of any reason why I would continue OO development in COBOL (and,
believe me, I have tried... :-) I have a HUGE investment in COBOL code and
abandoning it is not a decision to be taken lightly.)

So, coming back to the topic, SHOULD COBOL be supporting it's own innate
Collection Class? (or XML, or Network Communication, or whatever?)

No, I don't think so.

Again, what SHOULD COBOL be doing?

Ensuring it can interface easily to these facilities, just like other modern
languages. COBOL doesn't need a Collection Class (or any other innate
Classes) it if it can use the ones provided by DotNET (FCL), or MFC, or any
other third party. The variation in .DLL formats is not so great that a
common interface (or layered wrapper) can't be developed. (It works for COM,
and has for some years now...)

And before we get sidetracked into MS ruling the world, the latest
implementations of CORBA allow COM components to run in Unix environments.

>
> Therefore, it seems important to me that OO COBOL work *with* not outside
> those classes, object, methods, etc that are in "common" usage. There
> *are* classes/objects that handle things like "dictionaries" (see other
> thread) today. I few it as important that COBOL work using those methods
> (and native COBOL syntax for working with objects/methods) RATHER than
> COBOL defining its own classes/methods to do the same thing.

Important? Maybe... (I find it increasingly difficult to view anything
COBOL standard related as "important"... Had their chance; blew it, in my
opinion...) Nevertheless, I completely agree with your feelings on this.
>
> ***
>
> Again, this is a personal opinion (and that of Micro Focus) and I
> understand that others may have different views. Whatever their views, I
> do hope that SOME "real world COBOL users" do communicate them to the
> national Standards bodies that are having to make decisions about this.
>

I probably don't need to tell you that I won't be doing this, Bill. Still,
if there are still people who care about it, I hope they bang their heads
against the wall; you never know, it may shake some tiles loose...:-)

Pete.

Howard Brazee

2007-02-06, 6:55 pm

On Tue, 6 Feb 2007 14:07:33 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>I remember writing a Communications application using the COBOL facility,
>but it was in MicroFocus COBOL... (at least I think it was...)

And I used CoBOL programs where we basically ignored Working Storage -
the Communications section was used for pseudo-conversational logic.
The thing is - CoBOL wasn't designed for transaction processing (nor
for OO), those features were add-ons and we did not have a consistent
integral way of using it. But there weren't many alternatives - at
least there weren't cheap ways to try it out - so we adapted.

>I honestly believe COBOL missed the boat. There wasn't the uptake of OO
>COBOL that there needed to be to ensure the survival of the language. People
>now are starting to wake up to the advantages of an OO approach but it is
>far too late.

I'm not sure that anybody could have done anything about it. CoBOL
was used to run the big old programs, isn't as adaptable as library
languages like C, and didn't force us to think in OO. It also is
more expensive for those who want to just experiment to see how it
fits.

So a few languages adapted (or maybe just one). And some languages
designed from scratch to fit the new paradigm survive.

Pete Dashwood

2007-02-06, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:6d6hs29svpocecboihp630sau5u0heb241@
4ax.com...
> On Tue, 6 Feb 2007 14:07:33 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> And I used CoBOL programs where we basically ignored Working Storage -
> the Communications section was used for pseudo-conversational logic.
> The thing is - CoBOL wasn't designed for transaction processing (nor
> for OO), those features were add-ons and we did not have a consistent
> integral way of using it. But there weren't many alternatives - at
> least there weren't cheap ways to try it out - so we adapted.
>
>
> I'm not sure that anybody could have done anything about it. CoBOL
> was used to run the big old programs, isn't as adaptable as library
> languages like C, and didn't force us to think in OO.

That's a very good point, Howard. COBOL didn't require us to think in OO, in
fact, it reinforced NOT doing so.

I agree that nobody could really have done much about it.

However, I also believe (and it is just an opinion; I can't prove it...)
that there was a high level of inertia and lack of vision in the User base.
I guess it is understandable; when you've been doing something a certain way
for decades, there is no urgency to consider changng your approach.

Whatever the reasons, the technology moved on, but the COBOL user base
didn't.

I'm still sorry to see it go :-)

Pete.
> It also is
> more expensive for those who want to just experiment to see how it
> fits.
>
> So a few languages adapted (or maybe just one). And some languages
> designed from scratch to fit the new paradigm survive.

Sponsored Links