project stickleback

[w.ni...@gmail.com]

Cobol does enjoy a crowd of experts and the language is attracting attention of young people.
I guess because learning current languages has a steep curve.

However, the lack of good examples (read: source code) or working systems in Cobol will drive them away. It is remarkable that most efforts die in a enthusiastic approach trying to mimic OO design trends, looking for syntactic sugar and such. It is obvious that a background of WHY Cobol, HOW to use Cobol and WHEN to turn to Cobol is missing in educational settings.

It is my opinion that having Cobol projects available in open source will push the attention for Cobol in heights. It is my opinion too that Cobol can be used as THE Cloud transaction processing.

In this setting I have started project StickleBack in order to push (donated) Cobol systems (in source code) into the open source, to create decent tutorials on Cobol and to publish a set of standards suitable to form a framework.

What do think? Any tips, donations, sponsoring, collaboration?

[Pete Dashwood]

I wish you every success and will link to your site if you get it off the
ground.

I'm currently working on some of the things you mentioned but not from the
perspective you mentioned.

I don't see COBOL as viable in comparison to modern languages, for modern
environments, but I DO see a need to salvage what is there.

Good Luck,

Pete.

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

[Patrick]

I am not young-young, I am 37 but I am learning Cobol and really loving it.

You are so so very correct about the lack of good examples and another issue is that the few code examples available seem to be from different dialects.

I really hope your efforts bare fruit, it would be so great for me and many others.

BTW Cobol is probably the 20th language I have tried to learn. Some of those 20 were just tinkering for a few nights but I have to say that the FUD that is being spread about the language is largely false. The only thing I am missing is more powerful "include/require/import" system to include code.

-Patrick



" I used to write C, C++, PHP, Python, Perl, Ruby, Pascal, Javascript, Ada, Forth, Lisp, Fortran, Go, Lua, Factor, Tcl/Tk, Vala, Boo....now I can do anything"

[Fred Mobach]

That's great. You might consider opencobol (it runs on GNU/Linux, Unix,
Mac OS X and MS-Windows) [1]. You can find a dedicated mailinglist for
it at https://lists.sourceforge.net/lists/listinfo/open-cobol-list. The
FAQ can be found at http://opencobol.add1tocobol.com/.

As soon as your project's website is up I can perhaps show some Free
Software sources if anyone is interested.

It might be a challenge for experienced COBOL programmers to create
sources for educational use so show me please the TODO list for that.

[1]. Here opencobol runs on openSUSE (x64) and Debian (Raspberry-PI).
--
Fred Mobach
website : https://fred.mobach.nl
.... In God we trust ....
.. The rest we monitor ..

[Vince Coen]

Hello w!

14 May 13 12:14, you wrote to All:

> In this setting I have started project StickleBack in order to push
> (donated) Cobol systems (in source code) into the open source, to
> create decent tutorials on Cobol and to publish a set of standards
> suitable to form a framework.

> What do think? Any tips, donations, sponsoring, collaboration?

Let me know when you have it up and running and I will pass over a few
systems.

Vince

[w.ni...@gmail.com]

Hello Pete,

as of this week some efforts are live:

a web site http://stickleback.nlbox.com

a portal http://www.mycobol.net

I would love to see COSSET as a feature on mycobol.net?

Have a peek. Register at the portal.

Cheers,
wim niemans ri



Op dinsdag 14 mei 2013 13:32:37 UTC+2 schreef Pete Dashwood het volgende:

[w.ni...@gmail.com]

Hello Vince,

take a peek at the portal http://www.mycobol.net
when you register as a user there, we can exchange the systems.

Cheers,
wim niemans ri

Op woensdag 15 mei 2013 00:21:23 UTC+2 schreef Vince Coen het volgende:

[Pete Dashwood]

I'm afraid the source code of the COSSET package is copyright to CDC who are
now defunct. I don't have a copy of it (it was on punch cards).

However, I did have a quick look at the portal and it has a number of things
I was planning for "The Lounge" at http://primacomputing.co.nz

Maybe I'll just link to them... still working on some other stuff for the
site at the moment.

Glad to see you are persevering...

Good Luck!

[Pete Dashwood]

w.ni...@gmail.com wrote:
> Cobol does enjoy a crowd of experts and the language is attracting
> attention of young people.
> I guess because learning current languages has a steep curve.
>
> However, the lack of good examples (read: source code) or working
> systems in Cobol will drive them away. It is remarkable that most
> efforts die in a enthusiastic approach trying to mimic OO design
> trends, looking for syntactic sugar and such. It is obvious that a
> background of WHY Cobol, HOW to use Cobol and WHEN to turn to Cobol
> is missing in educational settings.

And not just in educational settings...there isn't much informed opinion
around in industry either.

The trouble is that most of the COBOL old-timers can only see COBOL and are
suspicious of the new paradigm because they don't understand it.

It is "strange", "different", has its own jargon, and is "esoteric"...

I wonder how many of them remember the effect that:

02 fltctr REDEFINES sumctr PIC s9(6)v9(12) comp.

... had on uninitiated people in the last century...

There are cases where you SHOULD use COBOL and, much to my own surprise, I
found myself endorsing such a case in a LinkedIN forum recently.

But mostly, we need to move COBOL on, or move on from it.

I've had some pressure lately to clarify my position on this and why I am so
"anti-COBOL" (I'm, actually not...:-)), so I have added a new presentation
to the web site which covers my thoughts on WHAT we need to do with COBOL,
and WHY we need to do it... similar to your emphasis above.

Please take a look at:

http://primacomputing.co.nz/primametro/demosandtutorials.aspx

and click on the tile for "Salvaging COBOL"

>
> It is my opinion that having Cobol projects available in open source
> will push the attention for Cobol in heights. It is my opinion too
> that Cobol can be used as THE Cloud transaction processing.

Well, it is hard to quantify that, Wim. I guess we have to wait and see.

I do wish you every success with your enterprise.

[Bill Gunshannon]

In article <b4ph0f...@mid.individual.net>,

"Pete Dashwood" <dash...@removethis.enternet.co.nz> writes:
> w.ni...@gmail.com wrote:
>> Cobol does enjoy a crowd of experts and the language is attracting
>> attention of young people.
>> I guess because learning current languages has a steep curve.
>>
>> However, the lack of good examples (read: source code) or working
>> systems in Cobol will drive them away.

This is not the first time I have seen this comment. And yet, I have
piles of source code for COBOL systems. Published in books, available
on the web. All of the source for all of Murach's books is out there.
I have a COBOL/SYBASE book and all the source was there.

>> It is remarkable that most
>> efforts die in a enthusiastic approach trying to mimic OO design
>> trends, looking for syntactic sugar and such. It is obvious that a
>> background of WHY Cobol, HOW to use Cobol and WHEN to turn to Cobol
>> is missing in educational settings.
>
> And not just in educational settings...there isn't much informed opinion
> around in industry either.

Education is much more interested in driving the bus than actually
preparing students for real jobs. I used to get coplaint emails
from former students here because when Ada first came out the depart-
ment just had to jump on the bandwagon and use it as their primary
educational programming language. And then students went out into
world to learn that Ada had been resoundingly rejected by 90% of
the US IT world.

>
> The trouble is that most of the COBOL old-timers can only see COBOL and are
> suspicious of the new paradigm because they don't understand it.

Not sure I would say most. I certainly don't and a lot of my peers
share my undersdtanding of programming and softwarfe engineering.
Pick the right tool for the job. And sometimes (not always) that
tool is COBOL.

>
> It is "strange", "different", has its own jargon, and is "esoteric"...

Nothing like Mumps (ANSI-M) and yet it seems to be holding its own.
Probably because CS departments never touched it and so there is no
one out there badmouthing it.

>
> I wonder how many of them remember the effect that:
>
> 02 fltctr REDEFINES sumctr PIC s9(6)v9(12) comp.
>
> ... had on uninitiated people in the last century...

"uninitiated" people are lost in any language. How do they fare with
unions in C?

>
> There are cases where you SHOULD use COBOL and, much to my own surprise, I
> found myself endorsing such a case in a LinkedIN forum recently.
>
> But mostly, we need to move COBOL on, or move on from it.

Here is where we part company. COBOL is fine for what it was designed
to do and sometimes, we still have to do that. If you have a task to
do that does not fit the COBOL paradigm then pick a language that matches
the job. But don't say COBOL needs to morph into a verbose form of Java
in order to be usable.

>
> I've had some pressure lately to clarify my position on this and why I am so
> "anti-COBOL" (I'm, actually not...:-)), so I have added a new presentation
> to the web site which covers my thoughts on WHAT we need to do with COBOL,
> and WHY we need to do it... similar to your emphasis above.

See my emphasis above!! :-)

>
> Please take a look at:
>
> http://primacomputing.co.nz/primametro/demosandtutorials.aspx
>
> and click on the tile for "Salvaging COBOL"
>
>>
>> It is my opinion that having Cobol projects available in open source
>> will push the attention for Cobol in heights. It is my opinion too
>> that Cobol can be used as THE Cloud transaction processing.

I know of one very useful project that would fit the open source
world. Web frontend, COBOL midle-ware, DB backend. I just never
seem to have the time to work on it. Library Card Catalog System.
How many small public libraries are out there that can not afford
a real one so they are trying to get by with something written for
them locally, usually in something like Excel. how's that for the
wrong tool for the job!!

>
> Well, it is hard to quantify that, Wim. I guess we have to wait and see.
>
> I do wish you every success with your enterprise.
>

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Pete Dashwood]

Mostly, and certainly for a networked environment, it isn't.

If you want to argue this, my position is clear from the presentation quoted
earlier. (and the link below)

If you watch the presentation, and wish to argue any of the points in it,
I'll be happy to respond, but I'm not going to waste time here presenting
arguments I already presented publicly.

>>
>> It is "strange", "different", has its own jargon, and is
>> "esoteric"...
>
> Nothing like Mumps (ANSI-M) and yet it seems to be holding its own.
> Probably because CS departments never touched it and so there is no
> one out there badmouthing it.
>

Mumps never was a mainstream solution, despite the quality of the DEC
hardware it ran on. Somewhere, people are probably still using JOVIAL and
FORTRAN, too...

>>
>> I wonder how many of them remember the effect that:
>>
>> 02 fltctr REDEFINES sumctr PIC s9(6)v9(12) comp.
>>
>> ... had on uninitiated people in the last century...
>
> "uninitiated" people are lost in any language. How do they fare with
> unions in C?

Yes, but COBOL was SUPPOSED to be "English like" and able to be understood
by Accountants and Managers...

(Note in passing...)
In its original incarnation (COBOL '59 - the first compiler I worked
with...) there was NO picture clause. Data definition was provided by SIZE,
CLASS, and USAGE clauses. PICTURE was introduced because this was too
verbose even for COBOL people...

>
>>
>> There are cases where you SHOULD use COBOL and, much to my own
>> surprise, I found myself endorsing such a case in a LinkedIN forum
>> recently.
>>
>> But mostly, we need to move COBOL on, or move on from it.
>
> Here is where we part company. COBOL is fine for what it was designed
> to do and sometimes, we still have to do that. If you have a task to
> do that does not fit the COBOL paradigm then pick a language that
> matches the job. But don't say COBOL needs to morph into a verbose
> form of Java in order to be usable.

I have never said any such thing, and we are closer in agreement on this
than you might think.

I don't think OO COBOL is a good long term solution. (And I have come to
that conclusion after using it for around 15 years.) Not because I don't
think it is well implemented; I think the extension of COBOL to support OO
constructs is one of the finest feats of software engineeering I have ever
seen. Unfortunately (for COBOL), the OO languages support OO better, so if
you are working with that paradigm, COBOL is NOT the best tool for the job.

Around about now, a lot of guys who moved to .NET COBOL compilers are
beginning to realize that they could do their job better in a different
language. They turned the learning curve on OO and are starting to realize
that using COBOL in that environment is tiresome, takes longer to write and
maintain, and is not a good solution. (However, it is better than NO
solution...)

Meanwhile, their management are starting to wake up to the fact that COBOL
is EXPENSIVE, and compilers like C# and JAVA are FREE. Why would you opt for
a development tool which requires you to pay an "up front fee" to buy it, an
"ongoing fee" for support and maintenance, and a "run time fee" for
everything you build with it, when you can download C# for free, get instant
tuition, support, and code samples for free, and pay NO fees to anyone for
what you build with it? The ONLY reason for retaining COBOL is because you
are working in an environment where the procedural paradigm is still king.
Stick with the "same old, same old" and let your competitors run all over
you.

BUT, OO COBOL is an EXCELLENT solution to help people move their code onto a
networked platform.

>
>>
>> I've had some pressure lately to clarify my position on this and why
>> I am so "anti-COBOL" (I'm, actually not...:-)), so I have added a
>> new presentation to the web site which covers my thoughts on WHAT we
>> need to do with COBOL, and WHY we need to do it... similar to your
>> emphasis above.
>
> See my emphasis above!! :-)
>
>>
>> Please take a look at:
>>
>> http://primacomputing.co.nz/primametro/demosandtutorials.aspx
>>
>> and click on the tile for "Salvaging COBOL"

As noted above, I'll happily debate any points arising from this
presentation, but only if you have watched it first :-)

>>>
>>> It is my opinion that having Cobol projects available in open source
>>> will push the attention for Cobol in heights. It is my opinion too
>>> that Cobol can be used as THE Cloud transaction processing.
>
> I know of one very useful project that would fit the open source
> world. Web frontend, COBOL midle-ware, DB backend. I just never
> seem to have the time to work on it. Library Card Catalog System.
> How many small public libraries are out there that can not afford
> a real one so they are trying to get by with something written for
> them locally, usually in something like Excel. how's that for the
> wrong tool for the job!!

A tool is not "wrong" if it works; it may not be "the best" tool... :-)

>
>>
>> Well, it is hard to quantify that, Wim. I guess we have to wait and
>> see.
>>
>> I do wish you every success with your enterprise.
>>

[Rick Smith]

On Friday, July 19, 2013 12:00:30 AM UTC-4, Pete Dashwood wrote:
> Bill Gunshannon wrote:
> > In article <b4ph0f...@mid.individual.net>,

> > "Pete Dashwood" <dashw...@removethis.enternet.co.nz> writes:
> >> w.niem...@gmail.com wrote:
[...]

> > Not sure I would say most. I certainly don't and a lot of my peers
> > share my undersdtanding of programming and softwarfe engineering.
> > Pick the right tool for the job. And sometimes (not always) that
> > tool is COBOL.
>
> Mostly, and certainly for a networked environment, it isn't.

Yeah, but whose fault is that? <g>

One of the early implementations of a "networked environment"
was the COBOL Communications feature using the COBOL MCS to
pass text messages between a central computer (server) and
terminals (clients). While there may be both practical and
technical reasons why the feature, as defined, may not meet
today's needs, the failure to adapt to or refine the feature
may well have been 'political'.

Given that COBOL Communications "isn't" currently usable in
a "network environment", it is nonetheless reasonable, in
some cases to use COBOL with a 'foreign' interface to the
network.

[In reviewing the COBOL Communications feature, the expression
"Everything Old Is New Again" came to mind. Here is a video
of the song from the movie "All That Jazz".
< http://www.youtube.com/watch?v=nL22e30bFic >]

If it is possible to use COBOL, in any way, to transfer a page
with an embedded video, such as that given, then there is no
reason to not use COBOL in a "networked environment". I see no
reason why such a transfer cannot be done with COBOL using a
'foreign' interface.

> If you want to argue this, my position is clear from the presentation quoted
> earlier. (and the link below)
>
> If you watch the presentation, and wish to argue any of the points in it,
> I'll be happy to respond, but I'm not going to waste time here presenting
> arguments I already presented publicly.

At 24:15, you show "... RDB instead of flat files. ...". I believe
this should be 'indexed files'.

[...]

> >> But mostly, we need to move COBOL on, or move on from it.

I am not clear what you mean by 'move COBOL on'

[...]

> Meanwhile, their management are starting to wake up to the fact that COBOL
> is EXPENSIVE, and compilers like C# and JAVA are FREE. Why would you opt for
> a development tool which requires you to pay an "up front fee" to buy it, an
> "ongoing fee" for support and maintenance, and a "run time fee" for
> everything you build with it, when you can download C# for free, get instant
> tuition, support, and code samples for free, and pay NO fees to anyone for
> what you build with it?

I have yet to see any claims that the performance of C# and Java,
with few exceptions, beats the performance of native compiled
code. While that may not mean much for the individual or small
user, it can make a difference to large enterprises in the cost
of hardware to run C# or Java.

[...]

> >> Please take a look at:
> >>
> >> http://primacomputing.co.nz/primametro/demosandtutorials.aspx
> >>
> >> and click on the tile for "Salvaging COBOL"
>
> As noted above, I'll happily debate any points arising from this
> presentation, but only if you have watched it first :-)

Then, happily debate why you used 'flat files' instead of
'indexed files', as noted above. <g>

[Pete Dashwood]

Rick Smith wrote:
> On Friday, July 19, 2013 12:00:30 AM UTC-4, Pete Dashwood wrote:
>> Bill Gunshannon wrote:
>>> In article <b4ph0f...@mid.individual.net>,
>>> "Pete Dashwood" <dashw...@removethis.enternet.co.nz> writes:
>>>> w.niem...@gmail.com wrote:
> [...]
>>> Not sure I would say most. I certainly don't and a lot of my peers
>>> share my undersdtanding of programming and softwarfe engineering.
>>> Pick the right tool for the job. And sometimes (not always) that
>>> tool is COBOL.
>>
>> Mostly, and certainly for a networked environment, it isn't.
>
> Yeah, but whose fault is that? <g>
>
> One of the early implementations of a "networked environment"
> was the COBOL Communications feature using the COBOL MCS to
> pass text messages between a central computer (server) and
> terminals (clients).

Yes, I knew it well and used it in a couple of places. I'm pleased to see
you are not seriously suggesting it replace .Net... :-)

>While there may be both practical and
> technical reasons why the feature, as defined, may not meet
> today's needs, the failure to adapt to or refine the feature
> may well have been 'political'.

Not sure. I try not to comment on COBOL politics because it is still a sore
point with me. The language and the community (in my opinion) were badly let
down by the Standards Committee and, although some very fine people put in a
huge amount of effort (Bill Klein is a perfect example), there was no proper
management of that effort and we ended up with an unimplementable standard,
and some dispirited and demotivated ex-committee members. It's water under
the bridge and I let it go a long time ago but it still irritates me when I
think about it. I would also agree that the COBOL community as a whole was
resistant to change and that didn't help.

>
> Given that COBOL Communications "isn't" currently usable in
> a "network environment", it is nonetheless reasonable, in
> some cases to use COBOL with a 'foreign' interface to the
> network.

Rick, I have never suggested anywhere that you CAN'T do things with COBOL;
you often can, but it is tedious and requires a lot of work, compared with
just plugging in pre-written, already debugged, functionality with a few
lines of code. My point was, and still is, that procedural COBOL is NOT the
best tool for the job of providing and using network layers and objects. (OO
COBOL is fine and my objection there is not to the COBOL; only that there
are easier and (in my opinion, better...) languages for doing that with.

>
> [In reviewing the COBOL Communications feature, the expression
> "Everything Old Is New Again" came to mind. Here is a video
> of the song from the movie "All That Jazz".
> < http://www.youtube.com/watch?v=nL22e30bFic >]

I couldn't get the link to work from the text but cut and pasted it into the
browser. Excellent! And very entertaining...

>
> If it is possible to use COBOL, in any way, to transfer a page
> with an embedded video, such as that given, then there is no
> reason to not use COBOL in a "networked environment". I see no
> reason why such a transfer cannot be done with COBOL using a
> 'foreign' interface.

Ah, I can see a number of reasons to "not use COBOL" even if there was the
capability to transfer such a page.

1. It costs money to write and run it. (If you use Micro Focus) (Javascript
and HTML5 are free.)
2. It requires more code and therefore takes longer to write and is more
difficult to maintain. (The presentation you watched is driven by less than
a dozen lines of Javascript and HTML5 and that includes falling back to
Flash if the browser doesn't support HTML5, and also includes offering the
option to download the video if they are unable to view it at all.)
3. It doesn't innately support asynchronous processes in the way that
Javascript and C# 5 do.
4. It's difficult to find people who can do it. And they need to know the
'foreign interface' as well... :-)
5. It

I have been dealing with HTML5 videos for the PRIMA web site and addressing
the problems of outmoded browsers having to fall back to Flash. The videos
on the site took weeks of investigation, trial and error, and research
before I could get to an acceptable level of video delivery. Getting
deliverable video to everyone in the world is not a job for COBOL. It is
hard enough scripting this stuff in Javascript, I wouldn't even begin to do
it in COBOL.

>
>> If you want to argue this, my position is clear from the
>> presentation quoted earlier. (and the link below)
>>
>> If you watch the presentation, and wish to argue any of the points
>> in it, I'll be happy to respond, but I'm not going to waste time
>> here presenting arguments I already presented publicly.
>
> At 24:15, you show "... RDB instead of flat files. ...". I believe
> this should be 'indexed files'.

I agree, however I have no intention of editing the video now.

>
> [...]
>>>> But mostly, we need to move COBOL on, or move on from it.
>
> I am not clear what you mean by 'move COBOL on'

Move COBOL on from procedural COBOL to OO COBOL if you intend to salvage
your legacy, and move on from COBOL altogether once you have turned the
learning curve for OO.

Right about now there are a number of COBOL guys who have been using the new
OO COBOL .Net compilers and have come to grips with Object Orientation.
They're doing it in COBOL because it is familiar and that's the tool they've
been given. But they are starting to realize that if it is all about getting
everything to the .Net framework, then the .Net languages are better than
.Net COBOL for working in that environment. I see people moving to VB.Net
and C# for future .Net development, once we have their legacy COBOL migrated
to the platform. Some stay with COBOL; it is really their choice, but I
don't think there'll be many within a few years.

I could be wrong; time will tell.

The solution we are offering lets them continue with COBOL if they want to,
or they can move on to other languages. (And the Framework lets them use
multiple languages on a level playing field (I love .Net... :-))

>
> [...]
>> Meanwhile, their management are starting to wake up to the fact that
>> COBOL is EXPENSIVE, and compilers like C# and JAVA are FREE. Why
>> would you opt for a development tool which requires you to pay an
>> "up front fee" to buy it, an "ongoing fee" for support and
>> maintenance, and a "run time fee" for everything you build with it,
>> when you can download C# for free, get instant tuition, support, and
>> code samples for free, and pay NO fees to anyone for what you build
>> with it?
>
> I have yet to see any claims that the performance of C# and Java,
> with few exceptions, beats the performance of native compiled
> code.

After the initial JIT compile it IS 'native compiled code'... :-)

(Once an assembly has been JIT compiled if it is required again, it IS
native code; Assemblies are only JIT compiled when they need to be...)

In the same way that COBOL compiled native code may not be not quite as good
as Assembler code written by an experienced programmer, so the JIT compile
IS an added overhead on C#. However, it is not so significant that it is a
showstopper and the benefits far outweigh the very slight performance
penalty.

However, I agree with you about native compiled code. Except that the
differences are infinitesimal. A couple of years back when I was a bit
concerned about this (I'm not any more) I benchmarked native compiled code
using InterOP services against the same functionality written in C#. (Both
running in .Net Framework 3.5). The "unmanaged" code was faster but it was
in the order of microseconds, over thousands of transactions. Anything
accessing a database (or even indexed files) is going to spend more time
waiting on IO than it is burning processor cycles.

The whole point about the networked environment is that it is scalable. You
can add new (faster) processors and implement load levelling if you are
seriously concerned about performance. Even if COBOL gave SIGNIFICANTLY
improved performance, that still wouldn't swing it for me. It costs too much
and I have options which were not available in the last century. (I would
have jumped at Open COBOL if it supported COM and OO... but that ship is
sailing and it is probably too late now, even if they came up with it.

I'm happy with using C# and I'm more productive with it than I ever was in
COBOL.)

>While that may not mean much for the individual or small
> user, it can make a difference to large enterprises in the cost
> of hardware to run C# or Java.

That's an issue with the Framework (.Net or JVM) rather than the languages.

Large enterprises are already using networks so mostly it is a case of
upgrading/extending their servers. If you measure the kind of server farm
you can buy for the cost of a mainframe, making hardware choices is not that
difficult.

>
> [...]
>>>> Please take a look at:
>>>>
>>>> http://primacomputing.co.nz/primametro/demosandtutorials.aspx
>>>>
>>>> and click on the tile for "Salvaging COBOL"
>>
>> As noted above, I'll happily debate any points arising from this
>> presentation, but only if you have watched it first :-)
>
> Then, happily debate why you used 'flat files' instead of
> 'indexed files', as noted above. <g>

No debate, it should have been "indexed files". I used "flat files" in the
generic sense of a non-database. A "loose use" if you like.

In a 28 minute presentation, if that was the only issue you had, I'm very
happy... :-)

Thanks for watching it and your feedback, which I always respect and value.

[Waldek Hebisch]

Pete Dashwood <dash...@removethis.enternet.co.nz> wrote:

> Bill Gunshannon wrote:
> >
> > Not sure I would say most. I certainly don't and a lot of my peers
> > share my undersdtanding of programming and softwarfe engineering.
> > Pick the right tool for the job. And sometimes (not always) that
> > tool is COBOL.
>
> Mostly, and certainly for a networked environment, it isn't.
>
> If you want to argue this, my position is clear from the presentation quoted
> earlier. (and the link below)
>

<snip>

> I don't think OO COBOL is a good long term solution. (And I have come to
> that conclusion after using it for around 15 years.) Not because I don't
> think it is well implemented; I think the extension of COBOL to support OO
> constructs is one of the finest feats of software engineeering I have ever
> seen. Unfortunately (for COBOL), the OO languages support OO better, so if
> you are working with that paradigm, COBOL is NOT the best tool for the job.
>
> Around about now, a lot of guys who moved to .NET COBOL compilers are
> beginning to realize that they could do their job better in a different
> language. They turned the learning curve on OO and are starting to realize
> that using COBOL in that environment is tiresome, takes longer to write and
> maintain, and is not a good solution. (However, it is better than NO
> solution...)
>
> Meanwhile, their management are starting to wake up to the fact that COBOL
> is EXPENSIVE, and compilers like C# and JAVA are FREE. Why would you opt for
> a development tool which requires you to pay an "up front fee" to buy it, an
> "ongoing fee" for support and maintenance, and a "run time fee" for
> everything you build with it, when you can download C# for free, get instant
> tuition, support, and code samples for free, and pay NO fees to anyone for
> what you build with it? The ONLY reason for retaining COBOL is because you
> are working in an environment where the procedural paradigm is still king.

Actually, if you try to write procedural code in Java or C# you
will see that they are much better languages for _procedural_
code. Of course, object orientation means that there is some
amount of "object boilerplate" when you want purely procedural
code. But this boilerplate is nothing compared to Cobol
verbosity. And you get good support for function/procedure
calls, local variables, structured programming constructs.
No warts like periods or "section versus paragraphs" problem.

In fact, popular OO languages are build around good procedural
core. The weak part of OO Cobol is its procedural core.
.Net main contribution is that .Net was designed to allow
easy migration _to_ C#. In traditional Cobol enviroments
frequently there was little sensible alternative to Cobol,
so sticking to it made sense.

Of course Cobol "can do the work" for a lot of tasks. Other
languages typically will do the same better (giving more
readable code and needing less effort for programming).
In the past reusing legacy code and good vendor support
could compensate Cobol disadvantages. But vendor limit
their Cobol support so the only remaining Cobol
advantage is legacy code...

I think that open source codes give quite strong indication
that Cobol is rarely good. Namely, in open source project
typically developers choose which language they will use.
Of course choice is biased towards languages know to
developers. But otherwise choice is mostly on technical
merits (sometimes developers just want to try new language).
And a lot of languages are used, in particular some quite
exotic ones. Yet I did not see _any_ serious open
source project written in Cobol...

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Pete Dashwood]

Maybe you should check their web site. I believe there HAVE been some
commercial successes with OpenCOBOL, but I'm not sure how "big" these
implementations are.

I found your post very interesting and some of the points about using OO
languages for procedural processing were thngs I had not considered. (Having
had a COBOL background, I automatically think of COBOL when it comes to
non-OO style processing...)

I'm not sure I completely agree that non-COBOL code is more "readable"; I
think it depends on the COBOL and who is trying to read it :-)

BUT, I would definitely agree that languages like C# and Java are much
"crisper" and achieve more with fewer lines of code than the same job done
in COBOL. That makes it quicker and easier to maintain (there is less of it
to wade through).

As far as COBOL for legacy, you probably know that my main interest
regarding COBOL currently is in salvaging legacy and ensuring it can run
well in the .Net environment. This usually means making legacy code what I
call "object aware" (we don't convert it to true OO Classes, but we do
enable it to use objects, and we automatically refactor all of the legacy IO
into invokes of object methods in a separate Data Access Layer.) I have
spent the last 6 years investigating this, thinking about it, and developing
tools to automate the process with. I'm pretty happy with the approach we
use now (and so, thankfully, are our clients... :-))

I was pressed by various people to add a "Testimonials" page to the new web
site. It is kind of ingrained in the Kiwi culture I grew up in not to wave
the banner for the things you do (we accept 'outstanding' as 'normal'
here... :-)) but I have to admit, whenever I have a bad day I go and look at
some of the very kind things people have said about our dealing with COBOL,
and it cheers me up no end... :-)

http://primacomputing.co.nz/PRIMAMetro/testimonials.aspx

Thanks for an interesting and thought provoking post, Waldek