Cobol - Could this save COBOL?

Author

Could this save COBOL?

Pete Dashwood

2006-09-04, 6:55 pm

I have been looking more closely at Fujitsu COBOL for .Net.

This is really an excellent product (on paper; I haven't tried it yet...)
and adds OO COBOL to the Visual Studio IDE so that a developer can use any
of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
COBOL has all the same benefits (editor, automatic build tracking, version
control, project organisation, full debugging facilities) that the other
languages enjoy and you can mix and match, developing classes (or .NET
components) in any of these languages.

It would be fairly easy to 'refactor' existing COBOL code for mainframe
using this environment and Fujitsu are also offering a CICS converter.

So, why would people not use it?

The main obstacles I see are as follows:

1. The mainframe sites are not into OO. The Dot NET environment is all
about using Dot NET classes and objects and many IT Managers are going to be
wary of upskilling their people, even though this is an ideal growth path
for traditional mainframe programmers.

2. The product is not cheap. That means that small software houses and
independents won't get the chance to experiment with it, or discover the
full benefits of it. (The free trial is for 5 days, not anywhere near long
enough to evaluate all the facilities offered. I believe it can be extended
by agreement with Fujitsu but that would be decidedly dodgy ground, in my
opinion)

3. Fujitsu support has established itself as being abysmal. One would hope
that with this product, that would be remedied and addressed, but it remains
to be seen.

4. Service Oriented Architecture (which this product provides excellent
support for) is still a mystery on mainframe sites where traditional COBOL
is still in use. The 'smart' people who are getting into this, tend to be
'Non-microSoft' users and, for them, Dot NET is of little interest anyway.
(IBM's approach is primarily via Java servlets). Yet, SOA can be implemented
very well in a Dot NET environment, and this product is ideal for doing just
that.

In the final analysis, it comes down to whether COBOL is still considered to
be viable. I'm re-evaluating this. Certainly OO COBOL can be used just as
easily as any other language, but the people who you might expect to use it,
don't want to...:-)

I still believe that COBOL as the only game in town is finished. But
products like Fujitsu's Net COBOL for Dot NET could possibly allow it to be
reinvented as a tool for refactoring existing code and for building SOAs
from existing systems. I understand that MicroFocus are providing a similar
product also, but I don't know the details.

Both companies must believe there is a hopeful market for it. If there
isn't, then they will sustain considerable losses. (The R & D could not have
been cheap...)

What do you guys think?

A. COBOL will continue as it always has, being procedural code with source
code maintained and central to all development.

B. Companies will stop ALL IT development (including COBOL) and simply use
packages, or outsource. The IT department is really just Network management,
with network nerds making sure the network stays up so people can share
spreadsheets, databases, and email, and rolling out new operating systems
when required. No inhouse development.

C. OO COBOL will be used to refactor existing source code into reusable
components. Probably as the basis for a SOA.

D. Existing systems written in COBOL will simply be replaced over time.
In-house support for COBOL will be dropped.

D. COBOL will have some other role, not described above.

Pete.

Douglas Gallant

2006-09-04, 9:55 pm

Answering your last question first (and ignoring the fact that you have two
option D's <g> ), direction in my shop seems to be your first D, just age out
the applications and replace with non-COBOL. The project I'm working on now
intends to replace the two major COBOL apps that we support and replace them
with a Java framework application. I also see a progression towrds B with
more outsourcing but it's mostly a people issue. (Note-I work for a State
government agency so we may have a few unique characteristics, in particular
the difficulties in recruiting ANY new programmers coupled with existing
workforce retirements. Can't rule out political motivations either.) I will
also add that SOA does not require (neccesarily) OO programming although we
could sink into other debates as to what exactly is SOA.

As for your comments on Fujitsu .NET I have to say that I have never worked
with the product. However, I have tinkered with Micro Focus' NetExpress for
..Net so there may be some commonality. My personal feeling was that the
transition to OO COBOL was going to be a little jarring. Although I
understand OO principles and have written VB.NET apps, getting the hang of
the OO COBOL syntax was not easy. There is also the odd aspect that if I
didn't already know OO COBOL, that trying to learn it rather than VB.NET or
C# for new development seems counterproductive, especially since there seems
to be little demand for OO COBOL skills compared to other .NET language
skills. In other words, if I already knew another .NET language then I saw
little benefit in dragging COBOL with me. (And I LIKE COBOL!)
The exception to this, and something we were interested in doing, was
rehosting existing procedural COBOL logic (especially subroutines) into .NET
components. Using the MF tools there were a couple of ways to accomplish it
but neither were quite what we had in mind. MF did plan to (and perhaps
already has, my eval was awhile ago) extend the Interface Mapping Toolkit to
support mapping procedural COBOL linkage sections with a .NET object
interface. That would have fit the bill at least in theory.

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m3tcaF4ec3fU1@individual.net...
>I have been looking more closely at Fujitsu COBOL for .Net.
>
> This is really an excellent product (on paper; I haven't tried it yet...)
> and adds OO COBOL to the Visual Studio IDE so that a developer can use any
> of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
> COBOL has all the same benefits (editor, automatic build tracking, version
> control, project organisation, full debugging facilities) that the other
> languages enjoy and you can mix and match, developing classes (or .NET
> components) in any of these languages.
>
> It would be fairly easy to 'refactor' existing COBOL code for mainframe
> using this environment and Fujitsu are also offering a CICS converter.
>
> So, why would people not use it?
>
> The main obstacles I see are as follows:
>
> 1. The mainframe sites are not into OO. The Dot NET environment is all
> about using Dot NET classes and objects and many IT Managers are going to
> be wary of upskilling their people, even though this is an ideal growth
> path for traditional mainframe programmers.
>
> 2. The product is not cheap. That means that small software houses and
> independents won't get the chance to experiment with it, or discover the
> full benefits of it. (The free trial is for 5 days, not anywhere near long
> enough to evaluate all the facilities offered. I believe it can be
> extended by agreement with Fujitsu but that would be decidedly dodgy
> ground, in my opinion)
>
> 3. Fujitsu support has established itself as being abysmal. One would hope
> that with this product, that would be remedied and addressed, but it
> remains to be seen.
>
> 4. Service Oriented Architecture (which this product provides excellent
> support for) is still a mystery on mainframe sites where traditional COBOL
> is still in use. The 'smart' people who are getting into this, tend to be
> 'Non-microSoft' users and, for them, Dot NET is of little interest anyway.
> (IBM's approach is primarily via Java servlets). Yet, SOA can be
> implemented very well in a Dot NET environment, and this product is ideal
> for doing just that.
>
> In the final analysis, it comes down to whether COBOL is still considered
> to be viable. I'm re-evaluating this. Certainly OO COBOL can be used just
> as easily as any other language, but the people who you might expect to
> use it, don't want to...:-)
>
> I still believe that COBOL as the only game in town is finished. But
> products like Fujitsu's Net COBOL for Dot NET could possibly allow it to
> be reinvented as a tool for refactoring existing code and for building
> SOAs from existing systems. I understand that MicroFocus are providing a
> similar product also, but I don't know the details.
>
> Both companies must believe there is a hopeful market for it. If there
> isn't, then they will sustain considerable losses. (The R & D could not
> have been cheap...)
>
> What do you guys think?
>
> A. COBOL will continue as it always has, being procedural code with source
> code maintained and central to all development.
>
> B. Companies will stop ALL IT development (including COBOL) and simply use
> packages, or outsource. The IT department is really just Network
> management, with network nerds making sure the network stays up so people
> can share spreadsheets, databases, and email, and rolling out new
> operating systems when required. No inhouse development.
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.
>
> D. COBOL will have some other role, not described above.
>
> Pete.
>
>
>
>
>
>

2006-09-05, 3:55 am

In article <4m3tcaF4ec3fU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>I have been looking more closely at Fujitsu COBOL for .Net.

[snip]

>What do you guys think?

I can barely speak for *myself*, let alone for others... but if I were
much good at predicting the future I'd make my living in the stockmarket.

(At present I do *not* make my living in the stockmarket... and, in fact,
by making simple 'mental investments' ('Hmmmmm... that looks good, let me
make a mark that I've bought (n) shares of Widgetco at price (US$y)') it
seems as though I can cause a worldwide recession.

DD

Pete Dashwood

2006-09-05, 7:55 am

Thanks for an interesting and informative response, Douglas.

Comments below...

"Douglas Gallant" <no@spam.net> wrote in message
news:PN5Lg.36283$uH6.3224@twister.nyroc.rr.com...
> Answering your last question first (and ignoring the fact that you have
> two option D's <g> ),

Sorry, it was a typo... let's call that option E... :-)

> direction in my shop seems to be your first D, just age out the
> applications and replace with non-COBOL.

Interesting. I don't know any places that are doing that, but it doesn't
surprise me.

>The project I'm working on now intends to replace the two major COBOL apps
>that we support and replace them with a Java framework application.

Are they using Open Source or is this a MS shop?

> I also see a progression towrds B with more outsourcing but it's mostly a
> people issue.

Yes, I see companies here doing that as well.

> (Note-I work for a State government agency so we may have a few unique
> characteristics, in particular the difficulties in recruiting ANY new
> programmers coupled with existing workforce retirements. Can't rule out
> political motivations either.) I will also add that SOA does not require
> (neccesarily) OO programming although we could sink into other debates as
> to what exactly is SOA.

Sure. Let's leave that aside for now.

>
> As for your comments on Fujitsu .NET I have to say that I have never
> worked with the product. However, I have tinkered with Micro Focus'
> NetExpress for .Net so there may be some commonality. My personal feeling
> was that the transition to OO COBOL was going to be a little jarring.
> Although I understand OO principles and have written VB.NET apps, getting
> the hang of the OO COBOL syntax was not easy.

Yes, I found the same problem when I first started using it. I gave up and
learned Java instead. Then went back to OO COBOL and it all seemed to fall
into place miraculously. :-) I think it is about concepts. Syntax can be
learned in ANY language (evenAPL, if you have a few billion brain cells to
spare and don't have a girl friend or a life... :-))

>There is also the odd aspect that if I didn't already know OO COBOL, that
>trying to learn it rather than VB.NET or C# for new development seems
>counterproductive, especially since there seems to be little demand for OO
>COBOL skills compared to other .NET language skills.
See, this raises a very important point. Should we, as programmers, learn a
language primarily because it is a marketable skill, or because we think it
might be useful for the work we need to do?

Obviously, most people want to be as marketable as possible, so they have a
good eye in this direction.

Nothing wrong with that.

I have been using Visual Studio to put apps together and this means mainly
VB or C# (I just can't warm to C++; in some ways it seems limited and
clunky...just a personal thing :-)) I haven't invested a lot of time in
learning C# and won't until its future is quite clear. But COBOL, given a
level playing field in the Dot NET arena, could be very useful. Especially
as I have a large investment in it already...

>In other words, if I already knew another .NET language then I saw little
>benefit in dragging COBOL with me. (And I LIKE COBOL!)

Yep, I completely understand and agree. But I'm realising there are times
when it would be good to have COBOL in the playground and playing nicely
with the other kids... :-)

> The exception to this, and something we were interested in doing, was
> rehosting existing procedural COBOL logic (especially subroutines) into
> .NET components. Using the MF tools there were a couple of ways to
> accomplish it but neither were quite what we had in mind. MF did plan to
> (and perhaps already has, my eval was awhile ago) extend the Interface
> Mapping Toolkit to support mapping procedural COBOL linkage sections with
> a .NET object interface. That would have fit the bill at least in theory.
>
Fujitsu is very strong in this area and makes it pretty simple. I especially
like their SOA interface. You can create a NET object from your old COBOL,
then wrap it as a Web Service, just by selecting options... pretty

really.

>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4m3tcaF4ec3fU1@individual.net...

Thanks for the insight into what's happening where you are,

Pete.

[color=darkred]
>
>

Pete Dashwood

2006-09-05, 7:55 am

<docdwarf@panix.com> wrote in message news:edjfhe$6ri$1@reader2.panix.com...
> In article <4m3tcaF4ec3fU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> [snip]
>
>
> I can barely speak for *myself*, let alone for others... but if I were
> much good at predicting the future I'd make my living in the stockmarket.

So what about the present? Is anyone talking about any of the options laid
out...?

>
> (At present I do *not* make my living in the stockmarket... and, in fact,
> by making simple 'mental investments' ('Hmmmmm... that looks good, let me
> make a mark that I've bought (n) shares of Widgetco at price (US$y)') it
> seems as though I can cause a worldwide recession.

At least in your own mind, Doc... :-)

Pete.

2006-09-05, 7:55 am

In article <4m559aF47ocgU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:edjfhe$6ri$1@reader2.panix.com...
>
>So what about the present?

Hmmmm... at present I'm waiting for the tea to get done steeping so that I
might have a fresh cup of Bai Mu Dan.

>Is anyone talking about any of the options laid
>out...?

I try not to eavesdrop... but, most likely, someone, somewhere is doing
that, aye.

>
>
>At least in your own mind, Doc... :-)

I'm not sure where 'seeming' exists outside of any mind, Mr Dashwood.

DD

Thane

2006-09-05, 7:55 am

Douglas Gallant wrote:
>
> As for your comments on Fujitsu .NET I have to say that I have never worked
> with the product. However, I have tinkered with Micro Focus' NetExpress for
> .Net so there may be some commonality. My personal feeling was that the
> transition to OO COBOL was going to be a little jarring.

There is no requirement - with the Fujitsu or the Micro Focus product
offerings for .NET, to use or utilize OO syntax or constructs.
Traditional COBOL programs can be compiled and used with the offerings
without refactoring or a change in syntax or adoption of OO.

Michael Wojcik

2006-09-05, 6:55 pm

In article <4m3tcaF4ec3fU1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> writes:
>
> This is really an excellent product (on paper; I haven't tried it yet...)
> and adds OO COBOL to the Visual Studio IDE so that a developer can use any
> of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
> COBOL has all the same benefits (editor, automatic build tracking, version
> control, project organisation, full debugging facilities) that the other
> languages enjoy and you can mix and match, developing classes (or .NET
> components) in any of these languages.

If I may toss in an interested metastasis: Micro Focus Net Express
for .NET, and the upcoming Micro Focus Studio, also provide an OO
COBOL as a first-class .NET language with Visual Studio integration.

--
Michael Wojcik michael.wojcik@microfocus.com

Even 300 years later, you should plan it in detail, when it comes to your
summer vacation. -- Pizzicato Five

Oliver Wong

2006-09-05, 6:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m3tcaF4ec3fU1@individual.net...
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.

I've seen a project where the environment around the COBOL app is
emulated, so that the COBOL program thinks it's running as intended, but
actually it's providing the backbone for a SOA web app: A lot of
screen-scrapping is done, and the output from COBOL is parsed and
transformed into HTML or XML as appropriate; Access to files is intercepted
and transformed into returning hardcoded string values, or connections to
remote databases, etc.

I assume they're going through all this trouble because the original
source code is lost or something.

- Oliver

Clark F Morris

2006-09-05, 6:55 pm

On Tue, 05 Sep 2006 16:28:54 GMT, "Oliver Wong" <owong@castortech.com>
wrote:

>
>"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
>news:4m3tcaF4ec3fU1@individual.net...
>
> I've seen a project where the environment around the COBOL app is
>emulated, so that the COBOL program thinks it's running as intended, but
>actually it's providing the backbone for a SOA web app: A lot of
>screen-scrapping is done, and the output from COBOL is parsed and
>transformed into HTML or XML as appropriate; Access to files is intercepted
>and transformed into returning hardcoded string values, or connections to
>remote databases, etc.
>
> I assume they're going through all this trouble because the original
>source code is lost or something.

Probably it is considered easier to work with known screen and use
language or tool du jour. Another explanation might be that the
program is communicating with both old world (CICS, IMS-DC, etc.) and
the web. Opening up programs can be interesting.
>
> - Oliver

Michael Russell

2006-09-05, 6:55 pm

Pete Dashwood wrote:

imho, nothing, but nothing can or will save Cobol.
It'll wither on the vine & no-one will particularly miss it
during their day job.

It's not being taught in college / university; new recruits
will quite reasonably balk at the idea of learning this old
language, too.

Yes, there are still 'trillions' of lines of Cobol source out
there, but less trillions than there used to be; a trend that's
not going to reverse.

If only there were a 'nice' language out there - just one
major, straightforward, popular language ... you know, as Cobol
used to be!

Regards

Michael

>...)
>
> What do you guys think?
>
> A. COBOL will continue as it always has, being procedural code with source
> code maintained and central to all development.
>
> B. Companies will stop ALL IT development (including COBOL) and simply use
> packages, or outsource. The IT department is really just Network management,
> with network nerds making sure the network stays up so people can share
> spreadsheets, databases, and email, and rolling out new operating systems
> when required. No inhouse development.
>
> C. OO COBOL will be used to refactor existing source code into reusable
> components. Probably as the basis for a SOA.
>
> D. Existing systems written in COBOL will simply be replaced over time.
> In-house support for COBOL will be dropped.
>
> D. COBOL will have some other role, not described above.
>
> Pete.

Oliver Wong

2006-09-05, 6:55 pm

"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:geGdnRHjTuCvVmDZnZ2dnUVZ8tadnZ2d@pi
pex.net...
>
> imho, nothing, but nothing can or will save Cobol.
> It'll wither on the vine & no-one will particularly miss it during their
> day job.
>
> It's not being taught in college / university; new recruits will quite
> reasonably balk at the idea of learning this old language, too.

Actually, I did some job interviews a while back. One of the applicants
was still in university, and had done some COBOL there. Maybe they're
foreseeing a excess of demand and a lack of supply of COBOL programmer in
the next few years.

- Oliver

Roger While

2006-09-05, 6:55 pm

See :http://www.csis.ul.ie/cobol/

University of Limerick.

"Oliver Wong" <owong@castortech.com> schrieb im Newsbeitrag
news:LKkLg.5809$0k7.5366@clgrps13...
>
> "Michael Russell" <Michael.Russell@msn.com> wrote in message
> news:geGdnRHjTuCvVmDZnZ2dnUVZ8tadnZ2d@pi
pex.net...
>
> Actually, I did some job interviews a while back. One of the applicants
> was still in university, and had done some COBOL there. Maybe they're
> foreseeing a excess of demand and a lack of supply of COBOL programmer in
> the next few years.
>
> - Oliver

Michael Russell

2006-09-05, 6:55 pm

Oh, Limerick! That's alright, then! ;-)

Seriously though, there can't be much of a percentage of
institutions offering Cobol .... and you need a degree nowadays
to start a coding job ....

Seems pretty clear cut to me.

Regards

Michael

Michael
Roger While wrote:
> See :http://www.csis.ul.ie/cobol/
>
> University of Limerick.
>
>
> "Oliver Wong" <owong@castortech.com> schrieb im Newsbeitrag
> news:LKkLg.5809$0k7.5366@clgrps13...
>
>

James J. Gavan

2006-09-05, 6:55 pm

Roger While wrote:
> See :http://www.csis.ul.ie/cobol/
>
> University of Limerick.

Whats' the significance of the reference to U. of L., Roger ?

Thane's discussion group back in 2000 had a participant from Limerick,
(how quickly you can forget names !), who learned COBOL and did his
thesis on OO. BUT - he told us back then that Michael Coughlan,
responsible for the notes and examples you refer to, had lost out - U,
of L. no longer teaches COBOL. (Doesn't show dates in Michael's source,
but I bet he wrote his examples back in the early to mid-90's, probably
using VISOC or the earliest version of Net Express). A bit confusing,
because his tutorial summary shows that he updated some entries as of
2002 - but I think the original, "they don't teach COBOL anymore at U.
of L.", still holds true.

Similarly another Brit (Michael Turk ?) teaching COBOL in Eastern
Australia, also lost out. His university no longer teaches COBOL. Will
Price had a loyal following of COBOLers, (for OO), in the U.S. academic
world - but their institutions progressively switched to the language du
jour.

Obviously there are still institutions in the States teaching COBOL -
one came up just the other day in the M/F Forum - young lady asking why
her examples keyed in from a textbook and using N/E University Edition
couldn't be located at runtime. Plus of course we have had other
examples here of newbies asking for help.

The last holdout here in Alberta (population in excess of 2.5 million
now - Calgary just a couple of w

s back hit its own million mark), was
de Vry Institute - gave up about a year or more ago. However I believe
de Vry still teaches COBOL in Chicago.

Jimmy
>
>
> "Oliver Wong" <owong@castortech.com> schrieb im Newsbeitrag
> news:LKkLg.5809$0k7.5366@clgrps13...
>
>
>
>

2006-09-05, 6:55 pm

In article <geGdnRHjTuCvVmDZnZ2dnUVZ8tadnZ2d@pipex.net>,
Michael Russell <Michael.Russell@msn.com> wrote:
>Pete Dashwood wrote:
>
>imho, nothing, but nothing can or will save Cobol.
>It'll wither on the vine & no-one will particularly miss it
>during their day job.

From
<http://groups.google.com/group/comp...de=source&hl=en>

--begin quoted text:

I don't remember where I first read it or to whom I should attribute it
but the statement was something along the lines of 'I was told to learn
new stuff because COBOL was a dying language and would soon be replaced.
The next w

I was told that Neil Armstrong had walked on the moon.'

--end quoted text

DD

William M. Klein

2006-09-05, 6:55 pm

Replying (but snipping all of Pete's original post)

Besides Fujitsu and Micro Focus, I know at least one (and possibly two) projects
to create NEW ".NET" COBOL products.

Personally, I am not at all certain whether relying on .NET is a "good" thing
(any more than relying on IBM mainframe architecture in the '70s was). Yes, it
is pretty (very) common today, but do you want to plan on it "always" being
there?

I understand there is a .NET (look-alike?) for Linux - but I hear very little
about it.

***

I guess my questions/comments are:

1) Why should the "interface" language be the same as the "business logic"
language? I think COBOL remains viable for the latter - whether the former is
done in COBOL or not.

2) Pete (and others) keep on talking about "components" and purchased software.
Someone SOMEWHERE must be creating those - in some language. Is (or will) COBOL
be part of this? For some "traditional" type applications, it is hard for me to
believe that COBOL based systems won't remain a player.

3) IBM mainframes will retain COBOL (just as they do Assembler) applications for
as long as business computing is done on them. Yes, they are "great servers" -
but they also continue to do LOTS of "data processing" (back-end or whatever).

4) I wish I understood the "perception" of C++, Java, .NET (C#) and other
"semi-common" environments/tools. I see COBOL in a "niche" position in the
future, and its future will depend upon how well it works with each (and all) of
the more common (for the specific environment) "tools".

***

P.S. for those who want to be "amused" by a related thread, you might want to
check out the current comp.lang.pl1 threads on OOP and PL/I.

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

charles hottel

2006-09-05, 9:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m555kF4i31mU1@individual.net...
> Thanks for an interesting and informative response, Douglas.
>
> Comments below...
>
<snip>

> Yes, I found the same problem when I first started using it. I gave up and
> learned Java instead. Then went back to OO COBOL and it all seemed to fall
> into place miraculously. :-) I think it is about concepts. Syntax can be
> learned in ANY language (evenAPL, if you have a few billion brain cells
> to spare and don't have a girl friend or a life... :-))
>

I recently had a similiar experience. After learning a lot about Java I
re-read some OO COBOL and found it much, much easier to understand and I
found myself noticing a lot more of the little subtle points. For me it
was not as much about concepts as much as having actual experience with
using the concepts. Putting it another way, for me, actual experience
helped me to to pick up on the little things that I would tend to not notice
by simply reading. Given how much I remember struggling with OOCOBOL I was
very surprised to now find it so much easier to understand. Of course I
still think part of my problem stemmed from having sleep apnea. Well it is
great to have an early 1990's understanding of OO concepts and programming
at last. I still need to learn much more about Java and design patterns and
building components and etc. but now it no longer seems to be beyond my
reach.

<snip>

Price is a major show stopper for me personally although I suppose it is
less so for companies. Likewise the reports of poor support and liscense
fees. Because of this I have pursued Java and while I find some of its
language features less convenient than the COBOL ways that I am more
familiar with, it does have some advantages in other areas. At one time I
thought I would make a lot of powerful programs and algorithms available in
COBOL as a way of promoting my favorite language. A lot of these programs
and algorithms were in C or C-like languages and translating them to COBOL
is definitly more of a challenge than doing it in Java.

<snip<
[color=darkred]

I think if COBOL people were going to make the change over to OOCOBOL they
would have do it by now or the would have at least made more of a start by
now.
[color=darkred]

Companies that can do their business this way certainly will. I work for the
federal government and in my experience the feds often have a lot of unique
requirements that will not be met this way. For example there is a lot of
demand for canned payroll and personnel apps but I think you would be hard
pressed to find one that supports reemployeed annuitants. Sure they might
provide it for the right price but the general product will not have it
because only the feds are interested in having it. They may support 401 k
programs but how many support civil service retirement system or the federal
employeee retirement system. A lot of companies are going to SAP and at my
agency they are going through a lot of contortions to try and use SAP for
some applications. Some ar easy to do with SAP. Others, well it is
premature at this point to judge it but they are facing some real challenges
in both providing complete functionality and also in the performance area.
Canned apps are great when they do everything that you want but if you end
up fighting them to do what you want it can be harder than simply
programming what you want. All canned apps seem to have a model of how the
world should work and if your world fits the model then you love them. Some
companies change what they are willing to accept and adapt to the model of
the canned app but government is mandated by law to do some things and can
find it very difficult to change their views of the world.
[color=darkred]

Perhaps but it seems to be very slow in coming to the mainframes in my
corner of the world. Other corners of the worls seem to be embracing ths
option though.
[color=darkred]

A lot of companies will do this but who can know the percentages for the
various categories? This seems to be a trend in some areas but companies
with a very large investment in COBOL seem to be embracing the new stuff
that they find useful and finding way to inteface their COBOL programs or
legacy (I hate that word) data to the new stuff, but I guess that is option
C.

I think all of the outsourcing of jobs overseas is influencing this option.
I have read a lot of articles lately advising IT people to not be coders but
instead to become project managers. But some people like me do not want to
manage and prefer to write programs and develop new algorithms. I feel
fortunate that I was able to make a good career doing what I like to do, but
I would hesitate to recommend it wholeheartedly to someone just starting
out.

[color=darkred]
>
> Thanks for the insight into what's happening where you are,
>
> Pete.
>

Bottom line, given your previous experience with OO and components, if you
can afford it and live with the known shortcomings, then why not go for it?
Despite all my protestation about the price I often think about taking this
approach myself, but for now reason says to keep on the Java trail until I
learn to be as comfortable with it as I now am with COBOL.

Pete Dashwood

2006-09-05, 9:55 pm

"Thane" <thaneh@softwaresimple.com> wrote in message
news:1157464523.766912.288590@i3g2000cwc.googlegroups.com...
>
> Douglas Gallant wrote:
>
> There is no requirement - with the Fujitsu or the Micro Focus product
> offerings for .NET, to use or utilize OO syntax or constructs.
> Traditional COBOL programs can be compiled and used with the offerings
> without refactoring or a change in syntax or adoption of OO.
>
OK. So how would you utilise Dot Net Classes and functions?

If you are going to use Dot NET simply as a vehicle for ancient procedural
code you might as well NOT make a transition to Dot Net at all.

If the products can leverage the underlying OO nature of the Dot NET
environment WITHOUT the user having to learn OO concepts, that MIGHT be of
some use (though personally, I wouldn't advise any company to do it).

PowerCOBOL manages to implement OO without the user necessarily being aware
of it, and this can be a useful learning aid, but that is quite different
from moving to the Dot NET framework.

Given your Fujitsu connections, Thane, perhaps you could post some
procedural code that would show how Dot NET functions can be accessed from
standard COBOL using the Fujitsu compiler. (I understand it has some
extensions to support Dot NET)? If this is not possible, then could you give
your reasons as to why you see moving to Dot NET being valuable for legacy
code that will not utilise the environment available?

I see this product as enabling traditional COBOL people to move into OO and
leverage their existing skills into the 21st century. For myself, I will
happily write stuff in any of the available languages that are supported in
the Visual Studio environment, but having COBOL there too, is an attractive
proposition. (Java is also very useful, but, as far as I know, VS doesn't
support it...)

To me it seems tragic to simply drag the legacy of the last 50 years into a
new environment that differs fundamentally and conceptually from that
legacy. I would rather COBOL died gracefully than see that happen. If you
disagree, please show your arguments.

Pete.

Pete Dashwood

2006-09-05, 9:55 pm

<docdwarf@panix.com> wrote in message news:edl10q$d6t$1@reader2.panix.com...
> In article <geGdnRHjTuCvVmDZnZ2dnUVZ8tadnZ2d@pipex.net>,
> Michael Russell <Michael.Russell@msn.com> wrote:
>
> From
> <http://groups.google.com/group/comp...de=source&hl=en>
>
> --begin quoted text:
>
> I don't remember where I first read it or to whom I should attribute it
> but the statement was something along the lines of 'I was told to learn
> new stuff because COBOL was a dying language and would soon be replaced.
> The next w

I was told that Neil Armstrong had walked on the moon.'
>
> --end quoted text
>
> DD

Supposing the admonition had been to learn new stuff, NOT because COBOL was
dying or would soon be replaced, but because of all the following reasons:

1. The more skills you have, the better chance there is of selling them.
2. The more tools in your toolbox, the better chance of finishing the
problem quickly, with consequently less stress around deadlines.
3. Updating your skill set is good for personal growth.
4. Eliminate anxiety just in case anything happens to COBOL. (Even if this
seems extremely unlikely...)
5. New technologies and methodologies may require approaches that are not
easily implemented in COBOL.

Would that have made any difference as to whether you learned Java, or
Scripting, or VB, or anything else, or not?

Pete.

Pete Dashwood

2006-09-05, 9:55 pm

Good response, Bill. Thoughtful and wise, as always... :-)

Comments below...

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Q4oLg.122156$TP1.50024@fe04.news.easynews.com...
> Replying (but snipping all of Pete's original post)
>
> Besides Fujitsu and Micro Focus, I know at least one (and possibly two)
> projects to create NEW ".NET" COBOL products.
>
Can you say whether these are commercial corporations (profit motivated),
open source (enthusiast motivated), or maybe personal projects from a given
individual or group of individuals (just as a technical challenge and maybe
for love of COBOL)

> Personally, I am not at all certain whether relying on .NET is a "good"
> thing (any more than relying on IBM mainframe architecture in the '70s
> was). Yes, it is pretty (very) common today, but do you want to plan on
> it "always" being there?

Good point. Dot NET certainly didn't have the initial acceptance that MS may
have hoped for. However, support for it seems to be growing and, on
inspection, it does seem to have some useful advantages (A flat playing
field via the CLR for different languages, being one of them). I completely
agree that RELYING on anytechnical environment is high risk...

I don't think we can plan on ANYTHING ALWAYS being there, but we can
certainly see that something useful (like the 360/370 architecture) is
likely to be around for a while...

My own interest in Dot NET has been stimulated because I am seeing that most
of the component factories are offering Dot NET components and discouraging
use of the older OLE based components. Added to this, the Classes which
underlie Dot NET are the richest MS have ever produced and are even better
than MFC in many regards.

As I still knock out the odd component, I am interested in adding this
capability to my arsenal.
>
> I understand there is a .NET (look-alike?) for Linux - but I hear very
> little about it.
>

Interesting. Maybe someone can comment on that?
> ***
>
> I guess my questions/comments are:
>
> 1) Why should the "interface" language be the same as the "business logic"
> language? I think COBOL remains viable for the latter - whether the
> former is done in COBOL or not.

Unfortunately, it is much more complex than just isolated layers of the
system design. The questions that have to be asked are not about methodology
and technology; they are about the approach to the Business IT solution,
entirely. Procedural "Business logic" hard coded in ANY language may not be
the way to go...

Instead of writing a procedure like...
<procedure for invoice>
(For purposes of argument only...no attempt to be a tech. or functional
spec. :-))
For each Product purchased
Prepare a line on the invoice
place the qty of items, a description of the item, the unit
price, and any discount, into the line
multiply the qty by the unit price, and discount and show the
total in a column at the end of the row
calculate GST/VAT/MWS/Sales Tax at the current going rate, based
on the row total and put it in
another total, adjacent to the total value of the sale.
when all products complete
sum totals of invoice lines and tax and place them in the total boxes
at the foot of the invoice
print the invoice or email it or fax it or whatever...
</procedure for invoice>

You could simply say: "When a sales transaction occurs, instantiate and
populate an invoice object, then print or dispose of it as configured."

Impossible? Science Fiction? Not at all...

Suppose the system "understands" concepts like 'Product', 'Customer',
'Invoice' and 'Account'. These are fundamental system OBJECTS. (You could
think of them as 'concepts', if you like. They contain 'intelligence' in the
form of Properties and Methods (information and behaviours); they react to,
or trigger, Events). It also "understands" transactions like 'Sale',
'Return', 'Payment', 'Credit', and so on. (It does this by having objects
that represent these transactions...)

The 'Invoice' object would know how to display itself. (The actual process
that displayed it might be coded in VB for a Windows desktop display, C# if
it was being emailed via CDONT or SMTP, COBOL if it was being printed,
dynamicially built with server side code in Dot NET ASP/JSP if it was going
to the Web, or whatever. You could use whatever language best suited what
you were developing, and the CLR will see that it all runs WITHOUT requiring
a bunch of different runtimes (some of which you might have to license...)

As long as computer programming is tied to the paradigm of procedural
coding, it will be limited to requiring humans to produce it, using
'computer programming languages' that spell out every detail and are subject
to the innate inaccuracy of human beings.

The Object approach is just the BEGINNING of a better way.

Objects become components and get reused all over the place. Their
behaviours can be extended.

The next step is 'smart' components that observe how they are deployed, and
modify or create their own behaviours accordingly.
(SQL does this in some RDBsystems; how the data is being accessed is stored
and analysed, then appropriate indexes can be added or dropped, clusters can
be moved around, physical reorganization is triggered automatically by the
system to accommodate the most frequently used access paths. 'Smart'
components would work in similar ways...)

By interaction with a human, a 'smart' component can modify its own
behaviour. There is no requirement for the human to be a programmer, or have
knowledge of a programming language; in fact, it is better if they are a
Business Analyst or Business User WITHOUT knowledge of the technology.

>
> 2) Pete (and others) keep on talking about "components" and purchased
> software. Someone SOMEWHERE must be creating those - in some language.
Yes, of course. But not indefinitely. And, for the most part, NOT using
COBOL. (Mainly because it wasn't OO and the whole approach to components
requires OO. I'm not going to get into the old arguments about modular
programming versus OO; they are NOT the same. (There ARE similarities; but a
turkey is 'similar' to an eagle... that doesn't make it one.) I've explained
it here (and elsewhere) so often that I'm truly bored with it... if people
still don't understand the differences or subtleties then they simply don't
want to know, and I am wasting my time.

The point here is that as more components become available there is less
requirement for procedural coding. Eventually, it reaches saturation. Dot
NET provides a HUGE variety of components in the form of rich Classes and
functions. More than we have seen with any OS (or OS extension) before. In
the same way that you don't sit down and write a square root calculation
routine when you have a function that does it, intrinsic to the language,
why would you write an invoice print program, or build a tree view from the
Windows API, or write a customer relationship management system?

> Is (or will) COBOL be part of this? For some "traditional" type
> applications, it is hard for me to believe that COBOL based systems won't
> remain a player.

2015. No more in-house procedural COBOL for new development. I'm hopeful
that OO COBOL will still be around and will have earned its place with the
others. (Although, if the reactions in this newsgroup are anything to go by,
it is not so likely... :-))

COBOL will die when procedural programming dies. Place your own bets as to
when that will be. It isn't about a new program replacing it (like ""The
Last One") It is about Business simply not wanting or needing to develop
computer applications in-house.

"Traditional" type applications (batch, for instance...) will be obviated by
online transaction driven systems of unthinkable power by today's standards.
Why would you run off a million statements or invoices for mailing when
customers don't want them? (They already have the electronic one they got at
the point of sale.) Here in NZ some of the Banks started offering customers
the option of not having snail mailed statements every month. They expected
around 5%...it is over 30% and has been running for just over a year. We do
have full access to our accounts on -line and the Banks will re-instate hard
copy if you want it.)

>
> 3) IBM mainframes will retain COBOL (just as they do Assembler)
> applications for as long as business computing is done on them. Yes, they
> are "great servers" - but they also continue to do LOTS of "data
> processing" (back-end or whatever).

Key here is "as long as business computing is done on them". What happens
when all the 'back end' processing is done on the 'front end' :-)? The only
reason it isn't at the moment is lack of imagination in system design, and
hardware capability. Both of these things are evolving...
>
> 4) I wish I understood the "perception" of C++, Java, .NET (C#) and other
> "semi-common" environments/tools.

I tried to address this to some extent above, Bill, but it is really
impossible in a space as small as this to cover everything.The fundamental
difference is OO. (All three of the above implement it well).

Building 'smart' applications in procedural code may not be impossible, but
it is certainly difficult (I know; I've been trying for decades :-)). Doing
so with OO components is much more viable.

I believe that is where the future lies.

>I see COBOL in a "niche" position in the future, and its future will depend
>upon how well it works with each (and all) of the more common (for the
>specific environment) "tools".

It will be the same niche occupied by Latin in our schools. Why should
people using the tools you mention care whether COBOL works well with them?
Unless it is able to completely interact with them, share classes and
methods, no one will be interested. OO COBOL can do that (it excels at it in
the Dot NET environment); procedural COBOL simply can't.

I believe the only thing likely to save the COBOL language is a really good
implementation of it under Dot NET with full OO capability. Maybe MF and
Fujitsu got it right this time. I hope so.

Pete.

Richard

2006-09-06, 3:55 am

William M. Klein wrote:

> I understand there is a .NET (look-alike?) for Linux - but I hear very little
> about it.

Mono, it is supported by Novell.

Pete Dashwood

2006-09-06, 3:55 am

Hi Charlie, nice to see you are still coming here :-)

Quick comments below...

"charles hottel" <chottel@earthlink.net> wrote in message
news:mcpLg.6696$xQ1.2548@newsread3.news.pas.earthlink.net...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4m555kF4i31mU1@individual.net...
> <snip>
>
>
> I recently had a similiar experience. After learning a lot about Java I
> re-read some OO COBOL and found it much, much easier to understand and I
> found myself noticing a lot more of the little subtle points. For me it
> was not as much about concepts as much as having actual experience with
> using the concepts. Putting it another way, for me, actual experience
> helped me to to pick up on the little things that I would tend to not
> notice by simply reading. Given how much I remember struggling with
> OOCOBOL I was very surprised to now find it so much easier to understand.
> Of course I still think part of my problem stemmed from having sleep
> apnea. Well it is great to have an early 1990's understanding of OO
> concepts and programming at last. I still need to learn much more about
> Java and design patterns and building components and etc. but now it no
> longer seems to be beyond my reach.
>

Excellent! Looks like we enjoyed a similar catharsis :-). Java is really
good for understanding OO and, as you pointed out, there is no real
substitute for hands on experience.

> <snip>
>
>
>
> Price is a major show stopper for me personally although I suppose it is
> less so for companies.

You'd think so, wouldn't you? However, the people who decide about spending
very often have no idea what is being bought. If you have an IT manager who
has his own budget and has some understanding of why such a tool could be
useful, you may have a chance. What often happens instead is that the
purchase has to be approved by someone who hasn't the faintest idea what the
use or purpose of the tool is. As things in IT are currently proceeding OK
and the company isn't going broke, there is no way this tool can be critical
so why buy it?

Unless there is a good committment to OO and OO COBOL and moving to Dot NET,
the decision is not likely to be made. If it was under $200 there would be
no problem; when it is several thousand there is a problem. In effect, from
the vendor's point of view they can sell it once at $3000 or sell it 15
times at $200. In fact, the latter would ensure a much wider base and might
be a better way to go... Companies buy $200 tools all the time and then find
that maybe they aren't exactly what was needed. No-one minds... it was $200
and some experience was gained. At least people could run low risk pilots if
they could get the compiler at a cheaper price.

High prices are a show stopper for all of us, including companies.

> Likewise the reports of poor support and liscense fees.

Support can be addressed, although it is hard to undo a perception once it
has been established.

One example: In Europe in the early 80s FIAT cars were perceived to be rust
buckets. (I had a 124 Sport that was literally falling out from under me
:-)). I decided to get something newer and better, even though mechanically,
it was an excellent motor car. My local FIAT agent in Wimbledon started
extolling the virtues of the new X/19 and I went for a test drive. It was
amazing (took it round the Elephant & Castle in the rain at over
50MPH...never looked like coming unstuck) and I loved it, but I was haunted
by the spectre of their reputation for rust. Then the salesman sprang his
surprise... FIAT had listened and recognized their deserved bad reputation.
The cars were being triple-primed, baked, then all body cavities injected
with wax. They offered a replacement rust warranty for 8 years, that was
transferable if you sold the car!! I bought it. It never rusted. I drove it
around Europe for 80,000 miles, had the time of my life in it and finally
wrecked it in Spain about 5 years later when I was forced off the road... It
could have been repaired, but simply wasn't worth it. I gave it to the
apprentice at the garage which towed it; he would do it in his spare time
and I'll never forget the look on his face when I said he could keep it :-)
I wouldn't mind betting it never rusted ion it's lifetime.

I still occasionally hear people talking about rust in FIATs and I always
tell this story.

Poor support from a software vendor can be countered by ensuring that
support is one of the priorities for the company. Don't fire your knowledge
base because they are expensive. (Sell more software so you can afford
them... :-)) Make sure that inter company communication lines are quick and
effective. If a support person can't solve a problem, make sure the problem
is quickly pooled to other support people and try and get an effective
workaround to the customer while the fix is being developed. Above all,
LISTEN to the customers.

And retain and acknowledge good support people.

License fees have been argued so often and no minds are likely to be
changed. My personal view is that this is a suicidal marketing policy. I
simply wouldn't (and have not) buy any product that used such a model.

> Because of this I have pursued Java and while I find some of its language
> features less convenient than the COBOL ways that I am more familiar with,
> it does have some advantages in other areas. At one time I thought I
> would make a lot of powerful programs and algorithms available in COBOL as
> a way of promoting my favorite language. A lot of these programs and
> algorithms were in C or C-like languages and translating them to COBOL is
> definitly more of a challenge than doing it in Java.

Still, sometimes there is great satisfaction in doing a difficult task,
right :-)?
>
> <snip<
>
>
> I think if COBOL people were going to make the change over to OOCOBOL they
> would have do it by now or the would have at least made more of a start by
> now.

Ouch, that stung...:-) For the last 8 years I have been posting here
advocating that people get into OO... I no longer really care whether they
do or not, but, in line with the topic of this thread, I do believe it could
save COBOL, even at this late hour.

>
>
> Companies that can do their business this way certainly will.

Yes, I have seen a couple recently who are moving this way.

> I work for the federal government and in my experience the feds often have
> a lot of unique requirements that will not be met this way. For example
> there is a lot of demand for canned payroll and personnel apps but I think
> you would be hard pressed to find one that supports reemployeed
> annuitants. Sure they might provide it for the right price but the
> general product will not have it because only the feds are interested in
> having it. They may support 401 k programs but how many support civil
> service retirement system or the federal employeee retirement system. A
> lot of companies are going to SAP and at my agency they are going through
> a lot of contortions to try and use SAP for some applications. Some ar
> easy to do with SAP. Others, well it is premature at this point to judge
> it but they are facing some real challenges in both providing complete
> functionality and also in the performance area. Canned apps are great when
> they do everything that you want but if you end up fighting them to do
> what you want it can be harder than simply programming what you want.

It may still be cheaper than maintaining that programming you did...

> All canned apps seem to have a model of how the world should work and if
> your world fits the model then you love them. Some companies change what
> they are willing to accept and adapt to the model of the canned app but
> government is mandated by law to do some things and can find it very
> difficult to change their views of the world.
>
Yes, I think that is spot on.

>
> Perhaps but it seems to be very slow in coming to the mainframes in my
> corner of the world. Other corners of the worls seem to be embracing ths
> option though.
>
There is a different mentality amongst mainframe programmers. This is
changing though.

>
> A lot of companies will do this but who can know the percentages for the
> various categories? This seems to be a trend in some areas but companies
> with a very large investment in COBOL seem to be embracing the new stuff
> that they find useful and finding way to inteface their COBOL programs or
> legacy (I hate that word) data to the new stuff, but I guess that is
> option C.

Whatever option, it is a sensible thing to do. Anything that extends the
life of existing code should be viewed as useful. However, the time bought
should be used toextend skill sets and re-address development, not sit back
in the status quo and wait for the next crisis.
>
> I think all of the outsourcing of jobs overseas is influencing this
> option. I have read a lot of articles lately advising IT people to not be
> coders but instead to become project managers.

Sorry, I had to smile at that :-) The skill sets required for good project
management are just as complex as those required to learn OO, and they are
not automatically acquired by working for a while as a programmer. Simply
telling people they are a project manager doesn't make them one; any more
than telling a turkey it is an eagle makes it one (see analogy elsewhere in
this thread... :-)) In my case, (although I might be a slow learner...) it
took at least 6 years of practice to become even a half-way decent project
manager; it involved study, thought, and mistakes, both on and off the job.
It was much harder than learning COBOL or Java...

>But some people like me do not want to manage and prefer to write programs
>and develop new algorithms.

Sure. I see nothing wrong in that. Some who DO want to manage really don't
know the stresses and effort it entails... (to do it well, of course; any
idiot can do it poorly, as is all too apparent to many here...:-))

>I feel fortunate that I was able to make a good career doing what I like to
>do, but I would hesitate to recommend it wholeheartedly to someone just
>starting out.
>
Me too. Funny that. I feel the 'glory days' are over... The fun we had
learning on a blank page is being kidnapped by 'Computer Science' and 'Best
Practice'. It is becoming just another dry academic subject turning out
graduates who can't write a three way split but know how to use binary
polynomials for error checking...

(OK, I'm not seriously advocating we should abandon Best Practice or
Computer Science, but it DID use to be fun and a lot of that seems to be
lost nowadays...)

>
>
> Bottom line, given your previous experience with OO and components, if you
> can afford it and live with the known shortcomings, then why not go for
> it? Despite all my protestation about the price I often think about taking
> this approach myself, but for now reason says to keep on the Java trail
> until I learn to be as comfortable with it as I now am with COBOL.
Well, I can afford it I suppose, but I don't usually buy anything computer
related unless I know it will pay for itself. This is a major expenditure
that could mean the difference between a core 2 64bit (merom) dual raid 150
GB 7800 SATA with 4 GB of memory in my next notebook, or something
considerably less classy... :-) (like, maybe half of that :-))

I requested a quote from Fujitsu USA some days ago but have had no response.
Doesn't inspire confidence...

Pete.

Pete Dashwood

2006-09-06, 3:55 am

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1157518270.661262.261630@h48g2000cwc.googlegroups.com...
>
> William M. Klein wrote:
>
>
> Mono, it is supported by Novell.
>
Do you have any first hand experience with it, Richard?

Pete.

Richard

2006-09-06, 3:55 am

Pete Dashwood wrote:

> Do you have any first hand experience with it, Richard?

No.

2006-09-06, 3:55 am

In article <4m6ma5F4l3ujU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:edl10q$d6t$1@reader2.panix.com...
><http://groups.google.com/group/comp...de=source&hl=en>
>
>Supposing the admonition had been to learn new stuff, NOT because COBOL was
>dying or would soon be replaced, but because of all the following reasons:
>
>1. The more skills you have, the better chance there is of selling them.
>2. The more tools in your toolbox, the better chance of finishing the
>problem quickly, with consequently less stress around deadlines.
>3. Updating your skill set is good for personal growth.
>4. Eliminate anxiety just in case anything happens to COBOL. (Even if this
>seems extremely unlikely...)
>5. New technologies and methodologies may require approaches that are not
>easily implemented in COBOL.
>
>Would that have made any difference as to whether you learned Java, or
>Scripting, or VB, or anything else, or not?

Mr Dashwood, curious that you neglected the most common of my motives for
learning something new, i.e. 'It's Fun!'... but as for your question it
falls into a kind of past subjunctive which I've often seen met with a
variation of 'Suppose my Sainted Paternal Grandmother had wheels... that
would have made her a trolley-car.'

DD

Pete Dashwood

2006-09-06, 3:55 am

<docdwarf@panix.com> wrote in message news:edm3lt$bu1$1@reader2.panix.com...
> In article <4m6ma5F4l3ujU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> Mr Dashwood, curious that you neglected the most common of my motives for
> learning something new, i.e. 'It's Fun!'... but as for your question it
> falls into a kind of past subjunctive which I've often seen met with a
> variation of 'Suppose my Sainted Paternal Grandmother had wheels... that
> would have made her a trolley-car.'
>
A stupid answer to a hypothetical question.

Fair enough.

I'll take that as a "No". :-)

Pete
> DD
>

2006-09-06, 3:55 am

In article <4m7im7F4r2hsU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:edm3lt$bu1$1@reader2.panix.com...
>A stupid answer to a hypothetical question.

An answer that point out the hypothetical nature of the question, Mr
Dashwood... and that may, with a bit of diligence, lead to that grand,
old, metha-hypotheticality of 'suppose there were no hypothetical
questions?'

>
>Fair enough.
>
>I'll take that as a "No". :-)

You have my permission, Mr Dashwood, to take it as a suppository, if you
so see fit... and to announce that in public, as well.

(Hmmmm... first time, I believe, I've formulated it that way... think I'll
try to remember that'un.)

DD

Pete Dashwood

2006-09-06, 7:55 am

<docdwarf@panix.com> wrote in message news:edm4sk$3br$1@reader2.panix.com...
> In article <4m7im7F4r2hsU1@individual.net>,
> Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
> An answer that point out the hypothetical nature of the question, Mr
> Dashwood... and that may, with a bit of diligence, lead to that grand,
> old, metha-hypotheticality of 'suppose there were no hypothetical
> questions?'
>
>
> You have my permission, Mr Dashwood, to take it as a suppository, if you
> so see fit... and to announce that in public, as well.
>
No need. It isn't me who's anally retentive..:-)

Pete.

2006-09-06, 6:55 pm

In article <4m81k7F4s62qU1@individual.net>,
Pete Dashwood <dashwood@enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:edm4sk$3br$1@reader2.panix.com...

[snip]
[color=darkred]
> No need. It isn't me who's anally retentive..:-)

Curious, Mr Dashwood, that you see the need to invoke this kind of
diagnosis... but one does what one can, I guess.

DD

Oliver Wong

2006-09-06, 6:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m6t41F4ql1gU1@individual.net...
>

There's the .NET look-alike for Linux, as you mention later on, called
Mono, and Mono is open source. One of the strong arguments for open source
is that even if everyone else in the world abandons it, you always still
have access to the source code and can modify or update it if you need to.
[color=darkred]
>
> Good point. Dot NET certainly didn't have the initial acceptance that MS
> may have hoped for. However, support for it seems to be growing and, on
> inspection, it does seem to have some useful advantages (A flat playing
> field via the CLR for different languages, being one of them). I
> completely agree that RELYING on anytechnical environment is high risk...

The CLR support for different languages is one of the things I admire
the most technologically in the .NET framework. I downloaded a 3rd party
utility that will actually translate code written in any .NET language into
your preferred language .NET, assuming your preferred language is either
VB.NET or C#. I've tried converting VB.NET to C#, and the results were
perfectly readable. I'd be interested in seeing what an OO COBOL targetting
..NET converted to C# would look like.

As an aside, I've seen a lot of people shy away from .NET specifically
because it is a Microsoft product, and they don't trust, or want anything to
do with .NET.

[...]
>
> My own interest in Dot NET has been stimulated because I am seeing that
> most of the component factories are offering Dot NET components and
> discouraging use of the older OLE based components. Added to this, the
> Classes which underlie Dot NET are the richest MS have ever produced and
> are even better than MFC in many regards.

I believe Microsoft is going to push even tighter coupling between
Windows and .NET, phasing out OLE, with Windows Vista.

>
> Interesting. Maybe someone can comment on that?

Mono
http://www.mono-project.com/Main_Page (has screenshots)
http://en.wikipedia.org/wiki/Mono_(software)

The concepts and technology of the .NET platform are "open" in some
sense (I haven't looked closely at this from a legal perspective), so
getting it to work on Linux was relatively problem free. However, Microsoft
has released a very large collection of classes and functions, and they have
not provided the source code for those, and so the bulk of the work in
developing the Mono project is reimplementing all that functionality from
scratch.

My understanding is that this work is actually mostly complete now,
except for GUI stuff. Without the GUI, you can't really develop user
applications (except for console or text-based ones), but you would have no
trouble developing web applications or SOA, which is the niche Mono is
currently filling.

For the GUI stuff, Microsoft's original library features something
called WinForms. For whatever reasons, the Mono project decided not to
replicate WinForms, and instead use a different API called GTK# to handle
the GUI stuff. GTK was a GUI library for C++ applications, and so GTK# is
the .NET equivalent.

If you wrote .NET code using WinForms, you'd have to rewrite it to use
GTK# instead to get it to run on Mono. However, if you wrote your .NET
application to use GTK#, then to get it to run on Microsoft's .NET platform
(as opposed to Mono), you'd simply have to download a free (open source)
GTK# runtime; no code rewrite is nescessary. So in that sense, GTK# is more
flexibile and leaves more options open to you.

[...]
> Instead of writing a procedure like...
> <procedure for invoice>
> (For purposes of argument only...no attempt to be a tech. or functional
> spec. :-))
> For each Product purchased
> Prepare a line on the invoice
> place the qty of items, a description of the item, the unit
> price, and any discount, into the line
> multiply the qty by the unit price, and discount and show the
> total in a column at the end of the row
> calculate GST/VAT/MWS/Sales Tax at the current going rate, based
> on the row total and put it in
> another total, adjacent to the total value of the sale.
> when all products complete
> sum totals of invoice lines and tax and place them in the total boxes
> at the foot of the invoice
> print the invoice or email it or fax it or whatever...
> </procedure for invoice>
>
> You could simply say: "When a sales transaction occurs, instantiate and
> populate an invoice object, then print or dispose of it as configured."
>
> Impossible? Science Fiction? Not at all...

I'm sure it'll happen one day, but I'm skeptical about it happening in,
say, the next 5-10 years. That said, I saw this very interesting demo of
natural English programming. The "business logic" of a pac-man style game is
programmed by this exact source code:

<code>
Pacman is a character who loves to run through a maze and eat dots. Whenever
Pacman eats a dot, it disappears and he wins a point.
</code>

The compiler is capable of taking the above plain English "code" and
translating it to Python code as follows:

<code>
def __main__():
class Pacman(Character):
def run(maze):
pass

def eat(dot):
dot.disappear()
Pacman.win(point)

def win(point):
pass

class dot:
def disappear()
pass
</code>

Article is at
http://www.trnmag.com/Stories/2005/...ode_032305.html
Be sure to watch the movie at
http://web.media.mit.edu/~hugo/demo...nder-simple.mov

Again, I'm skeptical, so I'm not sure how much of the movie demo is
smokes and mirrors, and how much of it actually works. That said, this looks
extremely promising. If it becomes a reality, then, as Pete says,
programmers can implement the underlying engine (taking care of drawing
pacman, the dots, etc. on the screen and intecepting hardware events like a
joystick motion and triggered "business" events like a request for Pacman to
move), while non-programmers can describe the business rules in plain
English.

- Oliver

Michael Wojcik

2006-09-06, 6:55 pm

In article <4m6lpgF4qnt0U1@individual.net>, "Pete Dashwood" <dashwood@enternet.co.nz> writes:
> "Thane" <thaneh@softwaresimple.com> wrote in message
> news:1157464523.766912.288590@i3g2000cwc.googlegroups.com...
> OK. So how would you utilise Dot Net Classes and functions?

By calling programs written in other .NET languages, perhaps.

> If you are going to use Dot NET simply as a vehicle for ancient procedural
> code you might as well NOT make a transition to Dot Net at all.

So your question is "How does one write procedural COBOL, given the
requirement that procedural code be avoided?". Yes, that's a tough
one.

> If the products can leverage the underlying OO nature of the Dot NET
> environment WITHOUT the user having to learn OO concepts, that MIGHT be of
> some use (though personally, I wouldn't advise any company to do it).

It's entirely possible to write procedural COBOL that uses much of
the .NET[1] Framework, by employing a minimal amount of OO syntax;
that does not make it OO COBOL. For example:

-----
program-id. regtest.

environment division.
configuration section.
repository.
class RegEx as "System.Text.RegularExpressions.Regex".

data division.
working-storage section.
01 TestString string value "a b c".
01 SpaceRe string value "\s+".
01 RmvSpaces usage object reference RegEx.

procedure division.
display TestString
set RmvSpaces to RegEx::"New"(SpaceRe)
set TestString to RmvSpaces::"Replace"(TestString, "")
display TestString
goback.

end program regtest.
-----

That program has five verbs, two of them using OO syntax, but I
certainly wouldn't call it an OO program - it's patently
procedural. Other than that, the only OO syntax it uses is a
one-line repository paragraph.

A COBOL programmer wouldn't need to know anything about OO to
use this sort of pattern - it's just regular COBOL plus some
odd-looking calls.

I can certainly see the argument that learning OO COBOL is a
better way to go, in .NET; I even sympathize with it. But it's
a preference, not a rule.

> To me it seems tragic to simply drag the legacy of the last 50 years into a
> new environment that differs fundamentally and conceptually from that
> legacy. I would rather COBOL died gracefully than see that happen. If you
> disagree, please show your arguments.

I'll disagree that .NET "differs fundamentally and conceptually". It's
a JIT-compiled execution platform with some consistency checking.
That's not new by any stretch of the imagination; it's just another
take on various virtualization and capability approaches, some of
which (eg the JVM, the AS/400) were quite successful. And it comes
with an OO framework, but that's definitely not new either - not even
for COBOL.

There are advantages to running procedural COBOL under .NET, as
opposed to natively under Windows, such as signed assemblies and
trust partitioning. And there are certainly useful things to be done
with procedural COBOL plus minimal OO syntax to avoid unsafe
operations and make some use of the .NET Framework, as I did above.

Whether that's "tragic" and/or inferior to a graceful demise[2] is
a matter of taste.

[1] I've never seen Microsoft write this as "Dot Net". ".NET" is a
proper noun; spelling it your way makes as much sense as writing
about "Co Bol". Is there a reason for that, or is it just an
affectation?

[2] I suspect COBOL is headed for a graceful demise, but I happen
to believe that means a very prolonged decline in use - longer than
I expect to be in the business, certainly. I don't know what else
could constitute "graceful" in this context. Given the tremendous
amount of COBOL code in use, I don't see how any faster switch to
some other language could be accomplished with any grace whatsoever.
And I don't think COBOL is extraordinary in that regard - I don't
expect C or Fortran or even, say, Erlang to disappear anytime soon.

--
Michael Wojcik michael.wojcik@microfocus.com

An intense imaginative activity accompanied by a psychological and moral
passivity is bound eventually to result in a curbing of the growth to
maturity and in consequent artistic repetitiveness and stultification.
-- D. S. Savage

charles hottel

2006-09-06, 6:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:4m74fhF4rktmU1@individual.net...
> Hi Charlie, nice to see you are still coming here :-)

Yeah I still hang out, but ever since my old computer died a couple of years
ago I learned I could do without some of this stuff. I post much less often.
I get tried of reading the same old arguments and refuse to participate in
most of them and I often skip reading them. I am more attracted to the open
minds than the closed minds. Learning new things is the fun part for me.

>
> Quick comments below...
>
> "charles hottel" <chottel@earthlink.net> wrote in message
> news:mcpLg.6696$xQ1.2548@newsread3.news.pas.earthlink.net...

<snip>
[color=darkred]
> There is a different mentality amongst mainframe programmers. This is
> changing though.
>

Back in March I got invited to meeting with the head manager. I thought it
was a mistake as I am never invited to these things. I felt out of place
because I was the only non-manager/non-project leader there. I am one of the
few government employees who is an analyst/programmer. Most of the
programming work is done by contractors. I think I was invited there simply
because my name appeared on a list of government employees.

Anyway they mentioned an SOA document that outlines the IT department
strategy. I said that I had read about it earlier and had searched for it on
our intranet and could not find it. I asked if anyone could tell me where to
find it. Of course no one knew but hey promised to find out. I am still
waiting. At least I know they have something going on with SOA.

All of the other manager types were very outspoken about their needs to have
more of these types of meetings. Either they are having them without me now
or they are not having them. Perhaps it was because I asked about their
proposed Java strategy and specifically about J2EE technologies they were
planning to employ. The big boss asked one of the other managers about it
and said surely this had been decided by now. Well yes of course and Charlie
by the way contact me and let me know what you are most interested in. Well
I never did because (1) it was obvious to me that he had no clue about what
I had asked and (2) how can I say what I am interested in until I know what
my possible choices are. It does no good to be interested in stuff if I am
never going to get to use it. What a troublemaker I am.

Since that time I have heard that in one of the big meetings someone managed
to bring up that it might be more than a little risky to change your
programming language and your DBMS at the same time. I heard that perhaps
they are reconsidering and may incorporate COBOL into there plans for parts
of the new replacement system. Thank GOD our stuff is one of the most
complicated parts of the system and that they have decided to do our stuff
last. They will not even start on any rewrite until well after I will be
able to choose my retirement date at my leisure.

Pete Dashwood

2006-09-06, 6:55 pm

Thanks for the example code, Michael.

That was what I wanted to see.

Maybe Thane can do the same for Fujitsu.

I don't intend to argue the OO case further; people will vote with their
feet.

Pete.

TOP POST no more below.

"Michael Wojcik" <mwojcik@newsguy.com> wrote in message
news:edmu0l0kig@news2.newsguy.com...
>
> In article <4m6lpgF4qnt0U1@individual.net>, "Pete Dashwood"
> <dashwood@enternet.co.nz> writes:
>
> By calling programs written in other .NET languages, perhaps.
>
>
> So your question is "How does one write procedural COBOL, given the
> requirement that procedural code be avoided?". Yes, that's a tough
> one.
>
>
> It's entirely possible to write procedural COBOL that uses much of
> the .NET[1] Framework, by employing a minimal amount of OO syntax;
> that does not make it OO COBOL. For example:
>
> -----
> program-id. regtest.
>
> environment division.
> configuration section.
> repository.
> class RegEx as "System.Text.RegularExpressions.Regex".
>
> data division.
> working-storage section.
> 01 TestString string value "a b c".
> 01 SpaceRe string value "\s+".
> 01 RmvSpaces usage object reference RegEx.
>
> procedure division.
> display TestString
> set RmvSpaces to RegEx::"New"(SpaceRe)
> set TestString to RmvSpaces::"Replace"(TestString, "")
> display TestString
> goback.
>
> end program regtest.
> -----
>
> That program has five verbs, two of them using OO syntax, but I
> certainly wouldn't call it an OO program - it's patently
> procedural. Other than that, the only OO syntax it uses is a
> one-line repository paragraph.
>
> A COBOL programmer wouldn't need to know anything about OO to
> use this sort of pattern - it's just regular COBOL plus some
> odd-looking calls.
>
> I can certainly see the argument that learning OO COBOL is a
> better way to go, in .NET; I even sympathize with it. But it's
> a preference, not a rule.
>
>
> I'll disagree that .NET "differs fundamentally and conceptually". It's
> a JIT-compiled execution platform with some consistency checking.
> That's not new by any stretch of the imagination; it's just another
> take on various virtualization and capability approaches, some of
> which (eg the JVM, the AS/400) were quite successful. And it comes
> with an OO framework, but that's definitely not new either - not even
> for COBOL.
>
> There are advantages to running procedural COBOL under .NET, as
> opposed to natively under Windows, such as signed assemblies and
> trust partitioning. And there are certainly useful things to be done
> with procedural COBOL plus minimal OO syntax to avoid unsafe
> operations and make some use of the .NET Framework, as I did above.
>
> Whether that's "tragic" and/or inferior to a graceful demise[2] is
> a matter of taste.
>
>
> [1] I've never seen Microsoft write this as "Dot Net". ".NET" is a
> proper noun; spelling it your way makes as much sense as writing
> about "Co Bol". Is there a reason for that, or is it just an
> affectation?
>
> [2] I suspect COBOL is headed for a graceful demise, but I happen
> to believe that means a very prolonged decline in use - longer than
> I expect to be in the business, certainly. I don't know what else
> could constitute "graceful" in this context. Given the tremendous
> amount of COBOL code in use, I don't see how any faster switch to
> some other language could be accomplished with any grace whatsoever.
> And I don't think COBOL is extraordinary in that regard - I don't
> expect C or Fortran or even, say, Erlang to disappear anytime soon.
>
>
> --
> Michael Wojcik michael.wojcik@microfocus.com
>
> An intense imaginative activity accompanied by a psychological and moral
> passivity is bound eventually to result in a curbing of the growth to
> maturity and in consequent artistic repetitiveness and stultification.
> -- D. S. Savage

Pete Dashwood

2006-09-06, 6:55 pm

Excellent post and very interesting, Oliver. (Yours usually are:-))

Thanks for the stuff on mono, the heads up on Windows Forms, and the Pac Man
stuff... All duly noted.

My example was intended to show that it is possible to do things with an OO
approach, which are much less easy to do with a procedural one, and to
speculate where the logical progression from that may end up.

I don't think it will take 10 years for us to start seeing 'smart'
components, but I guess time will tell :-)

Pete.

TOP POST - only original post below.

"Oliver Wong" <owong@castortech.com> wrote in message
news:heCLg.10016$Mh7.4332@edtnps90...
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:4m6t41F4ql1gU1@individual.net...
>
> There's the .NET look-alike for Linux, as you mention later on, called
> Mono, and Mono is open source. One of the strong arguments for open source
> is that even if everyone else in the world abandons it, you always still
> have access to the source code and can modify or update it if you need to.
>
>
> The CLR support for different languages is one of the things I admire
> the most technologically in the .NET framework. I downloaded a 3rd party
> utility that will actually translate code written in any .NET language
> into your preferred language .NET, assuming your preferred language is
> either VB.NET or C#. I've tried converting VB.NET to C#, and the results
> were perfectly readable. I'd be interested in seeing what an OO COBOL
> targetting .NET converted to C# would look like.
>
> As an aside, I've seen a lot of people shy away from .NET specifically
> because it is a Microsoft product, and they don't trust, or want anything
> to do with .NET.
>
> [...]
>
> I believe Microsoft is going to push even tighter coupling between
> Windows and .NET, phasing out OLE, with Windows Vista.
>
>
> Mono
> http://www.mono-project.com/Main_Page (has screenshots)
> http://en.wikipedia.org/wiki/Mono_(software)
>
> The concepts and technology of the .NET platform are "open" in some
> sense (I haven't looked closely at this from a legal perspective), so
> getting it to work on Linux was relatively problem free. However,
> Microsoft has released a very large collection of classes and functions,
> and they have not provided the source code for those, and so the bulk of
> the work in developing the Mono project is reimplementing all that
> functionality from scratch.
>
> My understanding is that this work is actually mostly complete now,
> except for GUI stuff. Without the GUI, you can't really develop user
> applications (except for console or text-based ones), but you would have
> no trouble developing web applications or SOA, which is the niche Mono is
> currently filling.
>
> For the GUI stuff, Microsoft's original library features something
> called WinForms. For whatever reasons, the Mono project decided not to
> replicate WinForms, and instead use a different API called GTK# to handle
> the GUI stuff. GTK was a GUI library for C++ applications, and so GTK# is
> the .NET equivalent.
>
> If you wrote .NET code using WinForms, you'd have to rewrite it to use
> GTK# instead to get it to run on Mono. However, if you wrote your .NET
> application to use GTK#, then to get it to run on Microsoft's .NET
> platform (as opposed to Mono), you'd simply have to download a free (open
> source) GTK# runtime; no code rewrite is nescessary. So in that sense,
> GTK# is more flexibile and leaves more options open to you.
>
> [...]
>
> I'm sure it'll happen one day, but I'm skeptical about it happening in,
> say, the next 5-10 years. That said, I saw this very interesting demo of
> natural English programming. The "business logic" of a pac-man style game
> is programmed by this exact source code:
>
> <code>
> Pacman is a character who loves to run through a maze and eat dots.
> Whenever Pacman eats a dot, it disappears and he wins a point.
> </code>
>
> The compiler is capable of taking the above plain English "code" and
> translating it to Python code as follows:
>
> <code>
> def __main__():
> class Pacman(Character):
> def run(maze):
> pass
>
> def eat(dot):
> dot.disappear()
> Pacman.win(point)
>
> def win(point):
> pass
>
> class dot:
> def disappear()
> pass
> </code>
>
> Article is at
> http://www.trnmag.com/Stories/2005/...ode_032305.html
> Be sure to watch the movie at
> http://web.media.mit.edu/~hugo/demo...nder-simple.mov
>
> Again, I'm skeptical, so I'm not sure how much of the movie demo is
> smokes and mirrors, and how much of it actually works. That said, this
> looks extremely promising. If it becomes a reality, then, as Pete says,
> programmers can implement the underlying engine (taking care of drawing
> pacman, the dots, etc. on the screen and intecepting hardware events like
> a joystick motion and triggered "business" events like a request for
> Pacman to move), while non-programmers can describe the business rules in
> plain English.
>
> - Oliver

Clark F Morris

2006-09-07, 6:55 pm

In response to the posting below, I have been doing a lot of thinking
about OO and the mainframe. There are a number of reasons why I think
OO had a harder time.

1. COBOL, unlike the other languages was not a major part of most
university computer curriculums. Many of the computer science
departments were a part of the mathematics department or spun off from
it. These departments were for the most part interested in solving
different problems that those addressed by the business community.

2. The management of most business IT is not interested in computing
science and is interested in solving business problems without blowing
up the world every time a change is made.

3. The large base of installed code makes change interesting. I was
on the year 2000 project at one company and for many existing systems
they retained 2 digit years because of the difficulty of changing all
the files and data bases. This client also was interested in
replacing their then current application suite but did not have a
guaranteed workable solution. I understand that 6 years later the
client is finally going to be able to cut over to a new application.

3. OO wasn't even available in the IBM arena until the early 1990's
and the support for it had the client on bleeding edge. Indeed the
initial OO support has been replaced by JAVA interfacing.

4. Repository facilities really haven't been available until
relatively recently in the IBM mainframe arena for COBOL until the
past few years and populating a repository again is interesting.

5. While runtime checking of compatibility of parameters passed
between dynamic caller and called modules was requested in the
SHARE/Guide Language Futures Task Force Report in the 1980's, I doubt
there is any such facility even today. This run-time checking is
expensive in an online environment, far less so in batch because it
only has to be done at initial bind.

6. Other mechanisms had evolved to address some of the problems that
OO is used to solve. While they are not as good, the question of
conversion cost becomes a major stumbling block.

7. In the mainframe area, many organizations were looking to replace
existing code with packages, and in many cases to get off the
mainframe. The attitude in many shops was and still is that they will
keeping the old systems limping with minimal improvement until brave
new world takes over which will be soon for some value of soon.
Organizations underestimate the difficulty of replacing even poorly
written applications. The application suite I mentioned in item 3 had
most of the people who worked on it more than willing to contribute
effort to its early demise. Both major rewrite/upgrade and
replacement can be difficult.

8. Especially prior to a few years ago, on many systems the overhead
of added intermodule checking would have killed response time. The
additional overhead of a database and increased I-O before the era of
multi-gigabyte main memory systems also was an inhibitor to converting
to a database.

9. A major change like either database or OO has to have management
interest and understanding. Databases go back to the 1970's and
relational databases to the 1980's. It has taken a long time for the
ideas to penetrate organizations and there has been far greater push
on the part of vendors to educate management on the value of database.
I might also add database is far more necessary on Windows and Unix
systems than traditional mainframes because the former do not have a
native indexed file system while the mainframes did and do. I haven't
seen the comparable push for OO in the business computing environment.

10. I know that I have looked at OO and was interested in it but have
not bothered to learn it because I would have had no opportunity to
apply the knowledge. At age 67, I don't know that I will have such an
opportunity and I suspect that any contracts I get will be because of
my "old world" knowledge. I have not been that interested in Java
because I would be less valuable than someone two years out of school
although I would welcome the opportunity to upgrade a Java based
system. I am far more of an improver and fixer than I am a creator. I
suspect that many of my younger compatriots are in the same situation.

11. Many COBOL programmers and IT managers are brought in from other
departments and their interest in moving up in the organization may
not be in IT. I am not certain that IT is a profession despite what
the Canadian Information Processing Society claims.

On Tue, 5 Sep 2006 12:06:29 +1200, "Pete Dashwood"
<dashwood@enternet.co.nz> wrote:

>I have been looking more closely at Fujitsu COBOL for .Net.
>
>This is really an excellent product (on paper; I haven't tried it yet...)
>and adds OO COBOL to the Visual Studio IDE so that a developer can use any
>of the popular languages for the MicroSoft platform (C++, VB, C#). Dot Net
>COBOL has all the same benefits (editor, automatic build tracking, version
>control, project organisation, full debugging facilities) that the other
>languages enjoy and you can mix and match, developing classes (or .NET
>components) in any of these languages.
>
>It would be fairly easy to 'refactor' existing COBOL code for mainframe
>using this environment and Fujitsu are also offering a CICS converter.
>
>So, why would people not use it?
>
>The main obstacles I see are as follows:
>
>1. The mainframe sites are not into OO. The Dot NET environment is all
>about using Dot NET classes and objects and many IT Managers are going to be
>wary of upskilling their people, even though this is an ideal growth path
>for traditional mainframe programmers.
>
>2. The product is not cheap. That means that small software houses and
>independents won't get the chance to experiment with it, or discover the
>full benefits of it. (The free trial is for 5 days, not anywhere near long
>enough to evaluate all the facilities offered. I believe it can be extended
>by agreement with Fujitsu but that would be decidedly dodgy ground, in my
>opinion)
>
>3. Fujitsu support has established itself as being abysmal. One would hope
>that with this product, that would be remedied and addressed, but it remains
>to be seen.
>
>4. Service Oriented Architecture (which this product provides excellent
>support for) is still a mystery on mainframe sites where traditional COBOL
>is still in use. The 'smart' people who are getting into this, tend to be
>'Non-microSoft' users and, for them, Dot NET is of little interest anyway.
>(IBM's approach is primarily via Java servlets). Yet, SOA can be implemented
>very well in a Dot NET environment, and this product is ideal for doing just
>that.
>
>In the final analysis, it comes down to whether COBOL is still considered to
>be viable. I'm re-evaluating this. Certainly OO COBOL can be used just as
>easily as any other language, but the people who you might expect to use it,
>don't want to...:-)
>
>I still believe that COBOL as the only game in town is finished. But
>products like Fujitsu's Net COBOL for Dot NET could possibly allow it to be
>reinvented as a tool for refactoring existing code and for building SOAs
>from existing systems. I understand that MicroFocus are providing a similar
>product also, but I don't know the details.
>
>Both companies must believe there is a hopeful market for it. If there
>isn't, then they will sustain considerable losses. (The R & D could not have
>been cheap...)
>
>What do you guys think?
>
>A. COBOL will continue as it always has, being procedural code with source
>code maintained and central to all development.
>
>B. Companies will stop ALL IT development (including COBOL) and simply use
>packages, or outsource. The IT department is really just Network management,
>with network nerds making sure the network stays up so people can share
>spreadsheets, databases, and email, and rolling out new operating systems
>when required. No inhouse development.
>
>C. OO COBOL will be used to refactor existing source code into reusable
>components. Probably as the basis for a SOA.
>
>D. Existing systems written in COBOL will simply be replaced over time.
>In-house support for COBOL will be dropped.
>
>D. COBOL will have some other role, not described above.
>
>Pete.
>
>
>
>
>

Pete Dashwood

2006-09-07, 9:55 pm

Thanks for an interesting and thoughtful response, Clark.

I am personally of the opinion that any languages not supporting the OO
paradigm will be gone within 10 years, and that includes COBOL, unless it is
seen to share classes and play on the same playing field as the other OO
languages.

The

thing about OO COBOL is that it supports non-OO use, out of
deference to it's long history. The fact that it does this is admirable, but
it doesn't encourage the user base to move on from 1960.

OO COBOL running in the Dot NET environment could have a real chance of
saving COBOL's bacon by showing how useful it can be; it can interact, share
Classes, and work with the other OO languages on an equal footing. If all
the COBOL programmers in the world were using it (with other languages) for
OO, COBOL would have an assured future.

They're not. Furthermore, there is no indication that they are likely to.

The conclusion is inevitable.

In fact, the posts here, the attitudes to OO still being exhibited, and the
lack of response to a likely sales enquiry by Fujitsu, are all combining to
tell me that I am flogging a dead horse. Might as well just let it go and
move on to C#...(and save several thousand dollars in the process...)

Small wonder we are witnessing the demise of COBOL. Even the people who are
selling it apparently aren't interested in doing so...

If the lifeblood of COBOL is going to be 1960s code in a mainframe
environment, it will be lucky if it lasts 10 years...

The trends are already apparent.

Pete.

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:07b1g251jj70djq3qdmaf5iqskrol38trn@
4ax.com...[color=darkred]
> In response to the posting below, I have been doing a lot of thinking
> about OO and the mainframe. There are a number of reasons why I think
> OO had a harder time.
>
> 1. COBOL, unlike the other languages was not a major part of most
> university computer curriculums. Many of the computer science
> departments were a part of the mathematics department or spun off from
> it. These departments were for the most part interested in solving
> different problems that those addressed by the business community.
>
> 2. The management of most business IT is not interested in computing
> science and is interested in solving business problems without blowing
> up the world every time a change is made.
>
> 3. The large base of installed code makes change interesting. I was
> on the year 2000 project at one company and for many existing systems
> they retained 2 digit years because of the difficulty of changing all
> the files and data bases. This client also was interested in
> replacing their then current application suite but did not have a
> guaranteed workable solution. I understand that 6 years later the
> client is finally going to be able to cut over to a new application.
>
> 3. OO wasn't even available in the IBM arena until the early 1990's
> and the support for it had th