Home > Archive > Cobol > May 2005 > Cobol history question -- lawsuit against standards committee
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Cobol history question -- lawsuit against standards committee
|
|
| beliavsky@aol.com 2005-05-18, 8:55 pm |
| In comp.lang.fortran , a reliable person recently wrote that Travellers
Inc (the insurance company?) sued the Cobol standards committee, I
think (based on the post) in the 1980s. Can anyone shed light on this?
I am just wondering on what basis a standards committee could be sued.
One can search "cobol fortran 2008" in comp.lang.fortran to find the
message I am talking about.
| |
| Richard 2005-05-18, 8:55 pm |
| > Can anyone shed light on this?
Google should be your friend. It found this in about 0.1 seconds.
""" In the early o1980s, COBOL bashing took a turn for the worse.
Serious efforts were underway to "kill" COBOL. In preparation for
the publication of ISO/ANSI COBOL 85, there were serious legal and
lobbying attempts (led by Travelers Insurance and joined by other
respectable corporations) to block any new COBOL standardization
effort. Some wanted to freeze the COBOL language as described in the
ANSI COBOL 74 standard. Others wanted to roll back the COBOL standard
to its "official" COBOL 68 version. The argument offered by these
groups was that it involved a great corporate cost to update their
enterprise applications in order for older COBOL programs to compile
cleanly in newer COBOL compilers. No one told them that they didn't
need to recompile any programs unless the business application required
updating."""
| |
| William M. Klein 2005-05-18, 8:55 pm |
| For someone who knows COBOL, this "law suit" (I think it was threatened not
submitted - but I could be in error on this) is what (eventually) led to the new
"OBSOLETE" classification in the '85 Standard.
The initial draft of what eventually became the '85 Standard actually DROPPED
several (all? many?) of the items that eventually were classified as "OBSOLETE".
By the time the '85 Standard was approved, these items were "kept in" BUT the
Standard said they would be dropped from the next revision (and in deed they
were - in the '02 Standard).
The '02 Standard introduced "ARCHAIC" as well as "OBSOLETE'. These were items
identified as in "too wide a use" to be dropped in the next Standard but when/if
they ever were NOT used widely, they MIGHT become OBSOLETE (and then dropped).
All of this, of course, has NOTHING to do with what implementor have (and
continue to) do, i.e. I haven't heard of any implementors "rushing" to drop
support (as an extension) of any of the '85 Standard "Obsolete" items (with the
possible exception of the ENTER statement which was always something of an
oddity - and some items that were OPTIONAL in the '85 Standard and not supported
universally in the first place).
--
Bill Klein
wmklein <at> ix.netcom.com
<beliavsky@aol.com> wrote in message
news:1116447182.706044.116990@g47g2000cwa.googlegroups.com...
> In comp.lang.fortran , a reliable person recently wrote that Travellers
> Inc (the insurance company?) sued the Cobol standards committee, I
> think (based on the post) in the 1980s. Can anyone shed light on this?
> I am just wondering on what basis a standards committee could be sued.
>
> One can search "cobol fortran 2008" in comp.lang.fortran to find the
> message I am talking about.
>
| |
| Clark Morris 2005-05-24, 3:55 pm |
| On 18 May 2005 13:32:13 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>Google should be your friend. It found this in about 0.1 seconds.
>
>""" In the early o1980s, COBOL bashing took a turn for the worse.
>Serious efforts were underway to "kill" COBOL. In preparation for
>the publication of ISO/ANSI COBOL 85, there were serious legal and
>lobbying attempts (led by Travelers Insurance and joined by other
>respectable corporations) to block any new COBOL standardization
>effort. Some wanted to freeze the COBOL language as described in the
>ANSI COBOL 74 standard. Others wanted to roll back the COBOL standard
>to its "official" COBOL 68 version. The argument offered by these
>groups was that it involved a great corporate cost to update their
>enterprise applications in order for older COBOL programs to compile
>cleanly in newer COBOL compilers. No one told them that they didn't
>need to recompile any programs unless the business application required
>updating."""
The complaint was not that new things were being added but rather that
current syntax was being dropped. In addition the interpretation of
current syntax was being changed. The classic case of change I have
yet to understand is from EXAMINE to INSPECT. The ALTER verb was
being dropped. As I pointed out in the SHARE COBOL project at the
time, people should be barred from using it in new programs but I
would hate to not have been able to recompile the payroll and
marketing programs I wrote in the late 1960's and early 1970's just
because the compiler changed. (The payroll programs were later
replaced by a package and needed a major rewrite if they were to
survive. The marketing programs lasted far longer than they should
for various reasons. I hope they aren't still running.) The problem
was two fold. The first was where the COBOL committee was changing
existing standardized syntax by deletion (ALTER), replacement (EXAMINE
by INSPECT) or change in definition. This was in the control of the
committee. The second was where vendor interpretations, extended use
of standardized syntax or common extensions were being replaced by
specific standards. This meant that at least some come would have to
be changed. Upward compatibility is very important in the mainframe
world (IBM, Unisys, Tandem now a part of HP, etc) and probably now in
enterprise Linux, Unix and Windows environments with thousands of
programs.
| |
| Howard Brazee 2005-05-24, 3:55 pm |
|
On 24-May-2005, Clark Morris <cfmtech@istar.ca> wrote:
> The classic case of change I have
> yet to understand is from EXAMINE to INSPECT
Don't forget TRANSFORM in there. I converted code twice to do the same thing.
| |
| William M. Klein 2005-05-24, 3:55 pm |
| I don't think that TRANSFORM was part of the '74 Standard, so dropping it from
the '85 Standard wouldn't have been an issue. For that matter, I am not certain
that EXAMINE was part of the '74 Standard.
NOTE:
IBM (see previous references to SHARE) *did* include both EXAMINE and
TRANSFORM in their '74 Standard compiler - but I think BOTH were extensions (and
were so marked).,
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:d6vq2g$re2$1@peabody.colorado.edu...
>
> On 24-May-2005, Clark Morris <cfmtech@istar.ca> wrote:
>
>
> Don't forget TRANSFORM in there. I converted code twice to do the same
> thing.
| |
| Chuck Stevens 2005-05-24, 3:55 pm |
| There is an important difference, though: while EXAMINE was standard
according to ANSI X3.23-1968, TRANSFORM was an IBM extension, at least
according to my copy of IBM DOS Full American National Standard COBOL (file
S360-24, order number GC28-639404).
=CVj
"Howard Brazee" <howard@brazee.net> wrote in message
news:d6vq2g$re2$1@peabody.colorado.edu...
>
> On 24-May-2005, Clark Morris <cfmtech@istar.ca> wrote:
>
>
> Don't forget TRANSFORM in there. I converted code twice to do the same
thing.
| |
| Chuck Stevens 2005-05-24, 3:55 pm |
|
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:z1Kke.258787$Sq.74631@fe05.news.easynews.com...
> I don't think that TRANSFORM was part of the '74 Standard, so dropping it
from
> the '85 Standard wouldn't have been an issue.
TRANSFORM wasn't part of the '68 standard either.
> For that matter, I am not certain
> that EXAMINE was part of the '74 Standard.
No, it definitely was not. Its functionality (actually, along with that of
TRANSFORM) was subsumed into INSPECT.
>
> NOTE:
> IBM (see previous references to SHARE) *did* include both EXAMINE and
> TRANSFORM in their '74 Standard compiler - but I think BOTH were
extensions (and
> were so marked).,
Yes, they'd have to be.
-Chuck Stevens
| |
| Howard Brazee 2005-05-24, 8:55 pm |
|
On 24-May-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> I don't think that TRANSFORM was part of the '74 Standard, so dropping it from
>
> the '85 Standard wouldn't have been an issue. For that matter, I am not
> certain
> that EXAMINE was part of the '74 Standard.
>
> NOTE:
> IBM (see previous references to SHARE) *did* include both EXAMINE and
> TRANSFORM in their '74 Standard compiler - but I think BOTH were extensions
> (and
> were so marked).,
I converted from EXAMINE to TRANSFORM on a Univac 9030. I think it was
converting from ANSI 68.
| |
| Chuck Stevens 2005-05-24, 8:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:d6vr71$se6$1@peabody.colorado.edu...
> I converted from EXAMINE to TRANSFORM on a Univac 9030. I think it was
> converting from ANSI 68.
That's a tough one. Are you sure you don't mean from EXAMINE to INSPECT?
It doesn't seem to me that the functions of ('68 standard) EXAMINE and (IBM
extension) TRANSFORM overlap very much!
-Chuck Stevens
| |
| Howard Brazee 2005-05-24, 8:55 pm |
|
On 24-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
> That's a tough one. Are you sure you don't mean from EXAMINE to INSPECT?
> It doesn't seem to me that the functions of ('68 standard) EXAMINE and (IBM
> extension) TRANSFORM overlap very much!
What happened is that I had programs compiled with each compiler, and some of
them wanted EXAMINE and some wanted INSPECT. I noticed that both compilers
supported TRANSFORM, and for a very common function that I needed done with the
on-line COBOL programs, TRANSFORM sufficed. To avoid having to worry about
which compiler a program used, I decided that this function should avoid
conversion problems and use TRANSFORM. It didn't work.
The Univac 9030 was the basic RCA design that was incorporated in the IBM 360,
so maybe TRANSFORM was an RCA extension that both systems inherited. I don't
know.
| |
| Clark Morris 2005-05-30, 3:55 am |
| On 18 May 2005 13:32:13 -0700, "Richard" <riplin@Azonic.co.nz> wrote:
>
>Google should be your friend. It found this in about 0.1 seconds.
>
>""" In the early o1980s, COBOL bashing took a turn for the worse.
>Serious efforts were underway to "kill" COBOL. In preparation for
>the publication of ISO/ANSI COBOL 85, there were serious legal and
>lobbying attempts (led by Travelers Insurance and joined by other
>respectable corporations) to block any new COBOL standardization
>effort. Some wanted to freeze the COBOL language as described in the
>ANSI COBOL 74 standard. Others wanted to roll back the COBOL standard
>to its "official" COBOL 68 version. The argument offered by these
>groups was that it involved a great corporate cost to update their
>enterprise applications in order for older COBOL programs to compile
>cleanly in newer COBOL compilers. No one told them that they didn't
>need to recompile any programs unless the business application required
>updating."""
The complaint was not that new things were being added but rather that
current syntax was being dropped. In addition the interpretation of
current syntax was being changed. The classic case of change I have
yet to understand is from EXAMINE to INSPECT. The ALTER verb was
being dropped. As I pointed out in the SHARE COBOL project at the
time, people should be barred from using it in new programs but I
would hate to not have been able to recompile the payroll and
marketing programs I wrote in the late 1960's and early 1970's just
because the compiler changed. (The payroll programs were later
replaced by a package and needed a major rewrite if they were to
survive. The marketing programs lasted far longer than they should
for various reasons. I hope they aren't still running.) The problem
was two fold. The first was where the COBOL committee was changing
existing standardized syntax by deletion (ALTER), replacement (EXAMINE
by INSPECT) or change in definition. This was in the control of the
committee. The second was where vendor interpretations, extended use
of standardized syntax or common extensions were being replaced by
specific standards. This meant that at least some come would have to
be changed. Upward compatibility is very important in the mainframe
world (IBM, Unisys, Tandem now a part of HP, etc) and probably now in
enterprise Linux, Unix and Windows environments with thousands of
programs.
| |
| Howard Brazee 2005-05-30, 3:55 am |
|
On 24-May-2005, Clark Morris <cfmtech@istar.ca> wrote:
> The classic case of change I have
> yet to understand is from EXAMINE to INSPECT
Don't forget TRANSFORM in there. I converted code twice to do the same thing.
| |
| Howard Brazee 2005-05-30, 3:55 am |
|
On 24-May-2005, "William M. Klein" <wmklein@nospam.netcom.com> wrote:
> I don't think that TRANSFORM was part of the '74 Standard, so dropping it from
>
> the '85 Standard wouldn't have been an issue. For that matter, I am not
> certain
> that EXAMINE was part of the '74 Standard.
>
> NOTE:
> IBM (see previous references to SHARE) *did* include both EXAMINE and
> TRANSFORM in their '74 Standard compiler - but I think BOTH were extensions
> (and
> were so marked).,
I converted from EXAMINE to TRANSFORM on a Univac 9030. I think it was
converting from ANSI 68.
|
|
|
|
|