For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.How much of the last two standards has been implemented (2002? and
Robert
For those who may wish to participate, this is being done by ISO byaccreditation from national standards bodies.
Robert
On Fri, 10 Nov 2017 14:54:07 -0800 (PST), 0robert.jones@gmail.com
wrote:
For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.How much of the last two standards has been implemented (2002? and
Robert
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
On 11/11/2017 11:54 AM, 0robert.jones@gmail.com wrote:
For those who may wish to participate, this is being done by ISO byUnless there is a solid commitment by a COBOL vendor to IMPLEMENT the
accreditation from national standards bodies.
Robert
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.
On 11/10/2017 09:08 PM, pete dashwood wrote:
On 11/11/2017 11:54 AM, 0robert.jones@gmail.com wrote:
For those who may wish to participate, this is being done by ISO byUnless there is a solid commitment by a COBOL vendor to IMPLEMENT the
accreditation from national standards bodies.
Robert
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
On 12/11/2017 10:01 AM, Bill Gunshannon wrote:
On 11/10/2017 09:08 PM, pete dashwood wrote:I take your point, Bill, but it may not be entirely fair.
On 11/11/2017 11:54 AM, 0robert.jones@gmail.com wrote:
For those who may wish to participate, this is being done by ISO byUnless there is a solid commitment by a COBOL vendor to IMPLEMENT the
accreditation from national standards bodies.
Robert
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
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.
On 11/12/2017 09:49 PM, pete dashwood wrote:
On 12/11/2017 10:01 AM, Bill Gunshannon wrote:
On 11/10/2017 09:08 PM, pete dashwood wrote:I take your point, Bill, but it may not be entirely fair.
On 11/11/2017 11:54 AM, 0robert.jones@gmail.com wrote:
For those who may wish to participate, this is being done by ISO by >>>>> accreditation from national standards bodies.Unless there is a solid commitment by a COBOL vendor to IMPLEMENT
Robert
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
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."
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.
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.-a Don't tune the engine, drive the bus in a direction the riders don't want to go.
(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.-a Another good example is OpenPROM.-a Developed completely by Sun.-a Turned over to IEEE to become
a standard.-a IEEE standardized it.-a 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.-a They wanted $60,000 for me to see a copy.-a Any wonder
that OpenPROM didn't become all that standard?
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?
Serious COBOL vendors attempted to also distance themselves from the
Standards fiasco,
See above.-a Why should they back something that is counter-productive?
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a 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.-a 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?-a 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?-a Do you think
they do this just to annoy the standards people?)
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.-a After all, isn't COBOL dead?
Then why expend the energy?
It does bring up another interesting point.-a Let's compare two rather obscure (by today's standards) languages.-a COBOL and ANSI-M (formerly
known as MUMPS).-a 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.-a 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.)-a And then we have
COBOL which is supposed to be dead and yet they are going to do a
new standard.
Go figure!!
I guess time will tell.
Yes, I suppose it will.
bill
For those who may wish to participate, this is being done by ISO byaccreditation from national standards bodies.
RobertInteresting 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
On Friday, November 10, 2017 at 2:54:08 PM UTC-8, 0rober...@gmail.com wrote: >> For those who may wish to participate, this is being done by ISO by accreditation from national standards bodies.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
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
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.
On Friday, November 10, 2017 at 2:54:08 PM UTC-8, 0rober...@gmail.com wrote: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
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
Don Nelson
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.
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.-a 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*.-a 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.-a 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.-a 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.
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.
On 11/20/2017 6:12 PM, pete dashwood wrote:
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.-a 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*.-a 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.-a 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.-a 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.
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.-a 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.-a But my memory might be
as porous as DocDwarf's.
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
On 11/20/2017 6:12 PM, pete dashwood wrote:
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
Back in the '85 era, I had considerably more interest in the standard, >>>> and watched its development with fair interest.a 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*.a 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.a 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.a 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.
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.a Insurance companies in the
USA were traditionally very big users of COBOL.
Still are.
I seem to recall reading something years ago that Travelers opposed any
changes to COBOL that would require re-coding.a 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.
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
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.
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.
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
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.
On Tue, 21 Nov 2017 12:00:30 -0600
Robert Wessel <robertwessel2@yahoo.com> wrote:
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon
<bill.gunshannon@gmail.com> wrote:
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 ?
On Tue, 21 Nov 2017 12:00:30 -0600
Robert Wessel <robertwessel2@yahoo.com> wrote:
On Tue, 21 Nov 2017 08:20:28 -0500, Bill Gunshannon
<bill.gunshannon@gmail.com> wrote:
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 ?
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".
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
On 11/20/2017 6:12 PM, pete dashwood wrote:
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
Back in the '85 era, I had considerably more interest in the standard, >>>> and watched its development with fair interest.-a 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*.-a 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.-a 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.-a 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.
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.-a Insurance companies in the
USA were traditionally very big users of COBOL.
Still are.
I seem to recall reading something years ago that Travelers opposed
any changes to COBOL that would require re-coding.-a But my memory
might be as porous as DocDwarf's.
That makes little sense.-a Just because the standard changes
doesn't mean you have to recode to meet it.-a Unisys still
maintains and ships ACOB, their 1974 standard compiler, as
well as one meeting the newer standard.-a I am certainly a
strong believer in "If it ain't broke, don't fix it".-a But
I am also sure that had Traveler's told their system vendor
"keep the old compiler" it would have happened.-a 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.-a For the tasks COBOL was used for it brought nothing
to the table but added complexity.
all.-a 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.
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.
On 11/20/2017 6:12 PM, pete dashwood wrote:
On 20/11/2017 5:24 PM, Robert Wessel wrote:
<snipped>
An interesting post, Robert.
Back in the '85 era, I had considerably more interest in the standard,
and watched its development with fair interest.-a 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*.-a 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.-a 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.-a 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.
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.-a 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.-a But my memory might be
as porous as DocDwarf's.
On Tuesday, November 21, 2017 at 4:59:59 PM UTC-5, robert...@yahoo.com wrote:
[snip]
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".
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."
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.
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
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.
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.
In article <f7ingtFmp68U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
[snip]
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]
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'.
On 11/22/2017 07:15 AM, docdwarf@panix.com wrote:
In article <f7ingtFmp68U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
[snip]
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.
On 11/22/2017 07:15 AM, docdwarf@panix.com wrote:
In article <f7ingtFmp68U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
On 11/21/2017 02:09 AM, Arnold Trembley wrote:
[snip]
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.
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,007 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 184:50:54 |
| Calls: | 13,137 |
| Calls today: | 2 |
| Files: | 186,574 |
| D/L today: |
485 files (104M bytes) |
| Messages: | 3,305,065 |