Cobol - J4 - presentation/discussion on "Future of the COBOL Standard"

Author

J4 - presentation/discussion on "Future of the COBOL Standard"

William M. Klein

2008-03-09, 6:55 pm

I thought that some (many?) of those who watch CLC would be interested in a
paper that was just put out on the J4 website. The following are the "foils"
for a Micro Focus presentation scheduled for next Wednesday, March 12. If
anyone reading this newsgroup has comments that they would like included in the
discussion, you probably could still send them to the J4 chair (before Tuesday)
and ask that they be included in the discussion. You can send such comments to:

bobkarlin <at> karlinskorner.com

and you may want to CC one of the presenters and ask for your views to be
included in the discussion. If so, CC:

John.Billman <at> microfocus.com

The presentation foils are:

08-0034 - Future of the COBOL Standard (Billman)

available at:

http://www.cobolstandard.info/j4/files/08-0034.pdf

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

Pete Dashwood

2008-03-10, 3:55 am

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:HAXAj.5290$FE.820@fe05.news.easynews.com...
>I thought that some (many?) of those who watch CLC would be interested in a
>paper that was just put out on the J4 website. The following are the
>"foils" for a Micro Focus presentation scheduled for next Wednesday, March
>12. If anyone reading this newsgroup has comments that they would like
>included in the discussion, you probably could still send them to the J4
>chair (before Tuesday) and ask that they be included in the discussion.
>You can send such comments to:
>
> bobkarlin <at> karlinskorner.com
>
> and you may want to CC one of the presenters and ask for your views to be
> included in the discussion. If so, CC:
>
> John.Billman <at> microfocus.com
>
> The presentation foils are:
>
> 08-0034 - Future of the COBOL Standard (Billman)
>
> available at:
>
> http://www.cobolstandard.info/j4/files/08-0034.pdf
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com

I won't be copying Bob Karlin, but here's what I think, anyway :-)

As COBOL is fundamental to MicroFocus' core business it is understandable
they would want to try and rejuvenate or re-invent it.

I think their idea to rejuvenate the standard is not a bad one, but to
expect COBOL to move into a world of objects and components, when there is
no user interest in the OO features of it, is simply myopic.

Line by line development and maintenance of code is non-viable as a forward
strategy, and the only place where there is likely to be a COBOL market for
some time yet is in Legacy and re-factoring or re-wrapping Legacy so it can
run in modern environments like .NET/Mono.

Any new standard should be stressing support for building OO components in
COBOL. As there is no user demand for that, there is little point in doing
it.

Doing what there IS user demand for (pretty much "same old, same old"),
while commendable on the part of MicroFocus, is expensive and ultimately
pointless. COBOL users (for the most part...) are currently out of touch
with IT reality. The people who are demanding features like XML support
haven't realised that the world has already moved on and XML is almost
obsolete. Sure let's cater for bigger numbers... (does it REALLY matter?)
The demands of the (rapidly dwindling) COBOL community are really not worth
catering to in the hopes of future long term revenue generation.

It's like Mediaeval scribes demanding better quality parchment and goose
feathers, while Gutenburg is building his printing press.

Despite the claim of billions of lines of existing code (dubious at best; it
has been eroded yearly for the last 5 years (at least...) at a rate of
millions of lines every year, by replacement with packaged solutions,
refactoring, and migration to Java and other solutions...), even the most
optimistic observer cannot see an expanding future for COBOL as a procedural
paradigm based language in a world that is increasingly more visual and more
non-procedural.

If I were MicroFocus, I'd be doing some focusing on transport/migration
mechanisms for COBOL, leveraging and re-factoring tools, and support for
visually building COBOL components that can play nicely with other languages
on level playing fields, like .NET.

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

>

tim

2008-03-10, 3:55 am

On Mon, 10 Mar 2008 17:07:03 +1300, Pete Dashwood wrote:

> I won't be copying Bob Karlin, but here's what I think, anyway :-)
>
> I think their idea to rejuvenate the standard is not a bad one, but to
> expect COBOL to move into a world of objects and components, when there is
> no user interest in the OO features of it, is simply myopic.
>

I tend to agree - a new standard should be looking to take the rough edges
off and not much more. 2002 was a huge over-reach. There is no constituency
for major new additions to COBOL, as evidenced by the fact 2002 has not
been fully implemented by anybody.

Agree with you about XML also. XML was possibly exciting in about 1999. In
practice it is very cumbersome to use, and I don't see the XML proposals
for COBOL solving this.

COBOL is not a good candidate for running on JVMs and .NET due to
technical problems ie use of redefine and pointers (which are in effect
arbitrary redefines), also packed decimal which is not well supported off
the mainframe. You can make it work, but it will run slowly.

> Line by line development and maintenance of code is non-viable as a forward
> strategy, and the only place where there is likely to be a COBOL market for
> some time yet is in Legacy and re-factoring or re-wrapping Legacy so it can
> run in modern environments like .NET/Mono.
>
> Despite the claim of billions of lines of existing code (dubious at best; it
> has been eroded yearly for the last 5 years (at least...) at a rate of
> millions of lines every year, by replacement with packaged solutions,
> refactoring, and migration to Java and other solutions...), even the most
> optimistic observer cannot see an expanding future for COBOL as a procedural
> paradigm based language in a world that is increasingly more visual and more
> non-procedural.
>

I would suggest, without having proof, that there are probably more lines
of code being written per year across all languages than ever before.
Packages and components are very useful but a lot of code is still needed.

My observation of big companies is that the COBOL base is going away very
slowly. I have seen things replaced by packages, but a lot of the packages
were written some time ago, in a language called COBOL.

It is hard to replace a custom application that is deeply embedded into
your business processes with a package. Look at the many debacles with SAP
implementations for some examples.

If the 200bn lines of code number is anywhere near right, the dollars
involved in replacing them is frightening. The cost is probably in the
$10-50 trillion dollar range.

Tim

Pete Dashwood

2008-03-10, 7:55 am

"tim" <TimJ@internet.com> wrote in message
news:13t9o34h59fed18@corp.supernews.com...
> On Mon, 10 Mar 2008 17:07:03 +1300, Pete Dashwood wrote:
>
>
> I tend to agree - a new standard should be looking to take the rough edges
> off and not much more. 2002 was a huge over-reach. There is no
> constituency
> for major new additions to COBOL, as evidenced by the fact 2002 has not
> been fully implemented by anybody.
>
> Agree with you about XML also. XML was possibly exciting in about 1999. In
> practice it is very cumbersome to use, and I don't see the XML proposals
> for COBOL solving this.
>
> COBOL is not a good candidate for running on JVMs and .NET due to
> technical problems ie use of redefine and pointers (which are in effect
> arbitrary redefines), also packed decimal which is not well supported off
> the mainframe. You can make it work, but it will run slowly.
>
>
> I would suggest, without having proof, that there are probably more lines
> of code being written per year across all languages than ever before.
> Packages and components are very useful but a lot of code is still needed.

Yes, that is certainly true right now. But things are changing, and the rate
of change is accellerating.
>
> My observation of big companies is that the COBOL base is going away very
> slowly. I have seen things replaced by packages, but a lot of the packages
> were written some time ago, in a language called COBOL.

Hmmm... I won't argue that one, because I really don't know, and I haven't
been at the coal face for a couple of years. (I expect to be back there
soon... :-)) Certainly, Peoplesoft I believe is COBOL based, IBM's HUON
solution is too, and there are probably a few other corporate ones that were
originally built for mainframes. There is a large installed base (at least
in lines of code) for these packages and they are backed by large
corporations like IBM, but that doesn't mean they can't also be eroded like
so many on-site tailored corporate COBOL solutions.
>
> It is hard to replace a custom application that is deeply embedded into
> your business processes with a package.

It is if you don't change the Business... :-) Many places are finding it is
actually cheaper to standardise their processes and procedures on a package
that provides consistent results across all branches, than to keep on
grinding out bespoke software.

But, I believe the biggest thing that prevents COBOL being a strong player
for the future, is that more and more systems need to be web based, and
that's an area where components are definitely required. Consequently, COBOL
is perceived as not playing well there. (I find this ironic, because I used
OO COBOL to develop some pretty smart web sites at a time when nobody did
that or even thought it was possible (...apart from Richard Plinston who was
using COBOL to drive CGI when most people here thought the Web was just a
passing fad...:-))).

Having grown used to C# and ASP.NET I can't honestly say I'd easily go back
to COBOL for web development, but I am certainly not blind to the fact that
OO COBOL can be very useful in this area.

> Look at the many debacles with SAP
> implementations for some examples.
>

Yes, I have actually been required to look at some of them :-)

However, there are also many successful SAP and Siebel installations, and I
haven't heard about too many recent SAP debacles. I was in Germany when SAP
was first developed (early 1970s) and worked (around 1977) on one of the
first major sites to evaluate it. It was written in IBM Assembler and was
pretty appalling, we thought. We rejected it, but Systems, Applications, and
Products in Data Processing (in Mannheim, Germany) went ahead undeterred and
the rest is history. It is fair to say that the SAP of 2008, is a far cry
from the SAP of 1978, or even of 1998...

> If the 200bn lines of code number is anywhere near right, the dollars
> involved in replacing them is frightening. The cost is probably in the
> $10-50 trillion dollar range.

Well, first, I don't believe it is even close. (I haven't seen any credible
sources; Gartner have a vested interest in supporting a large COBOL base,
although, as it has eroded, they have been less vociferous, and MicroFocus
also have a vested interest in portraying COBOL as a major player (whether
it is or not)).

Second, even if it were, it isn't about "replacement cost" as mostly it
isn't done with a Big Bang replacement. The cost of converting data and
code, or migrating systems, is part of the ongoing "maintenance" cost which,
as we all know, is the major cost for computer systems anyway.

The cost of NOT moving away from COBOL could be even more astronomical...

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

Howard Brazee

2008-03-10, 9:56 pm

On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@internet.com> wrote:

>COBOL is not a good candidate for running on JVMs and .NET due to
>technical problems ie use of redefine and pointers (which are in effect
>arbitrary redefines), also packed decimal which is not well supported off
>the mainframe. You can make it work, but it will run slowly.

Why does being able to use packed decimal make CoBOL a poor candidate?
If it doesn't fit in your environment, there's no requirement that it
has to be used.

Howard Brazee

2008-03-10, 9:56 pm

On Tue, 11 Mar 2008 00:47:46 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Yes, that is certainly true right now. But things are changing, and the rate
>of change is accellerating.

Something in that wording sounds wrong to me. But I can't say that
it is wrong. If a rate of change is accelerating is that like saying
a velocity is accelerating? Is it the same as saying "change is
accelerating"? I'm not sure.

>But, I believe the biggest thing that prevents COBOL being a strong player
>for the future, is that more and more systems need to be web based, and
>that's an area where components are definitely required. Consequently, COBOL
>is perceived as not playing well there.

I still think of systems as data based. The web part is the I/O for
the type of work I do. But databases don't need CoBOL either.

tlmfru

2008-03-10, 9:56 pm

tim <TimJ@internet.com> wrote in message
news:13t9o34h59fed18@corp.supernews.com...

> Despite the claim of billions of lines of existing code (dubious at best;
it
> has been eroded yearly for the last 5 years (at least...) at a rate of
> millions of lines every year, by replacement with packaged solutions,
> refactoring, and migration to Java and other solutions...), even the most
> optimistic observer cannot see an expanding future for COBOL as a
procedural
> paradigm based language in a world that is increasingly more visual and
more
> non-procedural.
>

(Tongue in ch

!)

I dunno. Looked at in one way there has been nothing new in computing for a
long, long time. Way back when, the Whirlwind and other pioneering machines
had a very small instruction set - often just 32 instructions. This of
course expanded as time went by until somebody invented the RISC concept -
cutting down the number and complexity of the instructions. The first
mass-storage devices used fixed-length records, short sectors, and absolute
addressing. Twenty years later, IBM reinvented the same thing but callled
it FBA. Once upon a time there was a central machine and dumb terminals.
This was reintroduced as client-server (I think so anyway, because I have
never seen a standard definition). There used to be service bureaux: now
it's software as a service and computing on demand, or even the cloud. So
who knows? Procedural programming is not dead yet, nor is Cobol: we only
have to wait for someone to repackage it as the Next Great Thing. What
would be great is to be that someone. The riches, the guru status!

PL

tlmfru

2008-03-10, 9:56 pm

As recently as last year, I worked with someone who insisted that PD had to
be used as it was faster. (In fact she dropped me from the project when I
didn't agree). On the Univac machines we both worked on (DECADES ago), it
was true - well in the IBM 360 architecture-dominated world it certainly
was - but that of course ceased to be s o many years ago. But there are
still people who haven't kept up to date, even on something as simple as
this, and such-like may insist on keeping things static.

People get such odd obsessions. Some manufacturer - Honeywell, I think -
came up with a proprietory silicon on sapphire memory structure. It
worked - it had to! But for a time there was a group of consultants who put
in their RPQ's the requirement that the proposed machine must have silicon
on sapphire memory. How that would have affected processing their payrolls
or other mission-critical systems was never made out!

PL

Howard Brazee <howard@brazee.net> wrote in message
news:takat3hnac8rubopu84tofpqvq4j0vi8h5@
4ax.com...
> On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@internet.com> wrote:
>
>
> Why does being able to use packed decimal make CoBOL a poor candidate?
> If it doesn't fit in your environment, there's no requirement that it
> has to be used.

Robert

2008-03-10, 9:56 pm

On Mon, 10 Mar 2008 09:27:08 -0600, Howard Brazee <howard@brazee.net> wrote:

>On Tue, 11 Mar 2008 00:47:46 +1300, "Pete Dashwood"
><dashwood@removethis.enternet.co.nz> wrote:
>
>
>Something in that wording sounds wrong to me. But I can't say that
>it is wrong. If a rate of change is accelerating is that like saying
>a velocity is accelerating? Is it the same as saying "change is
>accelerating"? I'm not sure.

Both. It's the second derivative, written f'(x). In the example of a moving car, speed
f(p) is the rate of change of its position, acceleration f'(p) is the rate of change of
speed.

A non-zero second derivative implies the original function (if it is a function) is of at
least 2nd degree.

>
>I still think of systems as data based. The web part is the I/O for
>the type of work I do. But databases don't need CoBOL either.

Data are nouns. Cobol is based on verbs (perform, move), as is SQL (select, update).
Object oriented languages are based on nouns.

Frank Swarbrick

2008-03-10, 9:56 pm

>>> On 3/9/2008 at 2:16 PM, in message
<HAXAj.5290$FE.820@fe05.news.easynews.com>, William M.
Klein<wmklein@nospam.netcom.com> wrote:
> I thought that some (many?) of those who watch CLC would be interested in

> a
> paper that was just put out on the J4 website. The following are the
> "foils"
> for a Micro Focus presentation scheduled for next Wednesday, March 12.
> If
> anyone reading this newsgroup has comments that they would like included
> in the
> discussion, you probably could still send them to the J4 chair (before
> Tuesday)
> and ask that they be included in the discussion. You can send such
> comments to:
>
> bobkarlin <at> karlinskorner.com
>
> and you may want to CC one of the presenters and ask for your views to
> be
> included in the discussion. If so, CC:
>
> John.Billman <at> microfocus.com
>
> The presentation foils are:
>
> 08-0034 - Future of the COBOL Standard (Billman)
>
> available at:
>
> http://www.cobolstandard.info/j4/files/08-0034.pdf

I am perplexed by some of the things they don't think would be useful to the
average Cobol programmer. Variable length fields and (dynamic capacity)
tables are features that I personally think would be very useful! Seems
that exception handling could use a rework, but why eliminate RESUME. I've
never really understood how Cobol 2002 exception handling is suppose to work
anyway...

Frank

Charles Hottel

2008-03-10, 9:56 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:nikat3tj211nuovo8kmmbdplfvmoddosb9@
4ax.com...
> On Tue, 11 Mar 2008 00:47:46 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> Something in that wording sounds wrong to me. But I can't say that
> it is wrong. If a rate of change is accelerating is that like saying
> a velocity is accelerating? Is it the same as saying "change is
> accelerating"? I'm not sure.
>
>
> I still think of systems as data based. The web part is the I/O for
> the type of work I do. But databases don't need CoBOL either.

I can't speak for waht Pete Dashwood meant, but imagine an exponential
equation that specifies a rate of change. Next imagine that the exponent in
the equation is itself varying at an exponential rate.

Pete Dashwood

2008-03-10, 9:56 pm

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:13tblldk2f3m41c@corp.supernews.com...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
> news:nikat3tj211nuovo8kmmbdplfvmoddosb9@
4ax.com...
>
> I can't speak for waht Pete Dashwood meant, but imagine an exponential
> equation that specifies a rate of change. Next imagine that the exponent
> in the equation is itself varying at an exponential rate.

Thanks Charlie, you and Robert both correctly interpreted what I was saying.

Perhaps I should have said: " But things are changing, and the rate of
change is speeding up." I just don't like using two words where one will
do... :-) Perhaps "increasing" would have done. Anyway, I'm sure my meaning
is now clear.

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

Robert

2008-03-10, 9:56 pm

On Mon, 10 Mar 2008 17:12:04 -0600, "Frank Swarbrick" <Frank.Swarbrick@efirstbank.com>
wrote:

><HAXAj.5290$FE.820@fe05.news.easynews.com>, William M.
>Klein<wmklein@nospam.netcom.com> wrote:
>
>
>I am perplexed by some of the things they don't think would be useful to the
>average Cobol programmer. Variable length fields and (dynamic capacity)
>tables are features that I personally think would be very useful!

The average Cobol programmer has avoided Occurs Depending On for 22 years. It's unlikely
he or she will use any-length items and dynamic-capacity tables.

This may be a clue to Micro Focus' position:
"Some OO programming languages perform garbage collection at run time, that is, they
automatically destroy objects that are no longer in use. OO COBOL does not provide garbage
collection."

Server Express v5 manual

Rick Smith

2008-03-10, 9:56 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:63jqf7F27lussU1@mid.individual.net...

[snip]

> Despite the claim of billions of lines of existing code (dubious at best;
it
> has been eroded yearly for the last 5 years (at least...) at a rate of
> millions of lines every year, by replacement with packaged solutions,
> refactoring, and migration to Java and other solutions...), even the most
> optimistic observer cannot see an expanding future for COBOL as a
procedural
> paradigm based language in a world that is increasingly more visual and
more
> non-procedural.

Just a couple of notes from an "optimistic observer". <g>

"COBOL (COmmon Business Oriented Language) is the
programming language most widely used for commercial
and administrative data processing." -- Micro Focus LRM,
probably from the COBOL 85 standard.

The most common paradigm for "commercial and
administrative data processing" is "clerks performing
procedures on or with data". COBOL came into existence as
a domain-specific language for impementing that paradigm.
Regardless of the implementation paradigm (procedural, OO,
functional, etc.) the result will neccesarily reflect the underlying
procedural basis for the required data processing. I suspect
that a great deal of programming with OOPLs is procedural
programming; but incorrectly claimed to be OO.

The expanding role for COBOL comes from the addition of
general-purpose programming language features in 2002;
features that complement the domain-specific features. Once
the general-purpose features become widely available and
discussed, more "multilingual" programmers can become
comfortable with "I can do that in COBOL".

tim

2008-03-10, 9:56 pm

On Mon, 10 Mar 2008 09:20:46 -0600, Howard Brazee wrote:

> On Mon, 10 Mar 2008 07:16:52 -0000, tim <TimJ@internet.com> wrote:
>
>
> Why does being able to use packed decimal make CoBOL a poor candidate?
> If it doesn't fit in your environment, there's no requirement that it
> has to be used.

If the program you are compiling says packed-decimal the standard says it
must be stored in packed decimal format. Of course you can provide
optimization flags that allow this rule to be overridden in the name
of speed. But with redefines and pointers/linkage it gets very difficult to
maintain correctness in the generated code if you change the format from
packed decimal to binary for example.

Packed decimal is mostly about the same speed as binary on IBM mainframes,
but it's a lot slower than binary on most Unix/PC CPUs. Packed decimal is
a lot faster than display format on mainframes for arithmetic, due to lack
of microcode support for most arithmetic operations performed on display
format data.

Tim

Pete Dashwood

2008-03-11, 7:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13tbq3hb852cjc9@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:63jqf7F27lussU1@mid.individual.net...
>
> [snip]
>
> it
> procedural
> more
>
> Just a couple of notes from an "optimistic observer". <g>

Other viewpoints always welcomed by me... :-)
>
> "COBOL (COmmon Business Oriented Language) is the
> programming language most widely used for commercial
> and administrative data processing." -- Micro Focus LRM,
> probably from the COBOL 85 standard.

Well, as it is the core of their business, they WOULD say that, wouldn't
they? :-)

I don't believe it is even true today, but I can't prove it so won't argue
it.

>
> The most common paradigm for "commercial and
> administrative data processing" is "clerks performing
> procedures on or with data". COBOL came into existence as
> a domain-specific language for impementing that paradigm.

Not exactly as I recall... and I was there :-)

COBOL's major attraction was that it offered an "easily maintainable,
platform independent" approach to "data processing". It is true that it
was about "performing procedures on or with data" but it also offered
freedom from being locked in to a specific vendor (at least, that was a
major perceived benefit; in practice, it was not so easy to switch
vendors...) People were more excited by COBOL at a technical level than at a
functional level.

And, in those days, the concept of online interaction was not a
consideration. All processing was deferred Batch processing. There weren't
even random access devices; data was stored and processed sequentially on
tapes. These were the roots of COBOL. We have come a long way since. True,
when inteeractive devices became available, COBOL was enhanced to
accommodate them, but the strength of the language was, and is, sequential
batch processing.

It is not COBOL's "fault" that it is not so good at interactive processing.
For years it was "the only game in town". Then came new approaches to
programming and processing. The Object paradigm arrived and, again, COBOL
was enhanced to accommodate it. A fantastic feat of software engineering,
but wasted because of the limited vision of the COBOL community who
perceived it as just a fashion statement, unnecessary, and really just
"modular programming, re-invented". The reality was that entrenched COBOL
systems were doing most of the backbone processing and this led to a smug
attitude on the part of COBOL practitioners who couldn't see COBOL being
replaced any time soon... They had not factored the global effect and power
of the Internet into their calculations... Within a decade, thousands of
COBOL programmers were jobless, and COBOL fell from being the No. 1 most
popular language for developing commercial computer systems, to being
outside the top 12 programming languages, according to a number of
independent surveys.
(http://www.scriptol.org/choose.php
http://www.tiobe.com/index.php/cont...tpci/index.html
http://www.devtopics.com/most-popul...ming-languages/)

The rest of the world, not having been indoctrinated into the procedural
paradigm, rushed to embrace the non-procedural paradigm and it was found
ideal for distributed, encapsulated processing. New languages, designed
specifically for building Object Oriented systems emerged. They weren't
"self documenting" and "easily maintainable" in the sense that COBOL was,
and neither did they need to be. They were far more powerful and required
less coding, and components built with them could be easily re-used. If
something didn't work it didn't need to be "maintained", it could simply be
discarded and rebuilt, quickly and easily. By the 21st century, visual tools
capable of generating these objects were available, and today they are
increasing in power exponentially, while COBOL is still tied to line by line
coding and green screen editing.

COBOL, as a language, was simply overtaken by events.

> Regardless of the implementation paradigm (procedural, OO,
> functional, etc.) the result will neccesarily reflect the underlying
> procedural basis for the required data processing. I suspect
> that a great deal of programming with OOPLs is procedural
> programming; but incorrectly claimed to be OO.

Maybe, but that is an academic argument. It doesn't matter what you call it,
the fact is that the new languages can be written quicker, re-written
quicker, require much less code, and have facilities that COBOL simply
doesn't. Whether they are doing procedural processing under the guise of OO
or not is immaterial; they can be generated to do it quicker than a good
COBOL programmer can code the thousands of lines it takes.

I have been astounded at the encapsulated functionality in languages like
C#, that simply isn't available in COBOL. It doesn't even matter what the
paradigm is, it is quicker to point and click in Visual Studio, than it is
to write hundreds of lines of COBOL in ISPF. End of story.

>
> The expanding role for COBOL comes from the addition of
> general-purpose programming language features in 2002;
> features that complement the domain-specific features. Once
> the general-purpose features become widely available and
> discussed, more "multilingual" programmers can become
> comfortable with "I can do that in COBOL".

I understand what you're saying, Rick, but I contend that they won't. I know
from my own experience (somewhat like being dragged kicking and screaming
into Java and C#) that the desire to go back to COBOL diminishes with the
increasing understanding and facility in OO languages. Yes, I COULD develop
web applications in OO COBOL, yes, I COULD write OO COBOL components, but I
won't and don't. (I did for many years and felt like a "voice in the
wilderness" receiving scorn and vitriol from most of the COBOL community
when I suggested that OO might be important for COBOL, and a total lack of
support from COBOL vendors when problems arose. Nowadays when I have a
problem, I don't need or want to go to MicroSoft; there are around 60
million people writing C#... I can get a GOOGLEd solution in minutes. Also,
the demonstrated attitude of the C# community is a helpful and positive one
in the C# forums I have used...) I just don't believe that once
"multilingual" programmers go away from COBOL, they will need or want to go
back to it.

The "new" features in COBOL, even if they could be implemented, are not
going to make any difference.

I respect MicroFocus for taking a hand in the standards debacle and I
honestly wish them well. Whether they are driven by commercial necessity or
a genuine desire to improve COBOL, what they are doing is commendable.

Unfortunately, I believe it is too late.

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

Howard Brazee

2008-03-11, 6:56 pm

On Mon, 10 Mar 2008 20:47:40 -0400, "Charles Hottel"
<chottel@earthlink.net> wrote:

>I can't speak for waht Pete Dashwood meant, but imagine an exponential
>equation that specifies a rate of change. Next imagine that the exponent in
>the equation is itself varying at an exponential rate.

That is singularity type changes. Or maybe just hyperbole.

Howard Brazee

2008-03-11, 6:56 pm

On Tue, 11 Mar 2008 02:08:27 -0000, tim <TimJ@internet.com> wrote:

>
>If the program you are compiling says packed-decimal the standard says it
>must be stored in packed decimal format. Of course you can provide
>optimization flags that allow this rule to be overridden in the name
>of speed. But with redefines and pointers/linkage it gets very difficult to
>maintain correctness in the generated code if you change the format from
>packed decimal to binary for example.

If the data are packed, then it doesn't matter what language is being
used - it has to handle the data.

If the data aren't packed, then it doesn't matter what language is
being used - it has to handle the data.

But if you are starting from scratch, if you don't wish to use packed
decimal. Then don't. Even if you're programming in CoBOL.

>Packed decimal is mostly about the same speed as binary on IBM mainframes,
>but it's a lot slower than binary on most Unix/PC CPUs. Packed decimal is
>a lot faster than display format on mainframes for arithmetic, due to lack
>of microcode support for most arithmetic operations performed on display
>format data.

On IBM mainframes I use packed-decimal for efficiency purposes. On
Windows machines, I don't.

Just because CoBOL knows how to handle packed decimal, doesn't mean I
have to use it when I program in CoBOL.

It doesn't make sense to switch from CoBOL to avoid using
packed-decimal.

That said - I know of people who argued shops should switch from CoBOL
to PL/I for a very similar reason. They liked PL/I because it had
bounds checking on tables. But they could have had bounds checking
on their CoBOL programs by changing a switch on their compilers. I
guess it was easier to persuade management to switch languages than it
was to change the standard created by a long-gone systems programmer.

Idiocy.

Howard Brazee

2008-03-11, 6:56 pm

On Wed, 12 Mar 2008 00:38:37 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Unfortunately, I believe it is too late.

Except for those of us whose best skills are CoBOL, I don't see that
this is particularly unfortunate. Adapting CoBOL, or for that
matter C is not necessarily the best way to build new tools for our
new needs.

Kind of like the old idea of building a robot who drives a car just
like a chauffeur, sitting in the driver's seat, turning his head
around to see behind him, and stepping on the throttle. Or for that
matter, designing a one person car to run just like a horse.

Sometimes starting over will create a better product.

(I wish computers had been designed from scratch to store data with
GMT in all their time-date-stamps - and languages such as CoBOL had a
function to convert the computer time to local).

William M. Klein

2008-03-11, 6:56 pm

"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47D56BE4.6F0F.0085.0@efirstbank.com...
> <HAXAj.5290$FE.820@fe05.news.easynews.com>, William M.
> Klein<wmklein@nospam.netcom.com> wrote:
<snip>
> I am perplexed by some of the things they don't think would be useful to the
> average Cobol programmer. Variable length fields and (dynamic capacity)
> tables are features that I personally think would be very useful! Seems
> that exception handling could use a rework, but why eliminate RESUME. I've
> never really understood how Cobol 2002 exception handling is suppose to work
> anyway...
>
> Frank
>
Frank,
I am not certain that they are saying that some of these features wouldn't be
"useful". However, as currently defined (in WD 1.10) there are both technical
problems and the run-time overhead would be significant.

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

William M. Klein

2008-03-11, 6:56 pm

"Robert" <no@e.mail> wrote in message
news:m1pbt3hf9l197putsqlr2pvr1iccpgv7ka@
4ax.com...
> On Mon, 10 Mar 2008 17:12:04 -0600, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com>
> wrote:
>
<snip>

> The average Cobol programmer has avoided Occurs Depending On for 22 years.
>

As usual, Robert's claim for what the "average COBOL porgramme" does or doesn't
do is based on his rigourously applied research method, i.e. "it seems to me -
that of those programs and programmers that I have seen, that ..."

Needless to say, given the LARGE number of files that are still used by COBOL
programs and that require ODO's, what he has stated does apply in some
environments, but requires a use of "average" that is not universally used.

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

Michael Mattias

2008-03-11, 6:56 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:dDzBj.440419>
> [progams] that require ODO's, what he has stated does apply in some
> environments, but requires a use of "average" that is not universally
> used.

Occurs Depending On is a perfectly fine and potentially quite useful
source-code level technique.

But it's like all other techniques: there are times to use it and times to
use something else.

Trying to quantify the techniques used by the "average" programmer is a
fool's errand. Example?

One time I was bought in as an outside contractor to work on a very specific
piece of software with which I had prior experience. The person supervising
my work had been the primary COBOL programmer for the client for nine (9)
years.

When I pronounced the job done, quite reasonably this supervisor wanted to
check out my coding techinques before she let me go.

Imagine my surprise when this nine-year veteran told me not only was my code
acceptable, but she was glad to have had the chance to review it because she
had NEVER SEEN THE 'SEARCH' VERB USED BEFORE.

That was the day I quit making *any* assumptions about "normal" or "average"
programming techniques.

--
Michael C. Mattias
Tal Systems Inc.
Racine WI
mmattias@talsystems.com

Howard Brazee

2008-03-11, 6:56 pm

On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>
>As usual, Robert's claim for what the "average COBOL porgramme" does or doesn't
>do is based on his rigourously applied research method, i.e. "it seems to me -
>that of those programs and programmers that I have seen, that ..."

I'll have to say that I don't think I've ever Occurs Depending On used
much for internal tables wherever I've worked (at least in the last
couple of decades) - and its usage in data files has been largely
superseded, first with header and detail records, and later with
database access.

But that's only my experience, I can't speak for the industry.

Howard Brazee

2008-03-11, 6:56 pm

On Tue, 11 Mar 2008 17:44:36 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Frank,
> I am not certain that they are saying that some of these features wouldn't be
>"useful". However, as currently defined (in WD 1.10) there are both technical
>problems and the run-time overhead would be significant.

With the world moving away from CoBOL to OO languages - why should
run-time overhead in batch CoBOL be significant?

Jeff Campbell

2008-03-11, 6:56 pm

Pete Dashwood wrote:
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13tbq3hb852cjc9@corp.supernews.com...
>
> Other viewpoints always welcomed by me... :-)
>
> Well, as it is the core of their business, they WOULD say that, wouldn't
> they? :-)
>
> I don't believe it is even true today, but I can't prove it so won't argue
> it.
>
>
> Not exactly as I recall... and I was there :-)
>

[snipped]

>
> Maybe, but that is an academic argument. It doesn't matter what you call it,
> the fact is that the new languages can be written quicker, re-written
> quicker, require much less code, and have facilities that COBOL simply
> doesn't. Whether they are doing procedural processing under the guise of OO
> or not is immaterial; they can be generated to do it quicker than a good
> COBOL programmer can code the thousands of lines it takes.
>
> I have been astounded at the encapsulated functionality in languages like
> C#, that simply isn't available in COBOL. It doesn't even matter what the
> paradigm is, it is quicker to point and click in Visual Studio, than it is
> to write hundreds of lines of COBOL in ISPF. End of story.

Let me second or third or whatever that! 8-)

I discovered yesterday that list boxes in .NET store objects rather than just
strings (strings are objects). That means I can store an array of records
encapsulated as object instances in the list box. When an item in the displayed
list is selected, the code processing the click event has direct access to the
objects contents. No searching or sorting!

A PowerCOBOL list box ,at least as of version 5, only stores text, meaning that
code needs to be written to find the corresponding record in a table. Indicies
need to be managed in a synchronized fashion in the list box and the backing
table. Insertion, deletion, modification routines, etc. More code to write,
debug and support.

The really

thing about storing objects in the list box is that the objects
do not have to all be of the same type. I'm not sure how often this will be useful
but I can see having a list box that presents the user with a hierarchy of choices
the choices relating to different types of things.

>
>
> I understand what you're saying, Rick, but I contend that they won't. I know
> from my own experience (somewhat like being dragged kicking and screaming
> into Java and C#) that the desire to go back to COBOL diminishes with the
> increasing understanding and facility in OO languages. Yes, I COULD develop
> web applications in OO COBOL, yes, I COULD write OO COBOL components, but I
> won't and don't. (I did for many years and felt like a "voice in the
> wilderness" receiving scorn and vitriol from most of the COBOL community
> when I suggested that OO might be important for COBOL, and a total lack of
> support from COBOL vendors when problems arose. Nowadays when I have a
> problem, I don't need or want to go to MicroSoft; there are around 60
> million people writing C#... I can get a GOOGLEd solution in minutes. Also,
> the demonstrated attitude of the C# community is a helpful and positive one
> in the C# forums I have used...) I just don't believe that once
> "multilingual" programmers go away from COBOL, they will need or want to go
> back to it.
>
> The "new" features in COBOL, even if they could be implemented, are not
> going to make any difference.
>
> I respect MicroFocus for taking a hand in the standards debacle and I
> honestly wish them well. Whether they are driven by commercial necessity or
> a genuine desire to improve COBOL, what they are doing is commendable.
>
> Unfortunately, I believe it is too late.
>
> Pete.
> "I used to write COBOL...now I can do anything."

Jeff

>
>
>

----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= - Total Privacy via Encryption =---

Bill Gunshannon

2008-03-11, 6:56 pm

In article <brjdt31tddip4bo55n9u8ma5gigqprt62q@4ax.com>,
Howard Brazee <howard@brazee.net> writes:
> On Tue, 11 Mar 2008 17:44:36 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> With the world moving away from CoBOL to OO languages

Funny, I keep hearing this, except from the people actually still
maintaining and writting large COBOL projects.

> - why should
> run-time overhead in batch CoBOL be significant?

bill

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

Howard Brazee

2008-03-11, 6:56 pm

On 11 Mar 2008 19:31:57 GMT, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

>
>Funny, I keep hearing this, except from the people actually still
>maintaining and writting large COBOL projects.

This time you heard it from someone actually still maintaining large
CoBOL projects.

It is easy to keep my head in the ground, and that makes me feel
secure. But feeling secure isn't the same thing as being ready for
what comes.

Clark F Morris

2008-03-11, 6:56 pm

On Tue, 11 Mar 2008 02:08:27 -0000, tim <TimJ@internet.com> wrote:

>On Mon, 10 Mar 2008 09:20:46 -0600, Howard Brazee wrote:
>
>
>If the program you are compiling says packed-decimal the standard says it
>must be stored in packed decimal format. Of course you can provide
>optimization flags that allow this rule to be overridden in the name
>of speed. But with redefines and pointers/linkage it gets very difficult to
>maintain correctness in the generated code if you change the format from
>packed decimal to binary for example.
>
>Packed decimal is mostly about the same speed as binary on IBM mainframes,
>but it's a lot slower than binary on most Unix/PC CPUs. Packed decimal is
>a lot faster than display format on mainframes for arithmetic, due to lack
>of microcode support for most arithmetic operations performed on display
>format data.

The only true decimal arithmetic on the IBM 360/370/390/z systems is
packed decimal and (IEE754 something on the latest z). It is more
efficient than converting to binary, doing the arithmetic and
converting back. It also is more efficient than what I think is
available for decimal arithmetic on the Intel chips. It is not nearly
as efficient as binary on the z series (or predecessors) if you are
not trying to get decimal rounding and behavior in division and other
places where it matters. Incidentally COBOL is NOT one of the
languages for which support for the new floating point decimal
arithmetic is announce on the z series.

Clark Morris

Clark Morris
>
>Tim

Pete Dashwood

2008-03-11, 6:56 pm

"Jeff Campbell" <n8wxs@arrl.net> wrote in message
news:1205259923_658@isp.n...
> Pete Dashwood wrote:
>
> [snipped]
>
>
> Let me second or third or whatever that! 8-)
>

Thanks for your support, Jeff :-)

> I discovered yesterday that list boxes in .NET store objects rather than
> just
> strings (strings are objects). That means I can store an array of records
> encapsulated as object instances in the list box. When an item in the
> displayed
> list is selected, the code processing the click event has direct access to
> the
> objects contents. No searching or sorting!
>
> A PowerCOBOL list box ,at least as of version 5, only stores text, meaning
> that
> code needs to be written to find the corresponding record in a table.
> Indicies
> need to be managed in a synchronized fashion in the list box and the
> backing
> table. Insertion, deletion, modification routines, etc. More code to
> write,
> debug and support.
>
> The really

thing about storing objects in the list box is that the
> objects
> do not have to all be of the same type. I'm not sure how often this will
> be useful
> but I can see having a list box that presents the user with a hierarchy of
> choices
> the choices relating to different types of things.
>

This is a good example, but it is just one of many...

Facilities like code reflection, generalized procedures through delegation,
access to event models, simple building and processing of collections,
access to a host of components that run across platforms and save
incalcuable amounts of time, are just some of the facilities that COBOL
simply doesn't even begin to address...

For batch processing, it doesn't matter; beyond that, it certainly does
matter...

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

Pete Dashwood

2008-03-11, 6:56 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:4gpdt3der0761opav40ebu4d3d4v0g9vi2@
4ax.com...
> On 11 Mar 2008 19:31:57 GMT, billg999@cs.uofs.edu (Bill Gunshannon)
> wrote:
>
>
> This time you heard it from someone actually still maintaining large
> CoBOL projects.
>
> It is easy to keep my head in the ground, and that makes me feel
> secure. But feeling secure isn't the same thing as being ready for
> what comes.

Well said, Howard.

It isn't really about "COBOL right or wrong".

It is about dealing with reality.

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

Robert

2008-03-11, 9:57 pm

On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:m1pbt3hf9l197putsqlr2pvr1iccpgv7ka@
4ax.com...
><snip>
>
>
>As usual, Robert's claim for what the "average COBOL porgramme" does or doesn't
>do is based on his rigourously applied research method, i.e. "it seems to me -
>that of those programs and programmers that I have seen, that ..."

When ODO comes up in this forum, as it did 3 years ago and 6 months ago in my Myth Busters
thread, some here said it should not be used because it is too slow (even when faced with
contrary evidence) or because it adds 'unnecessary complexity'. The Micro Focus Server
Express performance tips manual says it is slower; an IBM manual you linked to says the
same.

ODO is one of many faith-based issues in the Cobol community.

Manuals fail to point out that ODO makes SEARCH ALL 10% faster for typical (2^10) table
size. Assuming the table is half full, the difference is 1 - (log2(n) / (1 + log2(n))).

>Needless to say, given the LARGE number of files that are still used by COBOL
>programs and that require ODO's, what he has stated does apply in some
>environments, but requires a use of "average" that is not universally used.

Files? I thought files were replaced by databases years ago. Rows don't contain arrays.

Richard

2008-03-12, 3:55 am

On Mar 12, 3:27 pm, Robert <n...@e.mail> wrote:
> On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein" <wmkl...@nospam.netcom.com> wrote:
>
>
>

How did you determine which one was 'the average' ? By age ?, number
of lines per year ? And why is it only this one doing so ?

And why has he only started doing this (if in fact he has) since
1986 ?
[color=darkred]
>
> When ODO comes up in this forum, as it did 3 years ago and 6 months ago in my Myth Busters
> thread, some here said it should not be used

Your 'Myth Busters thread' was almost all completely busted. For the
most part your claims were myths.

> because it is too slow (even when faced with
> contrary evidence) or because it adds 'unnecessary complexity'. The Micro Focus Server
> Express performance tips manual says it is slower; an IBM manual you linked to says the
> same.
>
> ODO is one of many faith-based issues in the Cobol community.

Here is a clip from an HP3000 manual:

> * Access to tables defined with
> OCCURS...DEPENDING is less efficient than access to tables of
> fixed size, and so should be avoided where high performance is
> needed.

This seems fairly straight forward. Why do you think that HP lies
about this ?

> Manuals fail to point out that ODO makes SEARCH
> ALL 10% faster for typical (2^10) table
> size. Assuming the table is half full, the difference is 1 - (log2(n) / (1 + log2(n))).
>

Why do you think that a table size of 4000 or so is 'typical' ?

Whether it makes the search faster or slower is dependent on the
implementation, as well as many other things.

The HP manual says that _access_ is slower. It may be that the SEARCH
ALL is faster, or maybe not. It may be that in many programs the
tables are not used for SEARCH ALL and so your tiny detail is
completely irrelevant.

>
> Files? I thought files were replaced by databases years ago. Rows don't contain arrays.

Pete Dashwood

2008-03-12, 3:55 am

"Robert" <no@e.mail> wrote in message
news:f6eet3depq6ugth6br7r2mk1hd5u9uiiqk@
4ax.com...
> On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> When ODO comes up in this forum, as it did 3 years ago and 6 months ago in
> my Myth Busters
> thread, some here said it should not be used because it is too slow (even
> when faced with
> contrary evidence) or because it adds 'unnecessary complexity'. The Micro
> Focus Server
> Express performance tips manual says it is slower; an IBM manual you
> linked to says the
> same.

So, are you saying these manuals are wrong?

I don't use it because I don't believe it saves anything and it just adds
overhead (although I realy don't care about that) and complexity (although I
really don't care about that either... :-)). Basically, it promises to save
memory, then goes and allocates the largest possible space anyway. THAT'S
why I REALLY don't like it... it simply fails to deliver what it promises.
:-) (Failure to deliver, usually pisses me off... :-))

Now, your point about sorts on ODO arrays being faster is an interesting
one, but, as I have never used an ODO array in memory and therefore have no
need to sort it, for me, that's a teeny bit irrelevant... I don't sort fixed
length arrays either; instead, I load them in sequence and use SEARCH ALL
(if they're large) or just SEARCH if they're small. Easy, no messing, does
the job, works for me.

I simply don't understand why you are so fired up in support of ODO. What am
I missing, here?

(I haven't even bothered to discuss its use on files because that is just
beneath contempt as far as I'm concerned... In a bygone era, when external
media were limited in capacity and expensive in price, there MIGHT have been
a need for it (although even then we found other and better ways to store
information), but anyone still using it today for external storage just gets
my sympathy and an offer of help. No discussion.)

>
> ODO is one of many faith-based issues in the Cobol community.

"Tell us, Master, how we can acquire faith..."
"XXXX off!"
"Tell us, Master, how to XXXX off..."
(apologies to Monty Python's Life of Brian...)

>
> Manuals fail to point out that ODO makes SEARCH ALL 10% faster for typical
> (2^10) table
> size. Assuming the table is half full, the difference is 1 - (log2(n) / (1
> + log2(n))).
>

(Yawn)... so I should use ODO to save a few milliseconds when I need to sort
an array?

But I DON'T need to sort an array... ever. And if I did I'd take the hit...

Next point?

Bill obviously lives in a different world from me. If I was living in a
world where there were a "LARGE number of files that are still used by COBOL
programs and that require ODO's..." I'd be strongly encouraging migration to
databases... By an amazing coincidence, I just happen to have here some
tools that can fully automate the data migration and also some approaches
that can help with the code conversion. Am I prophetic or what? (Actually,
no... it's just that quite a number of people have realized that living in a
world where there are a "LARGE number of files that are still used by COBOL
programs and that require ODO's..." is NOT a good place to be...) I was one
of them, without even having the increased urgency that ODO would provide,
so I built some tools to help me get out of this dying world. Some other
people then also picked them up... I thought their usefulness was now over
as, surely, everybody has migrated? Apparently not... at least not where
Bill lives :-).

If you live in Bill's world and fear for the future, contact me. I can help.
[color=darkred]
> Files? I thought files were replaced by databases years ago. Rows don't
> contain arrays.

No they don't. But they can vary in length, WITHOUT needing ODO... VARCHAR
columns are implemented the way ODO SHOULD have been... transparently to the
user.

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

Rick Smith

2008-03-12, 3:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:63p2sfF28n6tgU1@mid.individual.net...

[snip]

> (Yawn)... so I should use ODO to save a few milliseconds when I need to
sort
> an array?
>
> But I DON'T need to sort an array... ever. And if I did I'd take the
hit...
>
> Next point?

Intrinsic functions using the ALL subscript will work with
ODO tables, but likely will not give the correct result when
using fixed length tables with a variable number of items.

MAX, MEAN, MEDIAN, MIDRANGE, MIN,
ORD-MAX, ORD-MIN, PRESENT-VALUE,
RANGE, STANDARD-DEVIATION, SUM, and
VARIANCE are those affected.

Pete Dashwood

2008-03-12, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13teonpobo7kve4@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:63p2sfF28n6tgU1@mid.individual.net...
>
> [snip]
>
> sort
> hit...
>
> Intrinsic functions using the ALL subscript will work with
> ODO tables, but likely will not give the correct result when
> using fixed length tables with a variable number of items.
>
> MAX, MEAN, MEDIAN, MIDRANGE, MIN,
> ORD-MAX, ORD-MIN, PRESENT-VALUE,
> RANGE, STANDARD-DEVIATION, SUM, and
> VARIANCE are those affected.
>
>

Fair enough.

Again, facilities I wouldn't use often enough to lose sleep over... :-)

I don't think I've ever used ALL as a subscript, and MAX, MIN, and SUM seem
more like SQL to me than COBOL... (I have used those in SQL...). So it looks
to me as if my COBOL use may be "limited", notwithstanding the fact I used
it successfully for decades. :-)

I'm wondering what proportion of the COBOL user base are using these
features on a daily basis?

Perhaps this is what Bill meant by a "bloated" standard...? Some

, but
esoteric features. Should the Standards committe be spending time on
documenting them and then expecting vendors to implement them, if there is a
tiny user demand for them? \

Or is it me? :-)

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

William M. Klein

2008-03-12, 3:55 am

Actually, I have used MAX, MIN, ORD-MAX, ORD-MIN with an ALL subscript and a
fixed number of occurrence table. The "trick" is to fill with high-values or
low-values before populating the table. for example pre-fill with low-values
and then use
Function Max (elem (all)) ...

and it will happily find the maximum entry.

SUM could work if you initialize to zero.

I don't know how "performance" OR "maintainability" would work when compared to
using an ODO for the same logic (and not having those "extra" table entries).

As far as Pete's question, the date, numval and the min/max, ord/char functions
are the ones that I think have been MOST commonly used (at least in IBM
mainframe and Micro Focus applications that I know). All of these were from the
'89 Intrinsic functions amendment and not added by the '02 Standard. (OK,
random also gets used - but it always surprises people how it actually works -
and I have also seen REM/MOD in more than one application.) I guess I have
seen everything except the statistics and trig functions <G>.

The two functions that I "like" from the '02 Standard - that I don't think are
used much (and I am not certain who has implemented them) are:
highest-algebraic
and
lowest-algebraic

As someone who (back in my paid programming days) occasionally fell into the
"trap" moving zeroes or 9's to a numeric field and NOT getting its
highest/lowest value, I think these were really "nice to have" new features.

--
Bill Klein
wmklein <at> ix.netcom.com
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:63p7ugF27vleuU1@mid.individual.net...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13teonpobo7kve4@corp.supernews.com...
>
> Fair enough.
>
> Again, facilities I wouldn't use often enough to lose sleep over... :-)
>
> I don't think I've ever used ALL as a subscript, and MAX, MIN, and SUM seem
> more like SQL to me than COBOL... (I have used those in SQL...). So it looks
> to me as if my COBOL use may be "limited", notwithstanding the fact I used it
> successfully for decades. :-)
>
> I'm wondering what proportion of the COBOL user base are using these features
> on a daily basis?
>
> Perhaps this is what Bill meant by a "bloated" standard...? Some

, but
> esoteric features. Should the Standards committe be spending time on
> documenting them and then expecting vendors to implement them, if there is a
> tiny user demand for them? \
>
> Or is it me? :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>

Robert

2008-03-12, 7:55 am

On Wed, 12 Mar 2008 17:01:25 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

>"Robert" <no@e.mail> wrote in message
> news:f6eet3depq6ugth6br7r2mk1hd5u9uiiqk@
4ax.com...
>
>So, are you saying these manuals are wrong?
>
>I don't use it because I don't believe it saves anything and it just adds
>overhead (although I realy don't care about that) and complexity (although I
>really don't care about that either... :-)). Basically, it promises to save
>memory, then goes and allocates the largest possible space anyway. THAT'S
>why I REALLY don't like it... it simply fails to deliver what it promises.
>:-) (Failure to deliver, usually pisses me off... :-))

No, it doesn't promise to save memory. The standard says working-storage is allocated
statically. Actually, it can save memory, but only if YOU dynamically allocate the ODO
structures. This seldom comes up in ODO discussions. I mentioned it when I talked about a
parser creating linked lists of variable length lines and words.

>Now, your point about sorts on ODO arrays being faster is an interesting
>one, but, as I have never used an ODO array in memory and therefore have no
>need to sort it, for me, that's a teeny bit irrelevant... I don't sort fixed
>length arrays either; instead, I load them in sequence and use SEARCH ALL
>(if they're large) or just SEARCH if they're small. Easy, no messing, does
>the job, works for me.

Your SEARCH ALLs would run faster if the arrays were dimensioned with ODO rather than
fixed length. What part of speed do you find complex?

>I simply don't understand why you are so fired up in support of ODO. What am
>I missing, here?

You are missing the point of the thread, which was acceptance of dyamically sized
structues in the next Cobol standard.

>
>(Yawn)... so I should use ODO to save a few milliseconds when I need to sort
>an array?

>But I DON'T need to sort an array... ever. And if I did I'd take the hit...

I didn't say anything about sorting an array.

>
>No they don't. But they can vary in length, WITHOUT needing ODO... VARCHAR
>columns are implemented the way ODO SHOULD have been... transparently to the
>user.

They are implemented the same way BASIC did it 40 years ago. Transparency depends on the
garbage collector.

Robert

2008-03-12, 7:55 am

On Tue, 11 Mar 2008 20:38:59 -0700 (PDT), Richard <riplin@azonic.co.nz> wrote:

>On Mar 12, 3:27 pm, Robert <n...@e.mail> wrote:
[color=darkred]
>
>Your 'Myth Busters thread' was almost all completely busted. For the
>most part your claims were myths.

You are missing the point. That several writers here were opposed to ODO shows the opinion
of some 'typical' programmers.

>
>Here is a clip from an HP3000 manual:
>
>
>This seems fairly straight forward. Why do you think that HP lies
>about this ?

HP didn't write that; Micro Focus write it. The exact same sentence appears in most Micro
Focus manuals.

>
>Why do you think that a table size of 4000 or so is 'typical' ?

1000.

>Whether it makes the search faster or slower is dependent on the
>implementation, as well as many other things.

There is only one way to implement a binary search. Unless the value of 2 is different in
your universe.

Pete Dashwood

2008-03-12, 7:55 am

"Bill Gunshannon" <billg999@cs.uofs.edu> wrote in message
news:63o51dF28emujU1@mid.individual.net...
> In article <brjdt31tddip4bo55n9u8ma5gigqprt62q@4ax.com>,
> Howard Brazee <howard@brazee.net> writes:
>
> Funny, I keep hearing this, except from the people actually still
> maintaining and writting large COBOL projects.
>

Sometimes, when you are in the middle of something, your perception of that
thing is different from that of someone who is detached or outside it.

People will be maintaining COBOL for some years to come yet, and the people
doing that see only that.

(I predicted 12 years ago that by 2015 COBOL would no longer be used as the
major in-house development language, and would, to all intents and purposes
be "dead"...I see no reason to change that prediction and, in fact, it is
coming true quicker than I thought...)

It is still important and relevant. (At least for now; take another look in
7 years...)

But that doesn't change the overall trend. The rate of change is
accellerating and and what might have taken 30 years last century, may take
15, or even 10, in this one...

There is a new influx of computer people coming into the industry who are
NOT conditioned to a sequential procedural paradigm. The "old timers" are
dying off or retiring. The effects of this are inevitable.

Meantime, as you observed, "business as usual"...:-)

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

Pete Dashwood

2008-03-12, 6:55 pm

"Robert" <no@e.mail> wrote in message
news:38kft3t3h52mm32b1vekgqe1qu98l7l1la@
4ax.com...
> On Wed, 12 Mar 2008 17:01:25 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>

No comment?
[color=darkred]
>
> No, it doesn't promise to save memory.

Er...excuse me, but I think it does. It says the size of the array DEPENDS
ON the count field. But it doesn't. The size of the array is always the
maximum possible.

> The standard says working-storage is allocated
> statically.

I have yet to see an implementor's manual that references the standard. As
implementor's manuals are what programmers normally use, whatever the
standard says is really irrelevant.

>Actually, it can save memory, but only if YOU dynamically allocate the ODO
> structures. This seldom comes up in ODO discussions. I mentioned it when I
> talked about a
> parser creating linked lists of variable length lines and words.

I know of no way in COBOL (apart from CICS and Assembler GETMAIN calls on
IBM mainframes) that can DYNAMICALLY allocate storage. So how exactly am I
supposed to dynamically allocate these ODO structures?
>
>
> Your SEARCH ALLs would run faster if the arrays were dimensioned with ODO
> rather than
> fixed length.

I doubt it and would need to see proof. And, to be brutally frank, I really
don't care... :-)

ODOs must be calculated at run time (even for fixed references); fixed
length can be calculated at compile time, for fixed references. I would
agree there probably isn't much to choose between variable references, but
I'd still have to code that awful ODO and it is UGLY!!!! :-)

Even then, if it saves a few milliseconds but I have to code ODO, that
solution is not for me...

>What part of speed do you find complex?

:-)

Given that I have actually optimised existing applications and been paid
serious money for making them run many times faster than they did
previously, probably not much. However, I am not obsessed by processor speed
in applications which spend most of their time waiting for IO to complete...

>
>
> You are missing the point of the thread, which was acceptance of
> dyamically sized
> structues in the next Cobol standard.

OK, if you say so... :-) I really have no comment on that so will butt out
at this point.

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

Bill Gunshannon

2008-03-12, 6:55 pm

In article <63q1pkF28mvcqU1@mid.individual.net>,
"Pete Dashwood" <dashwood@removethis.enternet.co.nz> writes:
>
>
> "Bill Gunshannon" <billg999@cs.uofs.edu> wrote in message
> news:63o51dF28emujU1@mid.individual.net...
>
> Sometimes, when you are in the middle of something, your perception of that
> thing is different from that of someone who is detached or outside it.
>
> People will be maintaining COBOL for some years to come yet, and the people
> doing that see only that.

You obviously missed the part about writting large applications in
COBOL.

>
> (I predicted 12 years ago that by 2015 COBOL would no longer be used as the
> major in-house development language, and would, to all intents and purposes
> be "dead"...I see no reason to change that prediction and, in fact, it is
> coming true quicker than I thought...)

Maybe in New Zealand!

>
> It is still important and relevant. (At least for now; take another look in
> 7 years...)

Like Unix and many other things, I was told that COBOL was on its way out
over 25 years ago. Guess what....... I have recently looked at a number
of places that are looking for long term, full-time COBOL programmers.
Unfortunately they almost all want current IBM OS experience, which I
don't have, having been out of the IBM forld for nearly 30 years.
These places are nit just doing maintenance while they migrate to C#
or Java. They are still developing applications in COBOL. Just because
the user doesn't see the COBOL doesn't mean it isn't there.

>
> But that doesn't change the overall trend. The rate of change is
> accellerating and and what might have taken 30 years last century, may take
> 15, or even 10, in this one...
>
> There is a new influx of computer people coming into the industry who are
> NOT conditioned to a sequential procedural paradigm. The "old timers" are
> dying off or retiring. The effects of this are inevitable.

Yeah, Fortran is supposedly the same way, except that I have seen recent
job postings looking for people who know Fortran or are willing to learn.
Oldtimers can pass their knowledge on. If you can really program in one
language it is not all that different to learn a new one. Especially
if you just ignore all the hype over new paradigms that really don't
apply to your core business.

>
> Meantime, as you observed, "business as usual"...:-)

And likely to be so til long after I am out of the IT world.

bill

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

Howard Brazee

2008-03-12, 6:55 pm

On Wed, 12 Mar 2008 17:01:25 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>Now, your point about sorts on ODO arrays being faster is an interesting
>one, but, as I have never used an ODO array in memory and therefore have no
>need to sort it, for me, that's a teeny bit irrelevant... I don't sort fixed
>length arrays either; instead, I load them in sequence and use SEARCH ALL
>(if they're large) or just SEARCH if they're small. Easy, no messing, does
>the job, works for me.

And if they're tiny, I search by hand (days of the w

Howard Brazee

2008-03-12, 6:55 pm

On Thu, 13 Mar 2008 01:48:57 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>But that doesn't change the overall trend. The rate of change is
>accellerating and and what might have taken 30 years last century, may take
>15, or even 10, in this one...
>
>There is a new influx of computer people coming into the industry who are
>NOT conditioned to a sequential procedural paradigm. The "old timers" are
>dying off or retiring. The effects of this are inevitable.

I wonder how long it will take before we will be at an equivalent
stage with today's methodologies and tools.

SkippyPB

2008-03-12, 6:55 pm

On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>"Robert" <no@e.mail> wrote in message
> news:m1pbt3hf9l197putsqlr2pvr1iccpgv7ka@
4ax.com...
><snip>
>
>
>As usual, Robert's claim for what the "average COBOL porgramme" does or doesn't
>do is based on his rigourously applied research method, i.e. "it seems to me -
>that of those programs and programmers that I have seen, that ..."
>
>Needless to say, given the LARGE number of files that are still used by COBOL
>programs and that require ODO's, what he has stated does apply in some
>environments, but requires a use of "average" that is not universally used.

I don't know any statistics regarding an "average Cobol program" but I
do know our shop standard for the 25+ years I've worked for my
employer disallows the use of "Occurs Depending On" clause in our
software.

Regards,
////
(o o)
-oOO--(_)--OOo-

"With global warming, somebody's baby is going to have to burst into
flames to make people do the right thing."
-- Chris Rock
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

Richard

2008-03-12, 6:55 pm

On Mar 13, 2:16 am, Robert <n...@e.mail> wrote:
> On Tue, 11 Mar 2008 20:38:59 -0700 (PDT), Richard <rip...@azonic.co.nz> wrote:
>
>
>
>
> You are missing the point. That several writers here were opposed to ODO shows the opinion
> of some 'typical' programmers.

I am not sure that they were 'opposed' to it, they simply didn't
bother with it.

>
>
>
>
>
> HP didn't write that; Micro Focus write it. The exact same sentence appears in most Micro
> Focus manuals.
>
>
>
> 1000.
>
>
> There is only one way to implement a binary search. Unless the value of 2 is different in
> your universe.

These are different things entirely. You are correct that with a
smaller table the number of binary chops reduces. However, if each
access is 'less efficient', because for example it checks against a
data item rather than literal, then it may still be slower.

In any case, even if the SEARCH ALL is faster it may be that loading
the table is slower, especially if the DO is incremented with each
access.

Howard Brazee

2008-03-12, 6:55 pm

On Wed, 12 Mar 2008 11:30:03 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

>In any case, even if the SEARCH ALL is faster it may be that loading
>the table is slower, especially if the DO is incremented with each
>access.

Without having table sorts available, I've coded comb sorts in CoBOL.
An example of this was a report where all of the line items for each
bill need to be sorted in a bill run.

Frank Swarbrick

2008-03-12, 6:55 pm

>>> On 3/11/2008 at 10:01 PM, in message
<63p2sfF28n6tgU1@mid.individual.net>,
Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
> No they don't. But they can vary in length, WITHOUT needing ODO...
> VARCHAR
> columns are implemented the way ODO SHOULD have been... transparently to
> the
> user.

This is exactly one of the reasons that Cobol should have dynamic length
fields. Currently you have to define a "VARCHAR" in Cobol like this:

01 A-VARCHAR-STRING.
49 A-VARCHAR-STRING-LEN PIC S9(4) COMP-5.
49 A-VARCHAR-STRING-TXT PIC X(1000).

EXEC SQL
SELECT A_VARCHAR_STRING
INTO :A-VARCHAR-STRING
FROM FRANK.TABLE1
END-EXEC

DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING-TXT(1:A-VARCHAR-STRING-LEN)
'"'.

Yuck!! I would much rather have:

01 A-VARCHAR-STRING PIC X ANY LENGTH
LIMIT IS 1000
PREFIXED BY BINARY-SHORT.

EXEC SQL
SELECT A_VARCHAR_STRING
INTO :A-VARCHAR-STRING
FROM FRANK.TABLE1
END-EXEC

DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING '"'.

Though to be honest the data definition is much too long, but I could live
with it just to have this feature.

Frank

Richard

2008-03-12, 6:55 pm

On Mar 13, 2:12 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> "Robert" <n...@e.mail> wrote in message
>
> news:38kft3t3h52mm32b1vekgqe1qu98l7l1la@
4ax.com...
>
>
>
>
>
>
>
>
>
>
>
> No comment?
>
>
>
> Er...excuse me, but I think it does. It says the size of the array DEPENDS
> ON the count field. But it doesn't. The size of the array is always the
> maximum possible.

Whether that is true or not is an implementation issue. A particular
compiler _could_ make it truly dynamic, but the performance penalty
would be unacceptable.

In any case, for file records it _IS_ true. The size of the record on
tape/disk really does depend on the count field.

The problem with Robert's claims(this time) is that ODO is used for
two different things. It controls the size of records in files, and it
is used to limit SORT and SEARCH. The first use is a bad thing because
there shouldn't be arrays in file records, but when tapes were all one
had it was a useful way of having sub-records. The complications of
having multiple ODO led to sites banning its use, quite rightly, when
disks became available and a separate file could be used for them.

While it may be true that SEARCH ALL is fractionally faster using ODO
and the recent ability to SORT a table requires it, these are seldom
used. Most of my tables are used sequentially because they hold groups
of data, they are lists not arrays. I can't recall ever bothering with
a SEARCH ALL. In most applications of requiring stuff by key I have
used the indexed file directly rather than load it all into an array
and SEARCH for it.

In any case SEARCH ALL still works without ODO, just fill the unused
portion with high values <shrug>. My tests do show that with Fujitsu
the ODO array access is fractionally slower, but only by 1%, and that
is with the depending on set fixed at maximum.

It is all to do with designing the system right in the first place
rather than fretting over a few milliseconds.

>
>
> I have yet to see an implementor's manual that references the standard. As
> implementor's manuals are what programmers normally use, whatever the
> standard says is really irrelevant.
>
>
> I know of no way in COBOL (apart from CICS and Assembler GETMAIN calls on
> IBM mainframes) that can DYNAMICALLY allocate storage. So how exactly am I
> supposed to dynamically allocate these ODO structures?
>
>
>
>
>
> I doubt it and would need to see proof. And, to be brutally frank, I really
> don't care... :-)
>
> ODOs must be calculated at run time (even for fixed references); fixed
> length can be calculated at compile time, for fixed references. I would
> agree there probably isn't much to choose between variable references, but
> I'd still have to code that awful ODO and it is UGLY!!!! :-)
>
> Even then, if it saves a few milliseconds but I have to code ODO, that
> solution is not for me...
>
>
> :-)
>
> Given that I have actually optimised existing applications and been paid
> serious money for making them run many times faster than they did
> previously, probably not much. However, I am not obsessed by processor speed
> in applications which spend most of their time waiting for IO to complete...
>
>
>
>
>
> OK, if you say so... :-) I really have no comment on that so will butt out
> at this point.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."

William M. Klein

2008-03-12, 6:55 pm

If the proposed revision:

A) limited ANY LENGTH items to the 01-level, then it might work better

B) made any of the BINARY-xxxx fields something other than processor dependent

C) didn't try and support both "direct" and "indirect" storage of such items,

Then, Yes, I would say that it might be a useful feature. As currently defined,
it just has BUNCHES of problems (both in the specification and probable
performance hits).

--
Bill Klein
wmklein <at> ix.netcom.com
"Frank Swarbrick" <Frank.Swarbrick@efirstbank.com> wrote in message
news:47D7DC66.6F0F.0085.0@efirstbank.com...
> <63p2sfF28n6tgU1@mid.individual.net>,
> Pete Dashwood<dashwood@removethis.enternet.co.nz> wrote:
>
> This is exactly one of the reasons that Cobol should have dynamic length
> fields. Currently you have to define a "VARCHAR" in Cobol like this:
>
> 01 A-VARCHAR-STRING.
> 49 A-VARCHAR-STRING-LEN PIC S9(4) COMP-5.
> 49 A-VARCHAR-STRING-TXT PIC X(1000).
>
> EXEC SQL
> SELECT A_VARCHAR_STRING
> INTO :A-VARCHAR-STRING
> FROM FRANK.TABLE1
> END-EXEC
>
> DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING-TXT(1:A-VARCHAR-STRING-LEN)
> '"'.
>
> Yuck!! I would much rather have:
>
> 01 A-VARCHAR-STRING PIC X ANY LENGTH
> LIMIT IS 1000
> PREFIXED BY BINARY-SHORT.
>
> EXEC SQL
> SELECT A_VARCHAR_STRING
> INTO :A-VARCHAR-STRING
> FROM FRANK.TABLE1
> END-EXEC
>
> DISPLAY 'A_VARCHAR_STRING = "' A-VARCHAR-STRING '"'.
>
> Though to be honest the data definition is much too long, but I could live
> with it just to have this feature.
>
> Frank
>

Howard Brazee

2008-03-12, 6:55 pm

On Wed, 12 Mar 2008 12:45:11 -0700 (PDT), Richard
<riplin@azonic.co.nz> wrote:

>The problem with Robert's claims(this time) is that ODO is used for
>two different things. It controls the size of records in files, and it
>is used to limit SORT and SEARCH. The first use is a bad thing because
>there shouldn't be arrays in file records, but when tapes were all one
>had it was a useful way of having sub-records. The complications of
>having multiple ODO led to sites banning its use, quite rightly, when
>disks became available and a separate file could be used for them.

Even with tapes, the concept of header and detail records was being
used instead of variable length tables after a while.

Clark F Morris

2008-03-12, 6:56 pm

On Tue, 11 Mar 2008 12:28:40 -0600, Howard Brazee <howard@brazee.net>
wrote:

>On Tue, 11 Mar 2008 17:50:02 GMT, "William M. Klein"
><wmklein@nospam.netcom.com> wrote:
>
>
>I'll have to say that I don't think I've ever Occurs Depending On used
>much for internal tables wherever I've worked (at least in the last
>couple of decades) - and its usage in data files has been largely
>superseded, first with header and detail records, and later with
>database access.
>
>But that's only my experience, I can't speak for the industry.
I believe that OCCURS DEPENDING ON is useful for tables that can have
a variable number of entries and are in sequence for searching using
SEARCH ALL.

Clark Morris

tlmfru

2008-03-12, 6:56 pm

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:63q1pkF28mvcqU1@mid.individual.net...
>
> There is a new influx of computer people coming into the industry who are
> NOT conditioned to a sequential procedural paradigm. The "old timers" are
> dying off or retiring. The effects of this are inevitable.
>
> Meantime, as you observed, "business as usual"...:-)
>
> Pete.
> --

.... to become old-timers in their turn. Wouldn't it be great to know ahead
of time what used-up pardigm they'll be clinging to?

PL

Rick Smith

2008-03-12, 6:56 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:63q361F28e93nU1@mid.individual.net...

[snip]

> Er...excuse me, but I think it does. It says the size of the array DEPENDS
> ON the count field. But it doesn't. The size of the array is always the
> maximum possible.

2002, OCCURS clause, GR 7, in part,
"This does not imply that the length of the subject of the entry
is variable, but that the number of occurrences is variable."

Nearly identical disclaimers appear in the LRMs I have,
which go back forty years to ANS COBOL 68.

Pete Dashwood

2008-03-12, 6:56 pm

"Bill Gunshannon" <billg999@cs.uofs.edu> wrote in message
news:63q8orF290er2U2@mid.individual.net...
> In article <63q1pkF28mvcqU1@mid.individual.net>,
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> writes:
>
> You obviously missed the part about writting large applications in
> COBOL.
>

No, I didn't miss it, it is just such a tiny fraction of ALL the new
development going on in the world that it is insignificant.

Maybe YOU missed the fact that COBOL is not even in the top 10 development
languages in the world. It is reasonable to assume, therefore that the
percentage of new development being done in it cannot be more than10%... in
practice, although the actual figures cannot be obtained, I would be
surprised if 3% of the world's new application development is in COBOL.

Whether you like it or not, many sites that are currently maintaining a
COBOL legacy are in the process of planning how to move off it (if they
haven't started already...). And some of these are major users like Banks
and insurance companies, traditional strongholds of Fortress COBOL.

>
> Maybe in New Zealand!

Don't worry, you'll catch us up eventually... :-)
(http://www.uci3.canterbury.ac.nz/nzleads.shtml)

>
>
> Like Unix and many other things, I was told that COBOL was on its way out
> over 25 years ago.

So just because something you were told 25 years ago wasn't true then, there
is no chance it could be true now, right?

> Guess what....... I have recently looked at a number
> of places that are looking for long term, full-time COBOL programmers.

" a number", huh?

Zero is a number, so is 1...

I know "a number" of places that are NOT looking for COBOL programmers, but
ARE looking for IT staff.

I'll bet my number is bigger than yours... :-)

> Unfortunately they almost all want current IBM OS experience, which I
> don't have, having been out of the IBM forld for nearly 30 years.

IBM is a last remaining stronghold for COBOL and THEY are encouraging their
customers to move away from it.

> These places are nit just doing maintenance while they migrate to C#
> or Java. They are still developing applications in COBOL. Just because
> the user doesn't see the COBOL doesn't mean it isn't there.
>

Sure. But they are an insignificant percentage of world software
development.

>
> Yeah, Fortran is supposedly the same way, except that I have seen recent
> job postings looking for people who know Fortran or are willing to learn.

Fortran is a niche market and has never gone away. Neither is it likely to;
it does what it does and it does it well.

> Oldtimers can pass their knowledge on. If you can really program in one
> language it is not all that different to learn a new one.

Demonstrably NOT so, as you would know if you ever tried teaching COBOL
programmers OO... The old adage about old dogs and new tricks is generally
pretty accurate. It CAN be done, but it is much easier to start with people
who don't believe they already know everything they need to, and that
anything different is just a re-invention of what they already know.

> Especially
> if you just ignore all the hype over new paradigms that really don't
> apply to your core business.
>

You'll be OK then...:-)

>
> And likely to be so til long after I am out of the IT world.

Well, I don't know how long you are giving yourself... :-)

There will be a perceived need for batch processing for a considerable time
yet. (Whether such a need is "real" remains to be seen. As the speed and
power of transaction processing increases, the idea of deferred batch
processing may become unnecessary. We currently use batch processing more
from historical habit than from real necessity. The concept of grouped
results can be approached in a number of ways, not just traditional batch
processing, especially as mutiple processor acrhitectures and consequent
parallel processing emerge over the horizon.)

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

Pete Dashwood

2008-03-12, 9:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:b7sft3huages2crc0v3lhekm76scp1leaf@
4ax.com...
> On Thu, 13 Mar 2008 01:48:57 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I wonder how long it will take before we will be at an equivalent
> stage with today's methodologies and tools.

That's a VERY interesting observation, Howard.

I don't see the current "state of the art" lasting for 50 years as COBOL
did.

Things are moving ever faster, knowledge increases, and, as it does, new
approaches emerge.

I also believe we are getting close to another fundamental shakeup that will
change the way we approach interaction with, and use of computers.

(In terms of computer architecture, we are overdue for a replacement for the
Von Neumann model. I don't see Quantum Computing as being realistically
achieveable on a commercial scale for some considerable time yet (if
ever...) Emerging parallelism might be the thing that triggers a sea change,
hard to say at this stage.)

There are so many factors that COULD influence this (Robotics,
Nanotechnology, AI, Genetics, logarithmically increasing understanding of
physical processes, the expansion of connectivity and the Internet, the
energy crisis, etc.) that it is unlikely that ANY particular current
technology will last more than say, 20 years. Software Engineering will be
no exception.

I'll be happy if we reach a point where people can interact with and utilise
computer power as naturally as they do a cell phone, without requiring
technocrats and engineers to keep things running. Smart software is a step
in the right direction and I wouldn't mind betting that, even as we are
having this discussion, it is evolving in a software lab somewhere :-)

I hope so.

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

Pete Dashwood

2008-03-12, 9:56 pm

"tlmfru" <lacey@mts.net> wrote in message
news:51YBj.17280$XO4.14456@newsfe19.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:63q1pkF28mvcqU1@mid.individual.net...
>
>
> ... to become old-timers in their turn. Wouldn't it be great to know
> ahead
> of time what used-up pardigm they'll be clinging to?
>
> PL
>
>

See my response toHoward, above in this thread... :-)

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