Cobol - Cobol's future - Microfocus, actually

Author

Cobol's future - Microfocus, actually

Michael Russell

2005-03-30, 8:55 am

I've liked Microfocus Cobol for a long time now.
It's like a well-known & used workshop tool.

The way things seem to me, very few students learn Cobol
and the intake of new users is probably minimal.
The writing's been on the wall for a good while.

Considering the shift in policy by, say, Oracle in making their
products freely available - for no money - I hope Microfocus
take a good look at their evaluation of how best to trade.

I'd suggest, fwiw, that MF could adopt a free distribution along
the same lines: cut the initial charges and rely on support and
maintenance.

Perhaps the short-to-medium term 'sales' wouldn't dazzle the world,
however, it may well recruit more _users_ of their Cobol.
It would also mean sharpening up their strategy & will for survival.
Without change, I fear they will simply wither on the vine.

Difficult to sell to the bean-counters, though.

Regards

Michael

Kellie Fitton

2005-03-30, 8:55 am

They used to allow free distribution of the runtime system on
differernt machines
for the Net Express compiler, I think version 2.0 and 3.0 for windows
platform, am
not sure why they had a change of heart with version 4.0, though. I
wonder how
they feel about Fujitsu's free 32-bit cobol compilers (students
version), when they
have a Net Express version that's geared toward students for about
$99.00 USD.

personally, I think the Net Express cobol compiler's much superior than
Fujitsu's
cobol compiler, also the IDE is much easier to navigate and the runtime
execution
is obviously faster, especially when I use the compilation directive
align"8", which
optimizes the machine code and allows for compatibility with 64-bit
versions.

Kellie Fitton

2005-03-30, 8:55 am

Jimmy,

What Micro Focus charges for the distributed runtime modules is not
expensive, the
problem with their policy though is that they want the customer to
purchase a minimum
of TEN licenses, for each time they need a license for a new machine. I
think the price
for a pack of TEN is about $1,100.00 USD. I think they should make the
minimum only
two per pack though, this way they can increase the circle of Cobol,
and mabe capture
more market share than acuCobol, Fijitsu and Liant as well. Regards.

Kellie.

James J. Gavan

2005-03-30, 8:55 am

Kellie Fitton wrote:
> Jimmy,
>
> What Micro Focus charges for the distributed runtime modules is not
> expensive, the
> problem with their policy though is that they want the customer to
> purchase a minimum
> of TEN licenses, for each time they need a license for a new machine. I
> think the price
> for a pack of TEN is about $1,100.00 USD. I think they should make the
> minimum only
> two per pack though, this way they can increase the circle of Cobol,
> and mabe capture
> more market share than acuCobol, Fijitsu and Liant as well. Regards.

Kellie,

OK that makes sense. Although not au fait with current pricing, you can
see why in the back of my mind I was thinking how much you had to shell
out up front. Now here's the problem; if and when I distribute, I'd want
it on a site for prospective users to take a look - then if interested,
we can get serious about runtime fees. If I make a good buck, then I
can't grumble too much at M/F making a buck too - I just include it in
my overall price.

On a personal basis they can be flexible, once they know the situation.
I recall somebody saying if I produce a small 'gizmo' retailing at $50,
what's the score ? Don't recall the answer. I think there was a
follow-up to accommodate the query.

Jimmy

Michael Russell

2005-03-30, 8:55 pm

Thane wrote:

>Oracle also charges HEFTY per connected user fees (or high site license
>fees for unlimited users). They also charge different license fees per
>processor.
>
>
>
Ah - the software is free, however.
This 'clearer' story lacks a bit of clarity :-)
How do corporates get in the position of paying these fees?
Not doubting that they do, but is it fair to assume that these
fees are for the support they've signed up for?

If Microfocus gave away their product, they could charge for support, too,
just like Oracle...... ?

Regards

Michael

Richard

2005-03-30, 8:55 pm

> All of Oracle's databases are free to download (9i to 10g, lots of
> platforms). They charge for maintenance (fixes) & support.

It may well be that you can download certain versions of Oracle, but
that doesn't give you a free licence to use it. You can download the
pricing PDF from the Oracle site which shows that a per CPU server
price may be $US40,000 plus per user fees of $US800.00 and that is
before options are added.

There are 'Personal edition' and 'Lite' which are quite restricted and
licences are $400 and $100 respectivly per user.

> Sun's Solaris is also free.

Solaris on a Sun server is paid for as part of the equipment cost.
Solaris on Intel I can't comment on, it may be free.

> I think Sybase may be, too. There must be others, but I haven't
looked.

There are many free database products, such as Ingres, PostgreSQL,
MySQL and so on. Sybase is not one of them. You can get trial and
evaluation versions of Sybase.

Frederico Fonseca

2005-03-30, 8:55 pm

On 30 Mar 2005 16:04:43 -0800, "Richard" <riplin@Azonic.co.nz> wrote:

>
>It may well be that you can download certain versions of Oracle, but
>that doesn't give you a free licence to use it. You can download the
>pricing PDF from the Oracle site which shows that a per CPU server
>price may be $US40,000 plus per user fees of $US800.00 and that is
>before options are added.
You can download and develop freely. Only when you are deploying do
you need to buy any licenses.

>
>There are 'Personal edition' and 'Lite' which are quite restricted and
>licences are $400 and $100 respectivly per user.
>
>
>Solaris on a Sun server is paid for as part of the equipment cost.
>Solaris on Intel I can't comment on, it may be free.
>
>looked.
>
>There are many free database products, such as Ingres, PostgreSQL,
>MySQL and so on. Sybase is not one of them. You can get trial and
>evaluation versions of Sybase.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Michael Russell

2005-04-01, 3:55 pm

Thane

2005-04-06, 11:59 am

Oracle also charges HEFTY per connected user fees (or high site license
fees for unlimited users). They also charge different license fees per
processor.

Michael Russell

2005-04-06, 11:59 am

Richard

2005-04-06, 11:59 am

Stephen Gennard

2005-04-06, 12:00 pm

>> Sun's Solaris is also free.

But Micro Focus COBOL is not a operating system it is a development tool.

Sun's own development tools such as their C/C++ and Fortran compilers are
not free.

ref : http://www.sun.com/software/products/studio/index.xml

--
Stephen

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1112227483.900890.83300@o13g2000cwo.googlegroups.com...
>
> It may well be that you can download certain versions of Oracle, but
> that doesn't give you a free licence to use it. You can download the
> pricing PDF from the Oracle site which shows that a per CPU server
> price may be $US40,000 plus per user fees of $US800.00 and that is
> before options are added.
>
> There are 'Personal edition' and 'Lite' which are quite restricted and
> licences are $400 and $100 respectivly per user.
>
>
> Solaris on a Sun server is paid for as part of the equipment cost.
> Solaris on Intel I can't comment on, it may be free.
>
> looked.
>
> There are many free database products, such as Ingres, PostgreSQL,
> MySQL and so on. Sybase is not one of them. You can get trial and
> evaluation versions of Sybase.
>

Stephen Gennard

2005-04-06, 12:00 pm

> MF's problem is, I think, a shrinking market place (or dwindling number of
> customers). They perhaps see it as inevitable that Cobol will die off.
> Everything dies off; there's no virtue in sitting around until it does:
> better get on with business!

Does MF really have a problem or is it just that *you* think MF has a
problem?

--
Stephen

"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:42456b27$0$2779$cc9e4d1f@news-text.dial.pipex.com...
> James J. Gavan wrote:
>
>
> Jimmy,
>
> All of Oracle's databases are free to download (9i to 10g, lots of
> platforms). They charge for maintenance (fixes) & support.
> Sun's Solaris is also free. I think Sybase may be, too. There must be
> others, but I haven't looked.
>
> MF's problem is, I think, a shrinking market place (or dwindling number of
> customers). They perhaps see it as inevitable that Cobol will die off.
> Everything dies off; there's no virtue in sitting around until it does:
> better get on with business!
>
> They have my best wishes - it's a tough situation to be in - I hope they
> out-tough it!
>
> Regards
>
> Michael
>
>

James J. Gavan

2005-04-06, 12:00 pm

Thane wrote:
> Oracle also charges HEFTY per connected user fees (or high site license
> fees for unlimited users). They also charge different license fees per
> processor.
>
Thank you ! Always nice to get a "clearer" story.

Jimmy

Alistair Maclean

2005-04-06, 3:55 pm

Michael Russell <Michael.Russell@msn.com> wrote in message news:<42456b27$0$2779$cc9e4d1f@news-text.dial.pipex.com>...
> James J. Gavan wrote:
>
>
> Jimmy,
>
> All of Oracle's databases are free to download (9i to 10g,

I tried to download one of these. No luck. I contacted their support
number and got told that their free downloads were enabled for 30 days
only.

William M. Klein

2005-04-07, 3:55 am

I disagree with you analysis of what Micro Focus thinks is the current and
future of COBOL.

HOWEVER, I do believe that they think *their* future is with "large" enterprise
COBOL shops and NOT with "individual" (or even small) development environments.

This DOES impact their "business model" (IMHO)

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:42456b27$0$2779$cc9e4d1f@news-text.dial.pipex.com...
> James J. Gavan wrote:
>
>
> Jimmy,
>
> All of Oracle's databases are free to download (9i to 10g, lots of platforms).
> They charge for maintenance (fixes) & support.
> Sun's Solaris is also free. I think Sybase may be, too. There must be others,
> but I haven't looked.
>
> MF's problem is, I think, a shrinking market place (or dwindling number of
> customers). They perhaps see it as inevitable that Cobol will die off.
> Everything dies off; there's no virtue in sitting around until it does: better
> get on with business!
>
> They have my best wishes - it's a tough situation to be in - I hope they
> out-tough it!
>
> Regards
>
> Michael
>
>

William M. Klein

2005-04-07, 3:55 am

Most of this thread has gone to "run-time" fees. I think there ARE different
issues related to free (low-cost) compilers versus free (low-cost) run-time
licenses.

However, it is interesting to note that Fujitsu *tried* a model of literally
GIVING AWAY their V3 compiler (and originally - not currently - this was for
"production" use). Furthermore, they did then AND STILL have no run-time
license charges.

However, from a business point of view, it is MY perception that the Micro Focus
"business model" has turned out to be more successful (for them) AND has
provided them the income to (apparently) provide both better software support
AND R&D resources.

Others may have other experiences, but my impression is that - no matter what we
MIGHT want or hope for - the Micro Focus (current) model (certainly NOT the
"MERANT" mindset) is working and SEEMS to provide a "future" for COBOL.

--
Bill Klein
wmklein <at> ix.netcom.com
"Michael Russell" <Michael.Russell@msn.com> wrote in message
news:424488fb$0$2766$cc9e4d1f@news-text.dial.pipex.com...
> I've liked Microfocus Cobol for a long time now.
> It's like a well-known & used workshop tool.
>
> The way things seem to me, very few students learn Cobol
> and the intake of new users is probably minimal.
> The writing's been on the wall for a good while.
>
> Considering the shift in policy by, say, Oracle in making their
> products freely available - for no money - I hope Microfocus
> take a good look at their evaluation of how best to trade.
>
> I'd suggest, fwiw, that MF could adopt a free distribution along
> the same lines: cut the initial charges and rely on support and
> maintenance.
>
> Perhaps the short-to-medium term 'sales' wouldn't dazzle the world,
> however, it may well recruit more _users_ of their Cobol.
> It would also mean sharpening up their strategy & will for survival.
> Without change, I fear they will simply wither on the vine.
>
> Difficult to sell to the bean-counters, though.
>
> Regards
>
> Michael

Robert Wagner

2005-04-08, 3:55 am

On Thu, 07 Apr 2005 03:39:39 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I disagree with you analysis of what Micro Focus thinks is the current and
>future of COBOL.
>
>HOWEVER, I do believe that they think *their* future is with "large" enterprise
>COBOL shops and NOT with "individual" (or even small) development environments.
>
>This DOES impact their "business model" (IMHO)

They are right, economically. One large customer can produce tens of
thousands in revenue, with only a handful of support calls .. some
productive and justified.

It would take hundreds of small customers to produce the same revenue,
and they'd produce a thousand times as many support calls.

I've called MF support twice, once under someone else's name. Once I
was reporting a bona fide reproducable BUG in their OpenESQL
precompiler. The other time it was an undocumented incompatibility
between the Oracle 'listener' and the MF runtime. Both were the kind
of issues that support wants and needs to hear about, not requests for
help born of ignorance.

Small users are a PITA.

Pete Dashwood

2005-04-08, 3:55 am

I really wish I could agree, Bill.

See below.

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:N%15e.7430531$f47.1367306@news.easynews.com...
> Most of this thread has gone to "run-time" fees. I think there ARE
different
> issues related to free (low-cost) compilers versus free (low-cost)
run-time
> licenses.
>
> However, it is interesting to note that Fujitsu *tried* a model of
literally
> GIVING AWAY their V3 compiler (and originally - not currently - this was
for
> "production" use). Furthermore, they did then AND STILL have no run-time
> license charges.
>

Fujitsu did this when the MF user base (of which I was one) felt pretty
upset over the withdrawal of VISOC. By offering a free COBOL compiler (plus
a DIALOG alternative in PowerCOBOL) they were hoping to attract a market
share. It worked. I for one, changed to Fujitsu and have remained with it
ever since.

I don't believe it was ever their intention to offer free compilers for the
duration... it was simply an effective marketing ploy. It also helped to
encourage interest in COBOL as a product and a credible development tool,
but that was just a positive spin off.

Since then the world has changed and is continuing to do so.

There have been huge sea-changes at MF/Merant, Fujitsu (America) has also
had some drastic changes (particularly in the way they handle support), and
the other COBOL vendors are kind of hanging in there by the skin of their
teeth. It is a declining market. The reasons for its decline only have a
little to do with COBOL users. We have seen a refusal by the user base to
embrace innovation like OO (while the rest of the world has grabbed it
avidly and used it as the basis for most modern development), but that in
and of itself has not caused the decline in COBOL. (It hasn't helped..mainly
because the language has no credibility WITHOUT the ability to handle
objects and components. This capability was added, but unless people use it,
it might as well have not been.)

There is no shortage of enthusiasm for COBOL, as we can witness in this
group, but talking it up doesn't change the reality of what is going on in
the world. People want quicker, easier, solutions. Other technologies
(including OO) are delivering these solutions. COBOL (and other procedural
languages) are being bypassed.

> However, from a business point of view, it is MY perception that the Micro
Focus
> "business model" has turned out to be more successful (for them) AND has
> provided them the income to (apparently) provide both better software
support
> AND R&D resources.
>
But is it sustainable?

As the COBOL market shrinks, the overall market for IT services is actually
expanding.

I will make a prediction here which you can gladly rub my nose in, in 15
years....

"By 2020, MicroFocus will either no longer be trading (this includes being
absorbed) or will have diversified their product range away from COBOL and
be into 'something else'. (In this case they would probably provide a small
core of maintenance staff for their remaining COBOL base customers, but
there will not be further releases of the compiler.)"

The problem with run time fees is that they provide short term revenue only.
As the market for developed systems becomes ever more competitive, cost of
runtime distribution becomes a serious 'negative edge'. Eventually
developers move to an environment where they will not incur this cost.

> Others may have other experiences, but my impression is that - no matter
what we
> MIGHT want or hope for - the Micro Focus (current) model (certainly NOT
the
> "MERANT" mindset) is working and SEEMS to provide a "future" for COBOL.
>

No one COBOL vendor will be responsible for providing a future for COBOL.
They may provide a limited future for their own niche market...

The market has already voted. There is no future for COBOL (apart from
possible batch applications, but even these will eventually move to other
platforms and environments.)

These days I use COBOL out of fondness and affection for it, not because of
any technical reason to do so. Others will also come to realise that there
is no need for it, and those who have never learned it, will certainly never
use it.

Corporations implementing 'best practices' won't even look at it.

The things which made COBOL important, are no longer relevant, but it is
very hard for COBOL programmers to see that.

It gives me no pleasure but that is how I see it.

Pete.

> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Michael Russell" <Michael.Russell@msn.com> wrote in message
> news:424488fb$0$2766$cc9e4d1f@news-text.dial.pipex.com...
>
>
>

jce

2005-04-08, 8:55 am

I wish I could agree......oh damn...I do mostly ;-)

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3bmcbuF6i66k6U1@individual.net...
>I really wish I could agree, Bill.
>
> See below.
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:N%15e.7430531$f47.1367306@news.easynews.com...

> There have been huge sea-changes at MF/Merant, Fujitsu (America) has also
> had some drastic changes (particularly in the way they handle support),
> and
> the other COBOL vendors are kind of hanging in there by the skin of their
> teeth. It is a declining market. The reasons for its decline only have a
> little to do with COBOL users. We have seen a refusal by the user base to
> embrace innovation like OO (while the rest of the world has grabbed it
> avidly and used it as the basis for most modern development), but that in
> and of itself has not caused the decline in COBOL. (It hasn't
> helped..mainly
> because the language has no credibility WITHOUT the ability to handle
> objects and components. This capability was added, but unless people use
> it,
> it might as well have not been.)

Not everything needs OO, not everything needs to talk to components. Web
Services [a fancy way of saying nothing particularly useful] can be
implemented as COBOL.
Again, the language is not important. COBOL is dying because it simply
offers no academic value or interest.

Most progress is made where there is academic interest or a perceived
commercial edge. Open source is a slight twist in so far as it is typically
to fulfil both "personal academic interest, or to provide free alternatives"

Commercially, Java was invented as they saw a need for the convergence of
digital devices (the language was a byproduct)....NET exists to increase the
sales of the base software platform (I'm not a MS bigot).

Computer science departments are working on real time photo rendering,
massively distributed databases, or natural language processing....or even
better, the tedium that is the latest and greatest XtraTreme practices for
SuperAgile facet based programming.
Java was developed for

I will suggest the SFM process using WBT to VDS and make lots of money
selling academic books stating the freaking obvious (It stands for Stick
Figure Model using White Board Technology to Visually Depict Scenarios)

Even in an OO world, logic is presented as logic at its root...& ^ | . Most
OO that I see is still procedural in its fundamental nature. It just
attaches a new data access methodology to what has happened for years (real
time user input systems are one exception). Most datastores are *still*
relational - OO databases have not taken off in the market place....this to
me says that OO is not the magic bullet - just a tool to simplify certain
tasks.

Object serialization is just a slightly enhanced record layout.....once you
get to sending across a wire, the language at the end makes no difference.
The brokers are the new key technology, and so that drives us to move from
record layouts to something more sophisticated - dynamic binding *is* some
real magic but it's not always needed - and in some cases you don't need the
OO package to accomplish the same thing..

> There is no shortage of enthusiasm for COBOL, as we can witness in this
> group, but talking it up doesn't change the reality of what is going on in
> the world. People want quicker, easier, solutions. Other technologies
> (including OO) are delivering these solutions. COBOL (and other procedural
> languages) are being bypassed.

This group talks about life, death, etymology, and components...occasionally
talking about how we are all lamenting the death of COBOL. If we removed
the B, it would survive. What COBOL needs is a new marketing campaign...if
we re-released a new language called Open Source MODE++ it would sell
(Massive Object Data for the Enterprise language -enhanced) it would be
taken up. I *really* believe that. The language is not the problem it's
that such a good job was done misinforming the public.

I like in to the fact that most Americans that I've personally asked (I will
not provide evidence of everyone I asked and their response) was *not* aware
that Russia was an ally in WW II. They cannot be convinced because the cold
war came with such intense propaganda. People cannot see beyond what they
have been taught to believe. It is why now in the US colleges you have to
frame *ALL* questions with a specific answer criteria because you can be
sued if you mark a paper that may be somewhat subjective because all
professors are leftist weenies who don't accept the position of the
conservatives (I'm not making this up). If you say write a canto
describing a level of hell, the crime and the punishment and keep it light -
you would expect Java bigots forced to write COBOL, or people who brake at
an orange light constantly having to wait for the red light.....but you
actually get...Gays go to hell because it's sin ....Muslims go to hell
because they are terrorists....(This *really* happened) People are losing
the ability to make critical decisions.....what is needed is to apply that
knowledge of that fact to COBOL.

COBOL just needs to be given a new name, new mantra, and some young

kid support...people have been taught that COBOL is bad and old for boring
bald headed men with gray beards and suspenders.

> Focus
> support
> But is it sustainable?
No

> As the COBOL market shrinks, the overall market for IT services is
> actually
> expanding.
Key word. Services. This is consulting. The IT needs a ground up overhaul.
Inventive new development not created to drive major enterprises. The SMB
market is the driving force to growth. Someone needs to subvert the growth
of Dell, IBM, EDS, Infosys, HP to move forward....and someone other than
large capital groups that own Microfocus and other businesses. We are
heading to consultant services using very little new innovation...COBOL
shrinks because what innovation there is takes part within a framework that
is "malleable". COBOL is pretty static......Java is still "being
developed", EJB and .NET are being enhanced as I type..

> I will make a prediction here which you can gladly rub my nose in, in 15
> years....

I call your 15 years and raise you 15 years

> "By 2020, MicroFocus will either no longer be trading (this includes
> being
> absorbed)
Microfocus is already managed by Golden Gate. I'm not sure it's traded. If
it is, then I lost this hand, but on the next I will raise you 5 because I
think in 10 years the entire software industry will be on its head.
Unlike you, I will not be living it up on the beach...more like scrounging
around for the $20,000 I will need to become a certified consultant ( I need
to start by certification company)

> or will have diversified their product range away from COBOL and
> be into 'something else'. (In this case they would probably provide a
> small
> core of maintenance staff for their remaining COBOL base customers, but
> there will not be further releases of the compiler.)"
What new is there to do? It would be more effective to write COBOL
"entertain" the world of software library attachments.

> The problem with run time fees is that they provide short term revenue
> only.
> As the market for developed systems becomes ever more competitive, cost of
> runtime distribution becomes a serious 'negative edge'. Eventually
> developers move to an environment where they will not incur this cost.
It's an interesting question going forward. The SOA world comes with many
of the same issues...I would expect that they would try and align with
whatever the business model will become. Many many vendors will provide
solutions that will embed in many and to end solutions.

> what we
> the
>
> No one COBOL vendor will be responsible for providing a future for COBOL.
> They may provide a limited future for their own niche market...
No one thought the 80s would be

again.....

> The market has already voted. There is no future for COBOL (apart from
> possible batch applications, but even these will eventually move to other
> platforms and environments.)
There is no future for Java and there is no future for .NET either...so
where are we going? The future is, unfortunately, whatever makes big
business money unless the "change" happens. This is a required global
statement

> These days I use COBOL out of fondness and affection for it, not because
> of
> any technical reason to do so. Others will also come to realise that there
> is no need for it, and those who have never learned it, will certainly
> never
> use it.
> Corporations implementing 'best practices' won't even look at it.
Best practices are what ?
CMM/SOA/Agile/ISD/XP/ISO/Waterfall/Re-use/Components/Linux/J2EE/.NET (I
know I'm mixing language, environment, practices but that's kind of my
point). Most corporations don't even understand what "metadata" or
"enterprise architecture" or "business rules" are. It' s my experience that
the first business rule written down is "Business Rules cannot be changed
and must be enforced" followed closely by the second rules "Except when
they aren't"

> The things which made COBOL important, are no longer relevant, but it is
> very hard for COBOL programmers to see that.
The things that made C, C++, Java important aren't relevant either.....

> It gives me no pleasure but that is how I see it.
When you are retired and live in what is allegedly one of the most beautiful
places in the world, COBOL is the last place I would look for pleasure.

As they say, Work to live your life, don't live your life to work.

Things always look bad, then they always come good ....Frankly, I'm more
worried about whether where I live will still be above water and heat
bearable with water to sustain the population in 15 years more than I am
whether Microfocus exists....we're just about ready to pass a law that will
allow Wallmarts to develop 10 acres of prime wetland without federal
approval.....

JCE
[color=darkred]
> Pete.
>

Pete Dashwood

2005-04-08, 8:55 pm

An entertaining and well written post, John.

It was such a good response I decided to respond to it :-)

See below....

"jce" <defaultuser@hotmail.com> wrote in message
news:qHp5e.24635$vd.14559@tornado.tampabay.rr.com...
> I wish I could agree......oh damn...I do mostly ;-)
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3bmcbuF6i66k6U1@individual.net...
>
also[color=darkred]
their[color=darkred]
to[color=darkred]
in[color=darkred]
>
> Not everything needs OO, not everything needs to talk to components. Web
> Services [a fancy way of saying nothing particularly useful] can be
> implemented as COBOL.

Yes, things CAN be implemented in many different ways. And certainly not
everything (particularly when it comes to applications), requires OO.

But, just taking Windows as an example, the system software that drives your
PC is comprised of objects. You can use them the same as the OS does if you
can deal with objects. (See my recent paper on scripting).

OO is a very useful facility. It always was, but COBOL programmers for the
most part resisted it because they have consistently resisted change, and
felt threatened by anything that posed an alternative to the COBOL way of
doing things. (like client/server computing...)

> Again, the language is not important. COBOL is dying because it simply
> offers no academic value or interest.
>

I don't believe it is as simple as that. I see many factors contributing to
the predictable death of COBOL. Sometime when I'm not so busy, I'll document
my thoughts on this subject and let the forum tear it to bits... :-)

> Most progress is made where there is academic interest or a perceived
> commercial edge. Open source is a slight twist in so far as it is
typically
> to fulfil both "personal academic interest, or to provide free
alternatives"
>

Don't disagree. Often the commercial edge of a given technology generates
academic interest in it in a desire to improve it and maximise the edge.
Often it works the other way with commerce recognising a 'competitive edge'
in an emerging technology developed in Acadaemia.(Psion is a good example of
this...)

> Commercially, Java was invented as they saw a need for the convergence of
> digital devices (the language was a byproduct)....NET exists to increase
the
> sales of the base software platform (I'm not a MS bigot).
>

Again I don't see it quite as black and white as that, but in general I
agree with your statement.

I am still innocent enough to believe that Java was an attempt at platform
independence and a single programming model for many diverse digital
platforms. But that was not the only reason for it. I also believe that dot
NET is an attempt to provide a common platform (The heart of it is the CLR)
that will make life easier for the OS. I notice in passing that it is
completely OO.

> Computer science departments are working on real time photo rendering,
> massively distributed databases, or natural language processing....or even
> better, the tedium that is the latest and greatest XtraTreme practices for
> SuperAgile facet based programming.
> Java was developed for
>
> I will suggest the SFM process using WBT to VDS and make lots of money
> selling academic books stating the freaking obvious (It stands for Stick
> Figure Model using White Board Technology to Visually Depict Scenarios)
>
:-) I enjoyed that very much...

> Even in an OO world, logic is presented as logic at its root...& ^ | .
Most
> OO that I see is still procedural in its fundamental nature. It just
> attaches a new data access methodology to what has happened for years
(real
> time user input systems are one exception). Most datastores are *still*
> relational - OO databases have not taken off in the market place....this
to
> me says that OO is not the magic bullet - just a tool to simplify certain
> tasks.
>

I don't think anyone has ever seen OO (or anything else) as a magic bullet.
Certainly the event driven model of programming, attached to an OO scenario,
is quicker to learn, easier to implement, and achieves working results
faster than the traditional procedural equivalents. I already posted an
example here which shows the compactness and simplicity of code (once you
clear your mind of pre-conceived ideas about how code should look and how it
should operate). New people learn these concepts very quickly and get
productive much quicker than has previously been the case.

In the Oldene Dayse we took on a new COBOL guy and gave him/her simple tasks
to do (like reporting and some minimal file manipulation), while they
absorbed all the installation standards and learned how to format code
appropriately, and dealt with handling source code. The 'apprenticeship'
lasted 3 to 6 months depending on the pressures of work and the ability of
the person. These days DB programmers write stored procedures using Graphic
IDEs that glue components together in minutes. Within a w

on the job they
are up to speed. The tools they use are infinitely more powerful than
TSO/ISPF.

It simply isn't acceptable any more to produce 1000 lines of source code (or
even 500 lines, if you want to quibble about code) to manipulate a database,
take three days to develop and test it, when the same result can be
achieved in 30 lines of script using OO components, that take an hour or so
to completely test and document.

As I mentioned earlier, the world wants faster solutions. Procedural
solutions simply don't provide them and the dependence on source code is no
longer viable. Even cutting and pasting or COPYing it (which, as we all
know, leads to proliferation of duplicated code across applications) still
doesn't improve the process to the point where it is competitive with
non-procedural development.

The non-COBOL world has voted with its feet. Whether you agree with my
synopsis or not, the market place is embracing it and I have seen procedural
code being replaced on several installations for very much the reasons
outlined. (I actually managed one major installation where this process was
taking place). It isn't emotional or a conspiracy against COBOL, it is just
doing what is commercially advantageous.

> Object serialization is just a slightly enhanced record layout.....once
you
> get to sending across a wire, the language at the end makes no difference.
> The brokers are the new key technology, and so that drives us to move from
> record layouts to something more sophisticated - dynamic binding *is* some
> real magic but it's not always needed - and in some cases you don't need
the
> OO package to accomplish the same thing..

I agree it is magic and I use it exclusively. 'Late Binding' (in an OO COBOL
environment) incurs a slight overhead at runtime, does not allow the
compiler to use the repository for validation of calls during source
processing, but more than makes up for these limitations by providing more
ease of use and much greater flexibility.(It also minimises maintenance
impacts on processes.) You can certainly use 'dynamic linkage' for called
modules from standard COBOL in most environments but, as I have tried to
explain here on numerous occasions, called COBOL modules are an ITSLIKE not
an ITSA of OO objects and components. The differences are subtle but
extremely important.

>
in[color=darkred]
procedural[color=darkred]
>
> This group talks about life, death, etymology, and
components...occasionally
> talking about how we are all lamenting the death of COBOL. If we removed
> the B, it would survive. What COBOL needs is a new marketing
campaign...if
> we re-released a new language called Open Source MODE++ it would sell
> (Massive Object Data for the Enterprise language -enhanced) it would be
> taken up. I *really* believe that. The language is not the problem it's
> that such a good job was done misinforming the public.
>

Here we definitely diverge. Renaming COBOL as COOL (or anything else) will
not re-invent the language. I do not believe its decline is because of
misinformation of the public (the public actually don't give a damn how
computers are programmed as long as it doesn't freeze while they are playing
Doom and Aunt Agatha's emails get through OK...) or even of the programming
world at large, neither do I believe the marketing ploys you suggest would
make any difference whatsoever. It's time is over. It served us all very
well. Let it go.

> I like in to the fact that most Americans that I've personally asked (I
will
> not provide evidence of everyone I asked and their response) was *not*
aware
> that Russia was an ally in WW II. They cannot be convinced because the
cold
> war came with such intense propaganda. People cannot see beyond what they
> have been taught to believe.

Now we're back in agreement again. I certainly believe that marketing has a
huge effect. But nobody actively marketed against COBOL. As for the
gullibility or ignorance of your colleagues about history, well I don't see
that really affecting COBOL very much. It reflects more on a poor education
system.

>It is why now in the US colleges you have to
> frame *ALL* questions with a specific answer criteria because you can be
> sued if you mark a paper that may be somewhat subjective because all
> professors are leftist weenies who don't accept the position of the
> conservatives (I'm not making this up).

See last sentence of above paragraph. Again, no direct bearing on COBOL
(Man! it is really hard to stay on topic in this forum, isn't it :-)?)

>If you say write a canto
> describing a level of hell, the crime and the punishment and keep it
light -
> you would expect Java bigots forced to write COBOL, or people who brake at
> an orange light constantly having to wait for the red light.....but you
> actually get...Gays go to hell because it's sin ....Muslims go to hell
> because they are terrorists....(This *really* happened) People are losing
> the ability to make critical decisions.....what is needed is to apply that
> knowledge of that fact to COBOL.
>

You may be right. But it is the people who would be likely to use COBOL who
need to make the 'critical decision' as to whether they should use it or
not. And their choices are not as open as you might think. Competitive
pressure means they have to use effective technology. COBOL has proven
itself over years to be effective, but in a limited arena that does not
match today's network based amphitheatres. There are simply other tools that
cost less and do it better (in some areas) and at least as well in other
areas. The mighty marketplace drives everything and woe betide he who tries
to buck it... (ask Nigel Lawson :-))

> COBOL just needs to be given a new name, new mantra, and some young

> kid support...people have been taught that COBOL is bad and old for boring
> bald headed men with gray beards and suspenders.
>
Could that be because it is? :-) (I haven't got to the suspenders yet, but
I'm certainly working on the rest of the qualifications...)

Sorry, I know you really believe this, but I don't.

has[color=darkred]
> No

Time will tell, of course, but I tend to agree that it probably is not
sustainable.

>
> Key word. Services. This is consulting.

Yes, I find to my amazement that just as I was ready to go out to pasture,
my skills are in demand in this area.

(There is an old saying: "Those who can do, those who can't, teach" I have
no wish to offend some of the very capable and useful teachers who frequent
this forum and it IS only a saying, but maybe if we changed it to "give
advice" instead of teach, it would be closer to the mark as far as
consulting goes.)

>The IT needs a ground up overhaul.
> Inventive new development not created to drive major enterprises. The SMB
> market is the driving force to growth.

Agreed. As a current TV campaign here observes: "Without small business
there would be no big business."

> Someone needs to subvert the growth
> of Dell, IBM, EDS, Infosys, HP to move forward....and someone other than
> large capital groups that own Microfocus and other businesses. We are
> heading to consultant services using very little new innovation...COBOL
> shrinks because what innovation there is takes part within a framework
that
> is "malleable". COBOL is pretty static......Java is still "being
> developed", EJB and .NET are being enhanced as I type..
>

That is an interesting observation. I need to think some more about that.

>
> I call your 15 years and raise you 15 years
>
> Microfocus is already managed by Golden Gate. I'm not sure it's traded.
If
> it is, then I lost this hand, but on the next I will raise you 5 because I
> think in 10 years the entire software industry will be on its head.

I believe there are some things in the pipeline that will change the way we
all use computers, much as the GUI interface did. I also believe there is a
fairly imminent breakthrough in processing capabilities and storage
capacity, that will have a dramatic effect as well.

I would be loth to say 10 years: I think the actual catharsis will happen
sooner than that, but the effects could take 10 years to really establish
themselves.

> Unlike you, I will not be living it up on the beach...more like scrounging
> around for the $20,000 I will need to become a certified consultant ( I
need
> to start by certification company)
>

Well, at least you have a plan :-) and as the weather here is becoming
noticeably

er my beach visits are getting less frequent. Besides, I am
actually 'working' at the moment so I'm too busy anyway.

> What new is there to do? It would be more effective to write COBOL
> "entertain" the world of software library attachments.
>

It is an interesting (well to me it is interesting... :-)) fact that one of
the most eminent Physicists in the world at the time (1897), Albert
Michelson, (of Michelson - Morley fame) said that: "it seems probable that
most of the grand underlying principles [of physical science] have been
firmly established". Of course, the discovery of X-rays, radioactivity, the
electron, relativity and quantum mechanics around the turn of the 20th
century proved him wrong.

Almost without fail, every time it looks as though there is nothing left to
do, there is... :-)

of[color=darkred]
> It's an interesting question going forward. The SOA world comes with many
> of the same issues...I would expect that they would try and align with
> whatever the business model will become. Many many vendors will provide
> solutions that will embed in many and to end solutions.
>
matter[color=darkred]
COBOL.[color=darkred]
> No one thought the 80s would be

again.....
>

As I recall, the 80's were the most un

decade of the 20th century...
they saw the collapse of computer programming as an art form, the unlocking
of computer power to the masses (with consequent decline in the salaries of
professionals), the cult of 'greed is good' (started by the film, "Wall
Street" in 1987), and the death of decent music (although it had been dying
for some time)... :-)

other[color=darkred]
> There is no future for Java and there is no future for .NET either...so
> where are we going?

We are going to a world where people will teach computers to do what is
required by example, interaction, and natural language. It will be a
'one-time' process. Once the machine has learned something, it will always
be available. The internet will be wirelessly carried everywhere, and the
knowledge base will follow us around via our pocket devices. Both smart
software and human beings will have access to whatever knowledge they
require, instantaneously, and without a constraining wire connection.

>The future is, unfortunately, whatever makes big
> business money unless the "change" happens. This is a required global
> statement
>
there[color=darkred]
> Best practices are what ?
> CMM/SOA/Agile/ISD/XP/ISO/Waterfall/Re-use/Components/Linux/J2EE/.NET (I
> know I'm mixing language, environment, practices but that's kind of my
> point). Most corporations don't even understand what "metadata" or
> "enterprise architecture" or "business rules" are. It' s my experience
that
> the first business rule written down is "Business Rules cannot be changed
> and must be enforced" followed closely by the second rules "Except when
> they aren't"

Yes, it very often seems that way. It is difficult for technically competent
people to understand how non-technically competent people cannot be
interested in or aspire to learn the technology. The fact is that most of
the world's population are interested only in using technology, not how it
works. I heard some local people complaining that the call out fee to have a
computer technician come to the house and "fix" their machine is now around
$100... When I suggested they could save much of this money by learning a
few basics, they looked at me in horror... time, effort, no thanks. Just
give us a solution.

The world wants computers but, as I have observed here before, the world is
not about to become computer programmers. Not even simple languages like
COBOL. However, let them point and click or drag and drop some icons
representing files, and they will do it.

>
>
> The things that made C, C++, Java important aren't relevant either.....
>

They are at the moment, however I agree they also have a "shelf life".

> When you are retired and live in what is allegedly one of the most
beautiful
> places in the world, COBOL is the last place I would look for pleasure.

Ah, but you are not me... And I'm not retired; I only thought I was... :-)

>
> As they say, Work to live your life, don't live your life to work.
>

I have always managed to have the best of both worlds by making my work
something that I enjoy immensely. Those of us who can do that are incredibly
lucky.

> Things always look bad, then they always come good ....Frankly, I'm more
> worried about whether where I live will still be above water and heat
> bearable with water to sustain the population in 15 years more than I am
> whether Microfocus exists....we're just about ready to pass a law that
will
> allow Wallmarts to develop 10 acres of prime wetland without federal
> approval.....

You are right to consider priorities... :-)

Pete.
>
> JCE
>
>
>
>

William M. Klein

2005-04-08, 8:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3bmcbuF6i66k6U1@individual.net...
>I really wish I could agree, Bill.
>
<snip>
> No one COBOL vendor will be responsible for providing a future for COBOL.
> They may provide a limited future for their own niche market...
>
I hate to sound like "you know whom" - but between Micro Focus and IBM, I *do*
think that most platforms where new development is done and where a lot (not
majority) of business is done do have a COBOL compiler available from a vendor
seeing a future in COBOL.

> The market has already voted. There is no future for COBOL (apart from
> possible batch applications, but even these will eventually move to other
> platforms and environments.)
>
After my visit to Newbury last w

("personal" - not business), I would say
that the Micro Focus perception of "lift and shift" for existing (IBM) mainframe
applications to server and workstations is succeeding with MANY customers.

I certainly do NOT know about 15 years from now, but I would say for the rest of
this decade, the use of COBOL will expand - not contract. (Which is NOT to say
that the PERCENTAGE of applications using COBOL will epxand - only the
"absolute" number)

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

Pete Dashwood

2005-04-09, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:Tsy5e.7588303$f47.1395099@news.easynews.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3bmcbuF6i66k6U1@individual.net...
> <snip>
COBOL.[color=darkred]
> I hate to sound like "you know whom" - but between Micro Focus and IBM, I
*do*
> think that most platforms where new development is done and where a lot
(not
> majority) of business is done do have a COBOL compiler available from a
vendor
> seeing a future in COBOL.

I don't know who you mean by "you know whom" or why you wouldn't want to
sound like someone, if your opinion happens to coincide with theirs :-),
but, leaving that aside, I would agree that currently, businesses such as
you describe certainly see a future in COBOL. They have an existing
investment that they are not about to replace. However, as time passes, they
will need to replace it and market pressures will force them to examine the
options available. It starts with a single system (the famous "pilot
project") and eventually, all of the IT development is either outsourced or
packaged.

Maintaining and developing thousands of lines of source code in house just
isn't viable when you don't HAVE to.

Business processing packages are now getting pretty smart and they provide a
standardised approach that the bean counters love. IT departments require
large budgets for most corporations and there comes a point where the ROI is
simply not good enough to warrant their continuance. Of course, network
support and the help desk are essential functions but even these are being
outsourced by some companies. Commercial organisations don't WANT to be IT
providers, they just want the service to help them run their business. That
is why I believe the days of COBOL (and other procedural languages) are
limited.

One way to cut the IT budget is to get out of development and maintenance
and simply limit the IT department to a handful of network specialists and a
helpdesk. (And even these CAN be outsourced, but the cost of doing so MIGHT
warrant retaining it in house...)

There are many factors at work here, it is not just black and white. As
computer literacy grows, people expect to process their own data with
spreadsheets and local databases. The centralized control exercised by the
traditional IT department is anathema, so the business resist IT developed
systems being thrust upon them. I have seen cases where the politics of this
become really scary...

The only effective policy, in my opinion, is to keep the business onside,
not by enforcing systems and procedures, but by ensuring they are part of
whatever is developed, they have bought into it from day one, have assisted
with the development working side by side with IT, and it delivers what they
need NOW. (That is why I personally favour RAD type development over
'waterfall based' ones). The only way the IT department can survive, is if
it is perceived as an asset by the business, rather than as a 'necessary
evil'. Working in this way also ensures that local data is fed to/from
corporate systems and everybody wins.

>
other[color=darkred]
> After my visit to Newbury last w

("personal" - not business), I would
say
> that the Micro Focus perception of "lift and shift" for existing (IBM)
mainframe
> applications to server and workstations is succeeding with MANY customers.
>

Yes, it is a good policy and I wouldn't argue that doing this is extending
the life of COBOL and COBOL developed systems. However, long term, once
these systems are on the server they can be maintained with tools other than
COBOL. If they are still using the COBOL file system (rather than open
databases) their life will be limited. In a 15 year timescale I don't see
it lasting. (But I stress that that is a personal opinion from one who is
by no means infallible.) From the Microfocus POV it may well be viable to
grab the money now, or for as long as possible before the goose dies, then
go and retire in the Bahamas or somewhere equally salubrious :-). I just
don't see a long term policy based around COBOL being viable.

> I certainly do NOT know about 15 years from now, but I would say for the
rest of
> this decade, the use of COBOL will expand - not contract. (Which is NOT
to say
> that the PERCENTAGE of applications using COBOL will epxand - only the
> "absolute" number)

Well there we diverge, Bill. (I'm not sure how you define 'absolute number'
.... do you mean that more COBOL applications will be developed, but as a
percentage of all applications developed, it will not increase?). I believe
that by the end of this decade the rot will be setting in and it will start
to become apparent. (The indications are already there but policies like the
one you described ("lift and shift"), while not actually reversing it, are
certainly slowing it). In the following decade the decrease will be marked.
By 2015 it will be hard to find a business still developing in COBOL.

Neverthe less, I'd love to be wrong on this. I hope you're right.

Pete.

Pete Dashwood

2005-04-09, 3:55 am

As usual, interesting observations, Richard.

Thanks for that.

Pete.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1112989505.511658.259830@o13g2000cwo.googlegroups.com...
>
> Java as a language was an attempt to correct the errors of C++, such as
> allowing visible pointers.
>
> The Java VM developed from a need for platform independence, originally
> for embedded systems (Oak) and then generalised to desktops, browsers
> and servers.
>
> There is no need for the language to be executed on a Java VM, it can
> be compiled (with eg gcj) to non-portable executables. OTOH many
> languages will run on the Java VM and use the library.
>
>
> C# was an attempt to correct the errors of Java, such as the removal of
> visible pointers, but mainly it was to get back at Sun for not allowing
> MS to take over control of Java, so they try to replace it with one
> they do control.
>
> The CLR is a replacement for the rather arcane Windows API that, after
> 20 years, is difficult to keep working because it was not designed for
> what it currently has to do.
>
>
> Exactly. Windows API is not, it is like a 20,000 line Cobol program,
> only it is like 20,000,000 lines, all with inter-dependencies and all
> using globals. One aim of Longhorn is that everything will be based on
> CLR, or its developed version, and the existing Windows API will be an
> optional add-on, just like the OS/2 1 API was an addon to NT, and WINE
> is an add-on to Linux.
>
>

Stephen Gennard

2005-04-09, 3:55 pm

Stephen Gennard

2005-04-09, 3:55 pm

Richard

2005-04-11, 3:55 am

> I am still innocent enough to believe that Java was an attempt at
> platform independence and a single programming model for
> many diverse digital platforms. But that was not the only reason
> for it.

Java as a language was an attempt to correct the errors of C++, such as
allowing visible pointers.

The Java VM developed from a need for platform independence, originally
for embedded systems (Oak) and then generalised to desktops, browsers
and servers.

There is no need for the language to be executed on a Java VM, it can
be compiled (with eg gcj) to non-portable executables. OTOH many
languages will run on the Java VM and use the library.

> I also believe that dot NET is an attempt to provide a common
> platform (The heart of it is the CLR) that will make life easier
> for the OS.

C# was an attempt to correct the errors of Java, such as the removal of
visible pointers, but mainly it was to get back at Sun for not allowing
MS to take over control of Java, so they try to replace it with one
they do control.

The CLR is a replacement for the rather arcane Windows API that, after
20 years, is difficult to keep working because it was not designed for
what it currently has to do.

> I notice in passing that it is completely OO.

Exactly. Windows API is not, it is like a 20,000 line Cobol program,
only it is like 20,000,000 lines, all with inter-dependencies and all
using globals. One aim of Longhorn is that everything will be based on
CLR, or its developed version, and the existing Windows API will be an
optional add-on, just like the OS/2 1 API was an addon to NT, and WINE
is an add-on to Linux.

Joe Zitzelberger

2005-04-11, 3:55 pm

In article <qHp5e.24635$vd.14559@tornado.tampabay.rr.com>,
"jce" <defaultuser@hotmail.com> wrote:

> I wish I could agree......oh damn...I do mostly ;-)
>
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3bmcbuF6i66k6U1@individual.net...
>
>
> Not everything needs OO, not everything needs to talk to components. Web
> Services [a fancy way of saying nothing particularly useful] can be
> implemented as COBOL.
> Again, the language is not important. COBOL is dying because it simply
> offers no academic value or interest.

Nothing NEEDS OO -- not even components. OO is a way of thinking, and
way of designing and structuring software -- just like Structured or
Spegetti. Sure, the OO support in the language helps, but you can write
OO style in assembler if necessary.

If Web Services are a way of saying nothing useful can be done in Cobol,
why have I spent the last three years designing extensions to allow
Cobol to play nicely in the Web Services arena?

The chances are quite good in the coming year that if you use any form
of plastic payment in North America or Europe you will be supported by
Cobol based Web Services -- hardly obsolete.

>
> This group talks about life, death, etymology, and components...occasionally
> talking about how we are all lamenting the death of COBOL. If we removed
> the B, it would survive. What COBOL needs is a new marketing campaign...if
> we re-released a new language called Open Source MODE++ it would sell
> (Massive Object Data for the Enterprise language -enhanced) it would be
> taken up. I *really* believe that. The language is not the problem it's
> that such a good job was done misinforming the public.
>
> I like in to the fact that most Americans that I've personally asked (I will
> not provide evidence of everyone I asked and their response) was *not* aware
> that Russia was an ally in WW II. They cannot be convinced because the cold
> war came with such intense propaganda. People cannot see beyond what they
> have been taught to believe.

Must...Resist...Temptation...Must...Stay...On....Topic...

Joe Zitzelberger

2005-04-11, 3:55 pm

In article <1112989505.511658.259830@o13g2000cwo.googlegroups.com>,
"Richard" <riplin@Azonic.co.nz> wrote:

>
> C# was an attempt to correct the errors of Java, such as the removal of
> visible pointers, but mainly it was to get back at Sun for not allowing
> MS to take over control of Java, so they try to replace it with one
> they do control.

Java did not have visible pointers. One of its original design goals
was to remove visible pointers from C++, which they did. Everything in
Java was a handle until Micro$oft introduced their version of Java with
pointers instead of handles.

M$ claimed it was a performance improvement, Sun claimed if violated the
licensing contract requiring a compatible VM. This was a major part of
the original Sun-M$ lawsuit.

To say that M$ C# is fixing something that M$ originally broke -- well,
that reminds me of the old joke.

Q: How does Bill Gates change a light bulb?
A: He doesn't, he simply declares darkness the industry standard.

William M. Klein

2005-04-11, 3:55 pm

William M. Klein

2005-04-11, 3:55 pm

Richard

2005-04-11, 8:55 pm

>> Java as a language was an attempt to correct the errors of C++, such
as
[color=darkred]
of[color=darkred]
[color=darkred]
> Java did not have visible pointers.

Yes, that is what I said.

> To say that M$ C# is fixing something that M$ originally broke

>From Java's perspective 'allowing visible pointers [in C++]' was an
error of C++.

>From C#'s perspective 'the removal of visible pointers [from Java]' was
an 'error' of Java.

Robert Wagner

2005-04-12, 3:55 am

Pete Dashwood

2005-04-12, 3:55 am

X-Trace: individual.net T/ emx0r1HfwUbYaHZh3+AQN6HLgkTIJ1dZkO+Tb2L0
wldnZi/v
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:111390

"Joe Zitzelberger" <joe_zitzelberger@nospam.com> wrote in message
news:joe_zitzelberger-27A7D6.08280711042005@ispnews.usenetserver.com...
> In article <qHp5e.24635$vd.14559@tornado.tampabay.rr.com>,
> "jce" <defaultuser@hotmail.com> wrote:
>
also[color=darkred]
support),[color=darkred]
their[color=darkred]
a[color=darkred]
to[color=darkred]
in[color=darkred]
use[color=darkred]
Web[color=darkred]
>
> Nothing NEEDS OO -- not even components. OO is a way of thinking, and
> way of designing and structuring software -- just like Structured or
> Spegetti. Sure, the OO support in the language helps, but you can write
> OO style in assembler if necessary.
>

You certainly COULD implement OO structures using Assembler, but why WOULD
you? There are things that DO need OO and they are best implemented using
languages that support OO.

Writing recursive or reusable modules in COBOL and calling it OO is not OO.

If you call a tail a leg, how many legs has a horse? (4: calling a tail a
leg does not make it one - thanks to Abe Lincoln for that one...)

I agree that OOP is a way of thinking about things, but it goes way beyond
that.

I disagree that useful components can be written WITHOUT OO. MODULES can be
written without OO and they can be useful, but they are NOT components.

> If Web Services are a way of saying nothing useful can be done in Cobol,
> why have I spent the last three years designing extensions to allow
> Cobol to play nicely in the Web Services arena?
>

COBOL Web services have been implementable via SOAP for more than three
years now. Not sure what you have been working on. Certainly COBOL Web
Services are as good as any other kind and I have never had trouble getting
them to 'play nicely' with other services. (I wrote a SOAP based credit card
processing module in COBOL just over two years ago- the bank's computers
required SOAP because the systems accessing it were written in a number of
different languages including, (in my case) COBOL. It all worked very well.)

> The chances are quite good in the coming year that if you use any form
> of plastic payment in North America or Europe you will be supported by
> Cobol based Web Services -- hardly obsolete.
>

The Web Services providing the facility are certainly not obsolete. But the
fact that they were written in COBOL is increasingly irrelevant. Consumers
of the service will not be interested in the source code. It could just as
easily be Java or C++ or Delphi or even ASP or (probably) Perl... COBOL is
neither REQUIRED nor ESSENTIAL for writing Web Services; it simply CAN be
used, (provided you wrap it properly).
>
this[color=darkred]
on in[color=darkred]
procedural[color=darkred]
components...occasionally[color=darkred]
removed[color=darkred]
campaign...if[color=darkred]
it's[color=darkred]
will[color=darkred]
aware[color=darkred]
cold[color=darkred]
they[color=darkred]
>
> Must...Resist...Temptation...Must...Stay...On....Topic...
>
Well done! You did... :-)

Pete.

Pete Dashwood

2005-04-12, 3:55 am

Pete Dashwood

2005-04-12, 3:55 am

jce

2005-04-12, 3:55 am

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:3bnjcdF6lmihbU1@individual.net...
> An entertaining and well written post, John.

Hmmm...you have a half decent memory I'm not sure I've posted here with that
name before.

> It was such a good response I decided to respond to it :-)

Thanks - I will respond and liberally cut chunks out where I plain out
disagree with you (or I have nothing to say :0) )

More than anything this is an acknowledgment of your response and that I did
read it, and did think about ;-)

> As I mentioned earlier, the world wants faster solutions.
Unfortunately, I find to the detriment of better solutions.

> The non-COBOL world has voted with its feet.
A strange keyboard you must have :-)

> synopsis or not, the market place is embracing it and I have seen
> procedural
> code being replaced on several installations for very much the reasons
> outlined. (I actually managed one major installation where this process
> was
> taking place). It isn't emotional or a conspiracy against COBOL, it is
> just
> doing what is commercially advantageous.
I don't believe it's a conspiracy. I think you're mostly right.
To deny that executives making executive decisions actually evaluate
anything based on reality of what is commercially advantageous though is
naive. One of the focal points of SOA, and one of the drivers behind it, is
that IT groups are looking to defend themselves with "value propositions".
It looks good when you have "sophisticated reuse" without "duplication" and
a "dictionary" of available services shareable both cross client and
internally. It's a restructuring of the ideas to prove value add as a
company department. The issue surrounding licencing in general is shifting.
You take a "lower" contract value on a deal but you don't create "exclusive
licencing" of the output of contracted services. Frankly, COBOL doesn't
play well in this environment. Java plays better - for now.
What is commercially advantageous is to be a large company selling
toolsuites (PeopleSoft/SAP) or a small company selling reusable components -
the success will be on the willingness of companies to accept the
limitations of such solutions. The totally flexibility won't be there
(business rule 2 - break the business rule this once)

> in
> procedural
In specific environments. Given that we're all COBOL, I'll assume that
we're predominantly business and agree with you.
[color=darkred]
> components...occasionally
> campaign...if
>
> Here we definitely diverge. Renaming COBOL as COOL (or anything else) will
> not re-invent the language. I do not believe its decline is because of
> misinformation of the public (the public actually don't give a damn how
> computers are programmed as long as it doesn't freeze while they are
> playing
> Doom and Aunt Agatha's emails get through OK...) or even of the
> programming
> world at large, neither do I believe the marketing ploys you suggest would
> make any difference whatsoever. It's time is over. It served us all very
> well. Let it go.
> will
> aware
> cold
> Now we're back in agreement again. I certainly believe that marketing has
> a
> huge effect. But nobody actively marketed against COBOL. As for the
> gullibility or ignorance of your colleagues about history, well I don't
> see
> that really affecting COBOL very much. It reflects more on a poor
> education
> system.

I have very much let it go - in general,though I need COBOL for my current
position. I'm under no pretense that there is a large future in *new*
deployments using COBOL as the base.
Marketing has a HUGE part to play though. Java has massive licencing
revenue and the marketing power of it's "compliancy".

C# has Microsoft (which works both to its favor and detriment). SmallTalk -
hmmm.......now where did that go?

But if you ask any 19 year old what they think of COBOL they think of old
men, old "mainframes" (who needs those things that are the size of baseball
stadiums)....they don't think of the real value that they can get from
COBOL. There are some tasks that are *MUCH* easier to perform in COBOL than
any other language. Those applications are becoming fewer, however, and
therein you and I agree.

> See last sentence of above paragraph. Again, no direct bearing on COBOL
> (Man! it is really hard to stay on topic in this forum, isn't it :-)?)

snipped my digression

> Could that be because it is? :-) (I haven't got to the suspenders yet, but
> I'm certainly working on the rest of the qualifications...)
> Sorry, I know you really believe this, but I don't.
I believe the immediate growth industy is actually the middleware of the
enterprise. If that is perfected, the end tools are still irrelevant. They
will die because knowledge is being lost, and in some cases the technology
is better - the real killer for COBOL is that there isn't *enough* to really
separate it when it has competition. It's advantages *are* there, but are
probably not great enough to overcome the lack of

. I've for example,
started using FileAid to perform a lot of the simple function that was
previously code (people don't get how much can be done with tools like
Fileaid, DFSORT, Perl).

> Time will tell, of course, but I tend to agree that it probably is not
> sustainable.
I remember when LendingTree.com was written up as a dot.boom on
startup....and it's still going. So time *will* tell.

> Yes, I find to my amazement that just as I was ready to go out to pasture,
> my skills are in demand in this area.
If I were ready for pasture, I think I'd just go - skill be damned ]:-> I
recently saw the first new ad...."Business Consulting....the *other* IBM"

> Agreed. As a current TV campaign here observes: "Without small business
> there would be no big business."
Hmmm. We don't get that one here. We get the "small business can be big
business with Cialis, Viagra, Lavitra...."

> need to start by certification company)
> Well, at least you have a plan :-) and as the weather here is becoming
> noticeably

er my beach visits are getting less frequent. Besides, I am
> actually 'working' at the moment so I'm too busy anyway.
My real plan is to sell my house, setup a community and live the slightly
less-religiously fervent version of Gerrard Winstanley. If this didn't
cross my mind on a given day I would be surprised.

> It is an interesting (well to me it is interesting... :-)) fact that one
> of
> the most eminent Physicists in the world at the time (1897), Albert
> Michelson, (of Michelson - Morley fame) said that: "it seems probable that
> most of the grand underlying principles [of physical science] have been
> firmly established". Of course, the discovery of X-rays, radioactivity,
> the
> electron, relativity and quantum mechanics around the turn of the 20th
> century proved him wrong.
And recently they proved Einstein right when he himself had apologised for
getting it wrong...go figure.

> We are going to a world where people will teach computers to do what is
> required by example, interaction, and natural language. It will be a
> 'one-time' process. Once the machine has learned something, it will always
> be available. The internet will be wirelessly carried everywhere, and the
> knowledge base will follow us around via our pocket devices. Both smart
> software and human beings will have access to whatever knowledge they
> require, instantaneously, and without a constraining wire connection.
Party over in Hackerville...

> Yes, it very often seems that way. It is difficult for technically
> competent
> people to understand how non-technically competent people cannot be
> interested in or aspire to learn the technology. The fact is that most of
> the world's population are interested only in using technology, not how it
> works. I heard some local people complaining that the call out fee to have
> a
> computer technician come to the house and "fix" their machine is now
> around
> $100... When I suggested they could save much of this money by learning a
> few basics, they looked at me in horror... time, effort, no thanks. Just
> give us a solution.
One could argue that a few golf lessons would work better than the new
latest greatest driver...
One could argue that self confidence would be cheaper than Rogaine...
I'm guilty though...I know nothing about cars...I pay $$$ to have some guy
stick a machine in it and tell me I"m good.
I get ripped off by handymen everytime I have a problem because I *don't*
know how much they should charge...if it costs less than it would cost me at
$35 / hour + material - I let them do it.
I'm the one who helps everyone I know - of course I don't get $100. I get
gratitude and a beer.....that's often good enough for me.

> I have always managed to have the best of both worlds by making my work
> something that I enjoy immensely. Those of us who can do that are
> incredibly
> lucky.
Deja vu here. I think this is something we've shared before.
[color=darkred]
Aye...there is always hope. I tell myself that every day
[color=darkred]
JCE

James J. Gavan

2005-04-12, 8:55 am

In-Reply-To: <joe_zitzelberger-27A7D6.08280711042005@ispnews.usenetserver.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 171
Message-ID: <xDL6e.972774$6l.404541@pd7tw2no>
Date: Tue, 12 Apr 2005 08:27:09 GMT
NNTP-Posting-Host: 24.71.223.147
X-Complaints-To: abuse@shaw.ca
X-Trace: pd7tw2no 1113294429 24.71.223.147 (Tue, 12 Apr 2005 02:27:09 MDT)
NNTP-Posting-Date: Tue, 12 Apr 2005 02:27:09 MDT
Organization: Shaw Residential Internet
Xref: newsfeed-west.nntpserver.com comp.lang.cobol:111418

Joe Zitzelberger wrote:
>
> Nothing NEEDS OO -- not even components. OO is a way of thinking, and
> way of designing and structuring software -- just like Structured or
> Spegetti. Sure, the OO support in the language helps, but you can write
> OO style in assembler if necessary.
>
OK - so how would you tackle the following in an easy fashion using
either Procedural COBOL or Assembler for that matter.

Problem : Display a Treeview with 'n' Levels. The purpose being to
select individual elements, add, change, move or delete and ensure the
same action occurs against COBOL files or DB Tables. When initially
loading the Treeview it shows a RED Icon, (Unactioned) for each element
in the Tree. When records are added, changed or moved, a GREEN Icon
(Updated) is substituted and a flag is also set in the appropriate
file/DB. Next time the Treeview is loaded from the database it will
show both GREEN and RED icons.

There is no limit on the number of elements for a particular Level
ranging from 0 to 'n'.

I said above 'n' levels - for practical purposes I've set the limit to
10 Levels, but that can easily be increased to 20, 30 etc... (Some
Treeview !). Having changed subsidiary elements to GREEN you then need
to ripple up through the Treeview to see if lower-numbered 'parent'
Levels can be changed from RED to GREEN, eventually all the way to the
top with the exception of the Root = Level 0 :-

*>---------------------------------------------------------------
OBJECT-STORAGE SECTION.
*>---------------------------------------------------------------
copy "\copylib\dlgparams.cpy" replacing ==(tag)== by ==Dialog==.
copy "dlgchoice.cpy".

01 ws-ElementFlag pic x(4) comp-5.
88 ElementActioned value 1.
88 ElementNotActioned value 2.

78 MaxCurrent value 3.
78 MaxLevels value 10.
78 TextLength value 100.

01 ErrorFlag pic 9(03) value 0.
88 ContinueProgram value 0.
88 CancelProgram value 99.

01 ws-IconID pic x(4) comp-5.
01 ws-IconIndex pic x(4) comp-5.

*> OBJECTS

01 os-Callback object reference value null.
01 os-collection object reference value null.
01 os-CurrentTvItem object reference value null.
01 os-MakeAstring object reference value null.

01 os-Objects. *> these are returned from "AppHouse"

05 os-ChoiceDialog object reference.
05 os-DBI occurs MaxLevels object reference.
05 os-TvControl object reference.
05 os-TvDialog object reference.
05 os-TvPopup object reference.

*>------------------------------------------------------------
Method-id. "checkIcons".
*>-------------------------------------------------------------
01 n pic x(4) comp-5.
01 ls-LevelNumber pic x(4) comp-5.
01 ls-size pic x(4) comp-5.
01 ls-Ancestor object reference.
01 ls-string object reference.
01 ls-Object object reference.

Linkage section.
01 lnk-LevelNumber pic x(4) comp-5.
01 lnk-Ancestor object reference.

Procedure Division using lnk-LevelNumber, lnk-Ancestor.

move lnk-LevelNumber to ls-LevelNumber
set ls-object to lnk-Ancestor
invoke ls-object "getLabel" returning ls-string
invoke ls-object "GetNormalImage" returning ws-IconIndex
invoke ls-object "getItems" returning os-Collection
invoke os-Collection "size" returning ls-size

if ls-size = zeroes
perform SINGULAR-RECORD

else perform MULTIPLE-RECORDS
End-if

EXIT METHOD.

MULTIPLE-RECORDS.

if os-Callback = null
invoke Callback "new"
using self "checkIcons-2 " returning os-Callback
End-if

move 1 to ws-ElementFlag
invoke os-collection "do" using os-Callback

move ws-ElementFlag to ws-IconID

if ws-IconID = ws-IconIndex *> both set to GREEN or both RED
EXIT METHOD

else invoke ls-object "setNormalImage" using ws-IconID
invoke ls-object "setSelectedImage" using ws-IconID
invoke os-Dbi(ls-LevelNumber) "updateParentRecord"
using ws-IconId, ls-object
subtract 1 from ls-LevelNumber

if ls-LevelNumber <> 0
invoke ls-Object "getAncestor" returning ls-Ancestor
invoke self "checkIcons"
using ls-LevelNumber, ls-Ancestor
End-if
End-if

Pete Dashwood

2005-04-12, 3:55 pm

"jce" <defaultuser@hotmail.com> wrote in message
news:bEI6e.60298$Fz.24378@tornado.tampabay.rr.com...
> "Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
> news:3bnjcdF6lmihbU1@individual.net...
>
> Hmmm...you have a half decent memory I'm not sure I've posted here with
that
> name before.
>
.."In my youth" said the sage
With a nod of his head
"I kept my memory supple
By the use of this ointment,
One shilling the box...
Allow me to sell you a couple!"

(Apologies to Charles Lutwidge Dodgson...:-))

I used to have a photographic memory...now I only have flashes...

>
> Thanks - I will respond and liberally cut chunks out where I plain out
> disagree with you (or I have nothing to say :0) )
>
> More than anything this is an acknowledgment of your response and that I
did
> read it, and did think about ;-)
>

Thanks for that.

> Unfortunately, I find to t