New revision to the COBOL standard has just begun

[0***@gmail.com]

For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

[Clark F Morris]

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

How much of the last two standards has been implemented (2002? and
2014?)? IBM has not yet implemented Decimal Floating Point, IEEE
binary floating point, the other binary usages and USAGE BIT in their
mainframe compiler despite having hardware implementation of both of
the Floating Point usages (they do support a subset of the hexadecimal
floating point sizes). The lack of linguistic support for DFP is
ironic considering Mike Cowlishaw, an IBM Fellow at the time and
inventor of REXX (a scripting language) was a major proponent of DFP
for business use.

Clark Morris

[pete dashwood]

Post by Clark F Morris

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

How much of the last two standards has been implemented (2002? and
2014?)? IBM has not yet implemented Decimal Floating Point, IEEE
binary floating point, the other binary usages and USAGE BIT in their
mainframe compiler despite having hardware implementation of both of
the Floating Point usages (they do support a subset of the hexadecimal
floating point sizes). The lack of linguistic support for DFP is
ironic considering Mike Cowlishaw, an IBM Fellow at the time and
inventor of REXX (a scripting language) was a major proponent of DFP
for business use.
Clark Morris

The ONLY vendor I know of who has made any attempt to implement ANY 2014
standards is GNU COBOL. (Please correct me if I'm wrong.)

And it isn't just DFP... there is a very long list of non-implemented
standards from both 2002 and 2014, not just from IBM, but also from
Micro Focus and Fujitsu. Micro Focus is a pretty COBOL-Centric company
but even they are trying to diversify away from it. There is a finite
number (and it is diminishing) of mainframe sites that can be targeted
for COBOL migration to the network.

If you put yourself in IBM's shoes, you can see their point. They would
LOVE to drop COBOL altogether; it is a millstone round their neck. They
CAN'T drop it, of course, but if they wait long enough and do as little
as possible, it will be overcome by events (as it largely has outside
IBM) and the new generation of developers and managers don't mind if it
isn't available any more.

For IBM, they see the future with OO and Java and they have quite
properly positioned themselves in this direction.

The World has changed; the landslide started 15 years ago, and the
pebbles didn't get to vote...

I still have a "soft spot" for COBOL but on the occasions when I have to
write it, it really suffers by comparison with modern languages and
tools. (For me, it is like wading through treacle and I smile when I
remember the "Good Old Days" when I thought it was brilliant...) And
even the modern languages may be moving to other platforms soon. The
whole way in which the world does business has changed, and the
traditional methods of IT support development are becoming increasingly
less relevant.

(I have written my thoughts on this at:
https://primacomputing.co.nz/primametro/objectsandlayers.aspx )

It is a look at the changing landscape and how it relates to COBOL.

In the meantime, there is a new attempt at getting a new COBOL standard.

I wish it well.

Pete.

[pete dashwood]

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

Unless there is a solid commitment by a COBOL vendor to IMPLEMENT the
new standard, it is just flogging a dead horse.

We have been here before and it was not a pleasant experience.

Nevertheless, I respect the people who apply their energy to it and
sincerely hope you get a committed vendor. With this regard, I should
think that GNU COBOL are probably your best bet.

Good Luck!

Pete.

[Bill Gunshannon]

Post by pete dashwood

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by
accreditation from national standards bodies.
Robert

Unless there is a solid commitment by a COBOL vendor to IMPLEMENT the
new standard, it is just flogging a dead horse.
We have been here before and it was not a pleasant experience.
Nevertheless, I respect the people who apply their energy to it and
sincerely hope you get a committed vendor. With this regard, I should
think that GNU COBOL are probably your best bet.
Good Luck!
Pete.

Maybe if th4e standards body was more interested in meeting the needs
of the people using the language rather than trying to redefine it
(as was done in a number of other languages as well) there might be
more acceptance of their work.

If there ever was an example of ivory-towerism, the standards bodies
are it.

bill

[pete dashwood]

Post by Bill Gunshannon

Post by pete dashwood

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by
accreditation from national standards bodies.
Robert

Unless there is a solid commitment by a COBOL vendor to IMPLEMENT the
new standard, it is just flogging a dead horse.
We have been here before and it was not a pleasant experience.
Nevertheless, I respect the people who apply their energy to it and
sincerely hope you get a committed vendor. With this regard, I should
think that GNU COBOL are probably your best bet.
Good Luck!
Pete.

Maybe if th4e standards body was more interested in meeting the needs
of the people using the language rather than trying to redefine it
(as was done in a number of other languages as well) there might be
more acceptance of their work.
If there ever was an example of ivory-towerism, the standards bodies
are it.
bill

I take your point, Bill, but it may not be entirely fair.

The COBOL "community" has to take some responsibility.

In the past, delegates who were actually COBOL programmers and analysts
were sponsored by their Companies to be part of Standards committees
which were reviewing COBOL.

Attempts were even made to "open up" the process by allowing public
posts by "interested parties" through forums such as this one.

With one or two exceptions (most of whom are sadly no longer with us...
(Bill Klein, Jimmy Gavan, etc.) the result was resounding silence.

Some delegates saw it as a "gravy train" that would look good on a CV...

The ones who didn't, ended up doing most of the work and receiving no
acknowledgement

(When Bill Klein tried to keep the Standards people honest by insisting
that the original COBOL "Mission Statement" from Codasyl 59 be
reproduced in the new standard, he was vilified and attacked. (It said
that copies of the COBOL spec. should be free (apart from the cost of
production - no profit), as the Companies that supported the Codasyl had
already paid for the effort of formulating it. Did not go down well with
the standards people, who were looking to charge serious sums for a copy
of the Standard...) Just one example of the "in-fighting" that went on
over COBOL standards.)

As COBOL's position as a development language declined, and as major
vendors did not implement the standards anyway, Companies were less
inclined to sponsor delegates to Standards committees.

Serious COBOL vendors attempted to also distance themselves from the
Standards fiasco, and so you get the situation today, where it looks
like "ivory towerism" because there is little "shop floor" involvement
in the process.

I was pretty sickened by the last round and I really hope that lessons
have been learned and the new attempt will succeed. (I don't have as
much personal involvement with COBOL today as I had then, so I am more
relaxed about it either succeeding or failing, but, obviously, I'd like
to see it succeed...)

I guess time will tell.

Pete.

[Bill Gunshannon]

Post by pete dashwood

Post by Bill Gunshannon

Post by pete dashwood

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by
accreditation from national standards bodies.
Robert

Unless there is a solid commitment by a COBOL vendor to IMPLEMENT the
new standard, it is just flogging a dead horse.
We have been here before and it was not a pleasant experience.
Nevertheless, I respect the people who apply their energy to it and
sincerely hope you get a committed vendor. With this regard, I should
think that GNU COBOL are probably your best bet.
Good Luck!
Pete.

Maybe if th4e standards body was more interested in meeting the needs
of the people using the language rather than trying to redefine it
(as was done in a number of other languages as well) there might be
more acceptance of their work.
If there ever was an example of ivory-towerism, the standards bodies
are it.
bill

I take your point, Bill, but it may not be entirely fair.
The COBOL "community" has to take some responsibility.
In the past, delegates who were actually COBOL programmers and analysts
were sponsored by their Companies to be part of Standards committees
which were reviewing COBOL.
Attempts were even made to "open up" the process by allowing public
posts by "interested parties" through forums such as this one.
With one or two exceptions (most of whom are sadly no longer with us...
(Bill Klein, Jimmy Gavan, etc.) the result was resounding silence.

Maybe because the practitioners of the art were satisfied with the
product they had and didn't want outsiders mucking about with it.
Did they give Bill Klein's comments any consideration or just did
the typical academic function of "Well, your wrong and we know what
is best for the COBOL community."

Post by pete dashwood
Some delegates saw it as a "gravy train" that would look good on a CV...

While that is probably true of some, when I was a government contractor
(that was before my foray into academia)my employer provided bodies for
standard committees and user groups and we all took that as seriously as
our regular work.

Post by pete dashwood
The ones who didn't, ended up doing most of the work and receiving no
acknowledgement

Sounds like exactly what I thought and the reason I am not a supporter
of these standards bodies. Don't tune the engine, drive the bus in a
direction the riders don't want to go.

Post by pete dashwood
(When Bill Klein tried to keep the Standards people honest by insisting
that the original COBOL "Mission Statement" from Codasyl 59 be
reproduced in the new standard, he was vilified and attacked. (It said
that copies of the COBOL spec. should be free (apart from the cost of
production - no profit), as the Companies that supported the Codasyl had
already paid for the effort of formulating it. Did not go down well with
the standards people, who were looking to charge serious sums for a copy
of the Standard...) Just one example of the "in-fighting" that went on
over COBOL standards.)

I agree with Bill Klein on this completely. Another good example is
OpenPROM. Developed completely by Sun. Turned over to IEEE to become
a standard. IEEE standardized it. I wanted to get a copy so I could
work on a version of OpenPROM for the various PDP-11's still running all
over the world. They wanted $60,000 for me to see a copy. Any wonder
that OpenPROM didn't become all that standard?

Post by pete dashwood
As COBOL's position as a development language declined, and as major
vendors did not implement the standards anyway, Companies were less
inclined to sponsor delegates to Standards committees.

And yet the standards body is going to create yet another standard
with no input from the practitioners of the art that does not meet
their needs and then wonder why it doesn't get accepted?

Post by pete dashwood
Serious COBOL vendors attempted to also distance themselves from the
Standards fiasco,

See above. Why should they back something that is counter-productive?

Post by pete dashwood
and so you get the situation today, where it looks
like "ivory towerism" because there is little "shop floor" involvement
in the process.

You have put the cart before the horse. It is "ivory towerism"
because they don't give serious consideration to the people who
really know what the language needs to be to do the job? And the
result is those same practitioners see no reason to waste time
when, in the end, they will be the ones who decide what COBOL is
really going to be.
(Did you know that at least one major Mainframe company still
maintains and ships an ANSI 74 COBOL Compiler? Do you think
they do this just to annoy the standards people?)

Post by pete dashwood
I was pretty sickened by the last round and I really hope that lessons
have been learned and the new attempt will succeed. (I don't have as
much personal involvement with COBOL today as I had then, so I am more
relaxed about it either succeeding or failing, but, obviously, I'd like
to see it succeed...)

I think they should just leave it alone. After all, isn't COBOL dead?
Then why expend the energy?

It does bring up another interesting point. Let's compare two rather
obscure (by today's standards) languages. COBOL and ANSI-M (formerly
known as MUMPS). ANSI-M is used in the majority of hospitals in the
world both in the the form of the public domain VISTA EMR system and
in a number of commercial products like EPIC and CACHE. It is also
used in banking, financials and government. And yet, ANSI has said
they will not be doing another version of the standard (even though,
in my opinion, it could use some polishing up.) And then we have
COBOL which is supposed to be dead and yet they are going to do a
new standard.

Go figure!!

Post by pete dashwood
I guess time will tell.

Yes, I suppose it will.

bill

[pete dashwood]

Post by Bill Gunshannon

Post by pete dashwood

Post by Bill Gunshannon

Post by pete dashwood

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by
accreditation from national standards bodies.
Robert

Unless there is a solid commitment by a COBOL vendor to IMPLEMENT
the new standard, it is just flogging a dead horse.
We have been here before and it was not a pleasant experience.
Nevertheless, I respect the people who apply their energy to it and
sincerely hope you get a committed vendor. With this regard, I
should think that GNU COBOL are probably your best bet.
Good Luck!
Pete.

Maybe if th4e standards body was more interested in meeting the needs
of the people using the language rather than trying to redefine it
(as was done in a number of other languages as well) there might be
more acceptance of their work.
If there ever was an example of ivory-towerism, the standards bodies
are it.
bill

I take your point, Bill, but it may not be entirely fair.
The COBOL "community" has to take some responsibility.
In the past, delegates who were actually COBOL programmers and
analysts were sponsored by their Companies to be part of Standards
committees which were reviewing COBOL.
Attempts were even made to "open up" the process by allowing public
posts by "interested parties" through forums such as this one.
With one or two exceptions (most of whom are sadly no longer with
us... (Bill Klein, Jimmy Gavan, etc.) the result was resounding silence.

Maybe because the practitioners of the art were satisfied with the
product they had and didn't want outsiders mucking about with it.
Did they give Bill Klein's comments any consideration or just did
the typical academic function of "Well, your wrong and we know what
is best for the COBOL community."

Post by pete dashwood
Some delegates saw it as a "gravy train" that would look good on a CV...

While that is probably true of some, when I was a government contractor
(that was before my foray into academia)my employer provided bodies for
standard committees and user groups and we all took that as seriously as
our regular work.

Post by pete dashwood
The ones who didn't, ended up doing most of the work and receiving no
acknowledgement

Sounds like exactly what I thought and the reason I am not a supporter
of these standards bodies.  Don't tune the engine, drive the bus in a
direction the riders don't want to go.

Post by pete dashwood
(When Bill Klein tried to keep the Standards people honest by
insisting that the original COBOL "Mission Statement" from Codasyl 59
be reproduced in the new standard, he was vilified and attacked. (It
said that copies of the COBOL spec. should be free (apart from the
cost of production - no profit), as the Companies that supported the
Codasyl had already paid for the effort of formulating it. Did not go
down well with the standards people, who were looking to charge
serious sums for a copy of the Standard...) Just one example of the
"in-fighting" that went on over COBOL standards.)

I agree with Bill Klein on this completely.  Another good example is
OpenPROM.  Developed completely by Sun.  Turned over to IEEE to become
a standard.  IEEE standardized it.  I wanted to get a copy so I could
work on a version of OpenPROM for the various PDP-11's still running all
over the world.  They wanted $60,000 for me to see a copy.  Any wonder
that OpenPROM didn't become all that standard?

Post by pete dashwood
As COBOL's position as a development language declined, and as major
vendors did not implement the standards anyway, Companies were less
inclined to sponsor delegates to Standards committees.

And yet the standards body is going to create yet another standard
with no input from the practitioners of the art that does not meet
their needs and then wonder why it doesn't get accepted?

Post by pete dashwood
Serious COBOL vendors attempted to also distance themselves from the
Standards fiasco,

See above.  Why should they back something that is counter-productive?

Post by pete dashwood
                   and so you get the situation today, where it looks
like "ivory towerism" because there is little "shop floor" involvement
in the process.

You have put the cart before the horse.  It is "ivory towerism"
because they don't give serious consideration to the people who
really know what the language needs to be to do the job?  And the
result is those same practitioners see no reason to waste time
when, in the end, they will be the ones who decide what COBOL is
really going to be.
(Did you know that at least one major Mainframe company still
maintains and ships an ANSI 74 COBOL Compiler?  Do you think
they do this just to annoy the standards people?)

Post by pete dashwood
I was pretty sickened by the last round and I really hope that lessons
have been learned and the new attempt will succeed. (I don't have as
much personal involvement with COBOL today as I had then, so I am more
relaxed about it either succeeding or failing, but, obviously, I'd
like to see it succeed...)

I think they should just leave it alone.  After all, isn't COBOL dead?
Then why expend the energy?
It does bring up another interesting point.  Let's compare two rather
obscure (by today's standards) languages.  COBOL and ANSI-M (formerly
known as MUMPS).  ANSI-M is used in the majority of hospitals in the
world both in the the form of the public domain VISTA EMR system and
in a number of commercial products like EPIC and CACHE.  It is also
used in banking, financials and government. And yet, ANSI has said
they will not be doing another version of the standard (even though,
in my opinion, it could use some polishing up.)  And then we have
COBOL which is supposed to be dead and yet they are going to do a
new standard.
Go figure!!

Post by pete dashwood
I guess time will tell.

Yes, I suppose it will.
bill

Thanks for your response, Bill.

I have nothing more to add.

Pete.

[d***@gmail.com]

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

Interesting comments by those who have no idea what actually happened during the development of the COBOL standards. I was there from 1973 to the final standard (I was chairman of the CODASYL COBOL Committee from 1978 or thereabouts to 1998 when it was combined with the ANSI (later NICTS) COBOL committee. I was project editor of the 2002 and the 2014 standards. Yeah, I was one of those evil vendors (Control Data and Tandem/Compaq/HP -- 13 different compilers) who apparently ignored everyone who was real. Actually, that was not the case at all. We were not an ivory tower group and accepted input form everyone, including Bill Klein. Bill's primary effort seemed to be in derailing what we were doing and delaying the completion of each standard. We read and discussed every input we received from anyone, including Bill. We even held events to get inputs. Especially for COBOL 85. We had a "structured programming" event to get ideas on what was needed. I spent quite a bit of time talking to user groups and individuals about what was needed. Our primary goal was to specify what the users wanted. I think we accomplished that. So, I think that vilifying us is not quite fair.

Don Nelson

[Robert Wessel]

Post by d***@gmail.com

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

Interesting comments by those who have no idea what actually happened during the development of the COBOL standards. I was there from 1973 to the final standard (I was chairman of the CODASYL COBOL Committee from 1978 or thereabouts to 1998 when it was combined with the ANSI (later NICTS) COBOL committee. I was project editor of the 2002 and the 2014 standards. Yeah, I was one of those evil vendors (Control Data and Tandem/Compaq/HP -- 13 different compilers) who apparently ignored everyone who was real. Actually, that was not the case at all. We were not an ivory tower group and accepted input form everyone, including Bill Klein. Bill's primary effort seemed to be in derailing what we were doing and delaying the completion of each standard. We read and discussed every input we received from anyone, including Bill. We even held events to get inputs. Especially for COBOL 85. We had a "structured programming" event to get ideas on what was needed. I spent quite a bit of time talking

to

Post by d***@gmail.com
user groups and individuals about what was needed. Our primary goal was to specify what the users wanted. I think we accomplished that. So, I think that vilifying us is not quite fair.

Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest. And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*. Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.

Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future. And the Cobol community was/is particularly insular.

At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it. The poor souls on the committee are not to blame.


*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

[pete dashwood]

On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest. And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*. Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future. And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it. The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.

I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

For me, the best point is the one you mentioned above: vendors won't
implement it unless they can make money with it. (Given that they are
not philanthropists, I guess it is an understandable position...)

I'm not entirely in agreement with the idea that the vendors and the
users killed it (17 years to produce a standard has to be laid at the
door of the Standards body...) but I agree that the reasons for the
demise of COBOL probably involve everybody mentioned, along with other
external factors in the marketplace.

I believe that the single most important contributor to the decline of
COBOL was the lack of recognition by everyone involved with COBOL, that
the paradigm changed with the advent of Networks. Even though a
fantastic feat of software engineering (extending COBOL to support OOP)
allowed COBOL to play on the new playing field, most of the Community
rejected it.

I've posted a series of pages covering my thoughts on this at:

https://primacomputing.co.nz/PRIMAMetro/objectsandlayers.aspx

People are encouraged to post their thoughts on the site Lounge Bar or
back here in this forum.

Pete.

[Arnold Trembley]

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.  And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*.  Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future.  And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it.  The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

I believe this is the Travelers referred to:

https://en.wikipedia.org/wiki/The_Travelers_Companies

Basically, a very large insurance company. Insurance companies in the
USA were traditionally very big users of COBOL.

I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding. But my memory might be
as porous as DocDwarf's.

Post by pete dashwood
For me, the best point is the one you mentioned above: vendors won't
implement it unless they can make money with it. (Given that they are
not philanthropists, I guess it is an understandable position...)
I'm not entirely in agreement with the idea that the vendors and the
users killed it (17 years to produce a standard has to be laid at the
door of the Standards body...) but I agree that the reasons for the
demise of COBOL probably involve everybody mentioned, along with other
external factors in the marketplace.
I believe that the single most important contributor to the decline of
COBOL was the lack of recognition by everyone involved with COBOL, that
the paradigm changed with the advent of Networks. Even though a
fantastic feat of software engineering (extending COBOL to support OOP)
allowed COBOL to play on the new playing field, most of the Community
rejected it.
https://primacomputing.co.nz/PRIMAMetro/objectsandlayers.aspx
People are encouraged to post their thoughts on the site Lounge Bar or
back here in this forum.
Pete.

[Bill Gunshannon]

Post by Arnold Trembley

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.  And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*.  Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future.  And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it.  The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

https://en.wikipedia.org/wiki/The_Travelers_Companies
Basically, a very large insurance company.  Insurance companies in the
USA were traditionally very big users of COBOL.

Still are.

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.  But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it. Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard. I am certainly a
strong believer in "If it ain't broke, don't fix it". But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened. The 1985
standard was probably the biggest improvement since COBOL's
inception and 2002 added more useful features, but the attempt
to ram OO down the throats of COBOL shops was probably it's
biggest mistake. It was resoundingly rejected and for good
reason. For the tasks COBOL was used for it brought nothing
to the table but added complexity. One paradigm does not fit
all. It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago. The supposed decline is not really a
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

bill




bill

[Robert Wessel]

On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon

Post by Bill Gunshannon

Post by Arnold Trembley

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.  And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*.  Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future.  And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it.  The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

https://en.wikipedia.org/wiki/The_Travelers_Companies
Basically, a very large insurance company.  Insurance companies in the
USA were traditionally very big users of COBOL.

Still are.

That's them. Although they've been bought, merged, sold, spun off,
split, folded, spindled and mutilated so many times since the early
eighties that it would probably take a team of forensic financial
archeologists to determine just what parts are still there from back
then.

Post by Bill Gunshannon

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.  But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it. Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard. I am certainly a
strong believer in "If it ain't broke, don't fix it". But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.

They did, and not, it didn't/doesn't make sense. They were basically
at the point of demanding that *no* new keywords were to be introduced
into the language* because of the (supposedly) high cost that would
impose on them for the conversion. As I said, they were literally
threatening a lawsuit against the committee to stop that sort of
thing.


*Good luck doing anything with the Cobol standard with that
restriction in place.

Post by Bill Gunshannon
The 1985
standard was probably the biggest improvement since COBOL's
inception and 2002 added more useful features, but the attempt
to ram OO down the throats of COBOL shops was probably it's
biggest mistake. It was resoundingly rejected and for good
reason. For the tasks COBOL was used for it brought nothing
to the table but added complexity. One paradigm does not fit
all. It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago. The supposed decline is not really a
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

Let's just agree to disagree on that, rather the rehashing that old
discussion again, except to say that the '85 debacle was one of the
major reasons there was the very long gap between '85 and '02, Cobol
would have been well served by several smaller updates during that
interval.

[Spiros Bousbouras]

On Tue, 21 Nov 2017 12:00:30 -0600

Post by Robert Wessel
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon

Post by Bill Gunshannon
That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it. Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard. I am certainly a
strong believer in "If it ain't broke, don't fix it". But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.

They did, and not, it didn't/doesn't make sense. They were basically
at the point of demanding that *no* new keywords were to be introduced
into the language* because of the (supposedly) high cost that would
impose on them for the conversion. As I said, they were literally
threatening a lawsuit against the committee to stop that sort of
thing.

Would such a lawsuit have any chance of succeeding ? I mean did they
have any half solid legal basis ?

[Bill Gunshannon]

Post by Spiros Bousbouras
On Tue, 21 Nov 2017 12:00:30 -0600

Post by Robert Wessel
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon

Post by Bill Gunshannon
That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it. Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard. I am certainly a
strong believer in "If it ain't broke, don't fix it". But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.

They did, and not, it didn't/doesn't make sense. They were basically
at the point of demanding that *no* new keywords were to be introduced
into the language* because of the (supposedly) high cost that would
impose on them for the conversion. As I said, they were literally
threatening a lawsuit against the committee to stop that sort of
thing.

Would such a lawsuit have any chance of succeeding ? I mean did they
have any half solid legal basis ?

That's one of the reasons the whole thing sounds so bogus.
There is nothing there that could possibly result in a lawsuit.
No one was being harmed. If the Standards guys wanted to waste
a whole bunch of their time devising a standard no one wanted
and no one was going to use that was their right. Now, if they
had threatened to force the users to use it through the courts
(which would have been just as ridiculous) then maybe they
could have fought it out but I doubt any court in the world
would have listened to either party and they ran the chance of
being charged with a frivolous lawsuit which is a triable
offense. :-)

Sounds a lot like the Ada and the Air Force debacle.

bill

[Robert Wessel]

Post by Spiros Bousbouras
On Tue, 21 Nov 2017 12:00:30 -0600

Post by Robert Wessel
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon

Post by Bill Gunshannon
That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it. Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard. I am certainly a
strong believer in "If it ain't broke, don't fix it". But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.

They did, and not, it didn't/doesn't make sense. They were basically
at the point of demanding that *no* new keywords were to be introduced
into the language* because of the (supposedly) high cost that would
impose on them for the conversion. As I said, they were literally
threatening a lawsuit against the committee to stop that sort of
thing.

Would such a lawsuit have any chance of succeeding ? I mean did they
have any half solid legal basis ?

You can sue anyone, for any reason, in the US. You're chances of
success are a whole different matter. I'm not of the opinion that
they could have won in court, but they might well have been able to
impose intolerable costs on the Cobol committee to defend themselves.
The problem with even unreasonable lawsuits, is that you can't just
ignore them, or will lose by default.

But in case anyone doubts either the threat, or the utter resistance
to any standard not providing "complete upwards compatibility"*, this
was on the front page of Computerworld on January 26, 1981:

https://books.google.com/books?id=d514ApKzvjYC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false



*"We must go on record as being unalterable opposed to this [Cobol-80]
standard because it does not provide complete upward compatibility".

[Rick Smith]

On Tuesday, November 21, 2017 at 4:59:59 PM UTC-5, ***@yahoo.com wrote:

[snip]

Post by Robert Wessel
But in case anyone doubts either the threat, or the utter resistance
to any standard not providing "complete upwards compatibility"*, this
https://books.google.com/books?id=d514ApKzvjYC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
*"We must go on record as being unalterable opposed to this [Cobol-80]
standard because it does not provide complete upward compatibility".

On page 8 of the same issue, with the title,
"Sites Asked to Comment On Ansi Cobol-80 Standard"

"Efforts to elicit a response to the proposed
X3J4 standard from other Cobol users were
largely unsuccessful possibly because, as one
manager said, "we haven't been paying attention
to it."

[pete dashwood]

Post by Rick Smith
[snip]

Post by Robert Wessel
But in case anyone doubts either the threat, or the utter resistance
to any standard not providing "complete upwards compatibility"*, this
https://books.google.com/books?id=d514ApKzvjYC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
*"We must go on record as being unalterable opposed to this [Cobol-80]
standard because it does not provide complete upward compatibility".

On page 8 of the same issue, with the title,
"Sites Asked to Comment On Ansi Cobol-80 Standard"
"Efforts to elicit a response to the proposed
X3J4 standard from other Cobol users were
largely unsuccessful possibly because, as one
manager said, "we haven't been paying attention
to it."

Amazing! Thanks for posting that, Rick.

Pete.

[pete dashwood]

Post by Bill Gunshannon

Post by Arnold Trembley

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.  And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*.  Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future.  And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it.  The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

https://en.wikipedia.org/wiki/The_Travelers_Companies
Basically, a very large insurance company.  Insurance companies in the
USA were traditionally very big users of COBOL.

Still are.

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed
any changes to COBOL that would require re-coding.  But my memory
might be as porous as DocDwarf's.

That makes little sense.  Just because the standard changes
doesn't mean you have to recode to meet it.  Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard.  I am certainly a
strong believer in "If it ain't broke, don't fix it".  But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.  The 1985
standard was probably the biggest improvement since COBOL's
inception and 2002 added more useful features, but the attempt
to ram OO down the throats of COBOL shops was probably it's
biggest mistake.

Nobody attempted to ram it down your throat, Bill. As always, it was
entirely over to users whether or not they implement a new Standard.

For most mainframe shops where the procedural paradigm had been
entrenched for decades and was working fine, it is understandable that
OO was rejected as not necessary.

It is really when you come to move to a networked solution that the need
for OO becomes apparent. (I covered WHY this is so in the pages
referenced in my previous post.) People needed to move to networked
solutions not just because the cost is less compared to a mainframe
solution, but, much more importantly, because the world has changed and
the way we do business has changed. (Again, covered in pages on the web
site)

Post by Bill Gunshannon
It was resoundingly rejected and for good
reason.  For the tasks COBOL was used for it brought nothing
to the table but added complexity.

It depends what you call a "good reason"... If resistance to change,
apathy, and short-sightedness are good reasons, then... OK. :-)

As for complexity, that is a subjective and relative assessment. Things
some people find complex, others have no problem with at all, and vice
versa.

I guess if a programmer's aspirations go no further than writing simple
English on a coding pad with a crayon, then there is probably no need to
go beyond doing that. For myself, I still get excited by innovation and
I make a point of teaching myself new stuff to keep my mind working.





One paradigm does not fit

Post by Bill Gunshannon
all.  It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago.

And it is interesting that some people don't accept that Gartner
themselves withdrew those assessments over a decade ago. Gartner are not
an unbiased source; they take money from COBOL vendors. Even if
everything they claimed was true, I hope you don't honestly think that
COBOL is enjoying the popularity it did in the last century?




The supposed decline is not really a

Post by Bill Gunshannon
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

And that unconfirmable base of "billions of lines" is eroded every year
by people voting with their feet and moving off COBOL.

If by "serious businesses" (and I never met anyone who ran a business
and didn't think it was serious), you are referring to Banks and
Insurance Companies, then think again. More and more of their IT
infrastructure is becoming networked and COBOL has no place in it.

Some of these institutions (particularly in the USA) retain COBOL
because they have little choice, but they are under no illusion that
eventually they will HAVE to let it go.

Pete.

[d***@panix.com]

[snip]

Post by Bill Gunshannon

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.?? But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it.

Try getting AFTER POSITIONING or TRANSLATE to compile under IGYCRCTL, Mr
Gunshannon.

Classic cost/benefit or ROI:

Given that scope delimiters, reference modification and EVALUATION are
'good things to have' - not 'necessary', one can 'code around them', just
as one can code ASM systems using only RR and RX instructions - but given
they are 'good to have' then recoding will be necessary.

[snip]

Post by Bill Gunshannon
It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago. The supposed decline is not really a
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

Lines of code is best left for other discussions... but if the same number
users exist while the overall number of users has increased then one has a
classic example of 'losing share'.

DD

[Bill Gunshannon]

Post by Rick Smith
[snip]

Post by Bill Gunshannon

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.?? But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it.

Try getting AFTER POSITIONING or TRANSLATE to compile under IGYCRCTL, Mr
Gunshannon.

I have no idea what "IGYCRCT" is. But the I stand by what
said. If your code is already running why would you need
to change or recompile it? Also, as I mentioned already,
Unisys still maintains and ships ACOB, a 1974 Standard compiler.
The same one I used 37 years ago. They have a new one, but
no one makes you use it.

Post by Rick Smith
Given that scope delimiters, reference modification and EVALUATION are
'good things to have' - not 'necessary', one can 'code around them', just
as one can code ASM systems using only RR and RX instructions - but given
they are 'good to have' then recoding will be necessary.

Yes, but the choice is the user. As you said, ROI. If a user
thinks it is worth the cost of recoding, then have at it, but
no one is forced to do it because some Standards body decided
they didn't like the language. I still work on systems that
have a K&R C Compiler. It's not going to change no matter what
the ANSI C Standards Committee decides to do.

Post by Rick Smith
[snip]

Post by Bill Gunshannon
It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago. The supposed decline is not really a
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

Lines of code is best left for other discussions... but if the same number
users exist while the overall number of users has increased then one has a
classic example of 'losing share'.

Losing Share != going away. If the number of lines of COBOL has
not significantly decreased then the number of programmers needed
to maintain that code has also not decreased. Academia continuing
to refuse to teach COBOL and worse still telling students learning
COBOL will adversely affect their careers (yes, I have known
professors who did just that!) is a terrible dis-service not
only to the business that require those programmers, but to the
students as well.

bill

[Robert Wessel]

On Wed, 22 Nov 2017 08:24:50 -0500, Bill Gunshannon

Post by Bill Gunshannon

Post by Rick Smith
[snip]

Post by Bill Gunshannon

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.?? But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it.

Try getting AFTER POSITIONING or TRANSLATE to compile under IGYCRCTL, Mr
Gunshannon.

I have no idea what "IGYCRCT" is. But the I stand by what
said. If your code is already running why would you need
to change or recompile it? Also, as I mentioned already,
Unisys still maintains and ships ACOB, a 1974 Standard compiler.
The same one I used 37 years ago. They have a new one, but
no one makes you use it.

FWIW, it's the phase name for IBM Enterprise Cobol. The complaint is
that the new(ish) compiler lacks support for some items the older
compilers supported.

But I agree, you'd expect that a vendor could/would either maintain an
older compiler for some time to support the prior language dialect, or
offer a dialect option on the new compiler.

But I suspect the assumption by Travelers, et al, was that they'd be
forced to make the jump eventually, if only to take advantage of new
features, or general support in the community. And I don't think an
assumption of indefinite support by the vendor is really reasonable,
even if it has actually worked out that way in some cases (and let's
face it, the areas where Cobol are used are not exactly the most
dynamic in computing anymore, which helps that sort of longevity). It
doesn't make their actions reasonable, however.

[d***@panix.com]

Post by Bill Gunshannon

Post by Rick Smith
[snip]

Post by Bill Gunshannon

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.?? But my memory might be
as porous as DocDwarf's.

That makes little sense. Just because the standard changes
doesn't mean you have to recode to meet it.

Try getting AFTER POSITIONING or TRANSLATE to compile under IGYCRCTL, Mr
Gunshannon.

I have no idea what "IGYCRCT" is.

IGYCRCTL is the IBM mainframe compiler for COBOLII (later COBOL '85)that
replaced IKFCBL00.

Post by Bill Gunshannon
But the I stand by what
said. If your code is already running why would you need
to change or recompile it?

Code is a response to a situation and some situations change. Refusing to
recompile locks an organisation into a software/hardware architecture.

No, calculating compound interest isn't going to change much any time
soon.

Yes, a company can grow and code that was 'perfectly good' now isn't. One
client I had was accustomed to having only five divisions and everywhere
was coded OCCURS(5).

Post by Bill Gunshannon
Also, as I mentioned already,
Unisys still maintains and ships ACOB, a 1974 Standard compiler.
The same one I used 37 years ago. They have a new one, but
no one makes you use it.

If your business needs are met by the limits of forty-some year old
software, well and good. Some accountants still wear green eye-shades,
arm-garters and fountain pens.

Post by Bill Gunshannon

Post by Rick Smith
Given that scope delimiters, reference modification and EVALUATION are
'good things to have' - not 'necessary', one can 'code around them', just
as one can code ASM systems using only RR and RX instructions - but given
they are 'good to have' then recoding will be necessary.

Yes, but the choice is the user. As you said, ROI. If a user
thinks it is worth the cost of recoding, then have at it, but
no one is forced to do it because some Standards body decided
they didn't like the language. I still work on systems that
have a K&R C Compiler. It's not going to change no matter what
the ANSI C Standards Committee decides to do.

The hardware on which the software runs gets old just as we do, Mr
Gunshannon. The IBM 1401 was so popular that software emulators for it
ran at some shops until the 1980s.

[snip]

Post by Bill Gunshannon

Post by Rick Smith

Post by Bill Gunshannon
It is interesting that people like Gartner still quote
the same number of users and lines of code for COBOL that
they did 20 years ago. The supposed decline is not really a
decline as much as it is a wealth of new code in other
languages that skew the statistics while COBOL remains with
billions of lines of code and a major portion of the serious
businesses running on it.

Lines of code is best left for other discussions... but if the same number
users exist while the overall number of users has increased then one has a
classic example of 'losing share'.

Losing Share != going away.

I don't believe I said otherwise.

DD

[pete dashwood]

Post by Arnold Trembley

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.  And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*.  Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future.  And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it.  The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?

https://en.wikipedia.org/wiki/The_Travelers_Companies
Basically, a very large insurance company.  Insurance companies in the
USA were traditionally very big users of COBOL.
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.  But my memory might be
as porous as DocDwarf's.

Thanks for that, Arnold.
<snipped>

Pete.

[d***@panix.com]

In article <2KCdnfFyB4S7TI7HnZ2dnUU7-***@giganews.com>,
Arnold Trembley <***@att.net> wrote:

[snip]

Post by Arnold Trembley
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding. But my memory might be
as porous as DocDwarf's.

I did a short contract at One Travelers Plaza in Hartford, Connecticut,
USA not too far back... 1993 or so. There were definitely 'camps' among
the programming groups; some embraced the recent Standard and others
regarded it as heresy.

My group was mixed... and I served as Keeper of Ye Anciente Knowledge.
Whenever there rose a heated debate about which constructs to use I'd
compile with a PMAP and bring the disputants into the Temple of Truth.

For the inevitable yowls of 'it wasn't like that with the old compiler!' I
would dig into the 'secret' libraries and work a LIST out of IKFCBL00...
my personal favorites were STRING and INSPECT... REPLACING. THey became
fast enough to use in CICS.

DD

[Robert Wessel]

On Tue, 21 Nov 2017 13:12:42 +1300, pete dashwood

Post by pete dashwood
<snipped>

Post by Robert Wessel
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest. And that was pretty
much a debacle, including a delay of half a decade, due almost solely
to a vocal and pettily obstinate portion of the *user* community, one
of the leaders of which was Travelers*. Counting the aftermath, which
left everyone too exhausted to do anything for a few years afterwards,
that did a decade's worth of damage to the language by itself.
Current user input is important, but current users tend to highly
focused on today's job, and are usually pretty bad at planning the
future. And the Cobol community was/is particularly insular.
At this point you have the problem that most of the vendors won't do
anything that doesn't allow them to extract a pound of flesh from the
users, and half the users scream "heresy!" about anything post-85 (and
heck, a bunch of Cobol-85 stuff is still considered esoteric by many).
While I've never made any secret of the fact that I don't think Cobol
is a good language (an interesting experiment that produced a negative
result), it's been the vendors and the users that have really killed
it. The poor souls on the committee are not to blame.
*I don't remember if it was that whole group, or just Travelers, that
was actually threatening to sue the committee because they had some
(fairly petty) issues with the way the standard was developing.

An interesting post, Robert.
I'm unfamiliar with "Travelers"; is it a Company or a user group, or
something else?
For me, the best point is the one you mentioned above: vendors won't
implement it unless they can make money with it. (Given that they are
not philanthropists, I guess it is an understandable position...)

While they're not, if the decision is only "will this bring us more
revenue", then vendors that have a captive and static market (IOW,
most everyone playing in the Cobol market), have *no* incentive to do
anything new. IBM is not going to sell any more Cobol licenses, or
mainframes, if the implement the latest standard, not matter how much
their users might like it. So while they may get there eventually,
it's not much of a priority.

Post by pete dashwood
I'm not entirely in agreement with the idea that the vendors and the
users killed it (17 years to produce a standard has to be laid at the
door of the Standards body...) but I agree that the reasons for the
demise of COBOL probably involve everybody mentioned, along with other
external factors in the marketplace.

In the sense that nobody wanted to go near it for the better part of a
decade after the '85 debacle.

Post by pete dashwood
I believe that the single most important contributor to the decline of
COBOL was the lack of recognition by everyone involved with COBOL, that
the paradigm changed with the advent of Networks. Even though a
fantastic feat of software engineering (extending COBOL to support OOP)
allowed COBOL to play on the new playing field, most of the Community
rejected it.

I've heard a joke that by the time the '02 standard rolled around, and
the vendors deigned to provide implementations, and the
implementations reached the programmers, the only ones left using
Cobol were the programmers still bitter from being forced into
structured programming. That's obviously a gross exaggeration, but
the user community *is* hugely insular, and extremely (technically)
conservative - many shops appear to still be avoiding nested
subprograms. Much of the management under which much of the Cobol
community works is even worse.

Post by pete dashwood
https://primacomputing.co.nz/PRIMAMetro/objectsandlayers.aspx
People are encouraged to post their thoughts on the site Lounge Bar or
back here in this forum.
Pete.

[pete dashwood]

Post by d***@gmail.com

Post by 0***@gmail.com
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.
Robert

Interesting comments by those who have no idea what actually happened during the development of the COBOL standards. I was there from 1973 to the final standard (I was chairman of the CODASYL COBOL Committee from 1978 or thereabouts to 1998 when it was combined with the ANSI (later NICTS) COBOL committee. I was project editor of the 2002 and the 2014 standards. Yeah, I was one of those evil vendors (Control Data and Tandem/Compaq/HP -- 13 different compilers) who apparently ignored everyone who was real. Actually, that was not the case at all. We were not an ivory tower group and accepted input form everyone, including Bill Klein. Bill's primary effort seemed to be in derailing what we were doing and delaying the completion of each standard. We read and discussed every input we received from anyone, including Bill. We even held events to get inputs. Especially for COBOL 85. We had a "structured programming" event to get ideas on what was needed. I spent quite a bit of time talking to user groups and individuals about what was needed. Our primary goal was to specify what the users wanted. I think we accomplished that. So, I think that vilifying us is not quite fair.
Don Nelson

Thanks for posting this; it is right and proper that your view should be
heard.

For myself, I posted what my perception was; it was not intended as a
personal attack on anyone. (I ALWAYS "call 'em as I see 'em" and am open
to have that perception debated...)

I still believe that the treatment of Bill Klein was shabby and I know
it was never his intention to derail the process. (Quite the opposite,
in fact. Bill cared passionately about COBOL and was truly "expert" on
the subject.)

We had several conversations by phone between Chicago and Europe and I
know how seriously upset he was by what was going on. He asked me if I
would be prepared to come over and help him with his case. I said I
would make myself available if he needed it.

Certainly, there was not as much support for the process as might have
been expected and I have already stated here that the COBOL community
could have done more.

The results are what the effort has to be judged by.

Pete.
--