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

"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.

"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."
>

On Mon, 10 Mar 2008 17:12:04 -0600, "Frank Swarbrick" <Frank.Swarbrick@efirs
tbank.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 th
e
>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. I
t'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 p
rovide garbage
collection."

Server Express v5 manual

"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".

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

"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."

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.

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).

"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 t
he
> 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'v
e
> never really understood how Cobol 2002 exception handling is suppose to wo
rk
> anyway...
>
> Frank
>
Frank,
I am not certain that they are saying that some of these features wouldn't b
e
"useful".  However, as currently defined (in WD 1.10)  there are both techni
cal
problems and the run-time overhead would be significant.


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

"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 does
n'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 COBO
L
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