Cobol - OO COBOL - What if ???

Author

OO COBOL - What if ???

William M. Klein

2007-10-05, 3:55 am

This is partially a response to the current "What is/was the problem with OO and
COBOL?" discussion and partially a follow-up to the recent "Did the mainframe
kill COBOL?" thread.

Hypothetical Situation:
In 1995 (or so - but WELL before Y2K) ANSI and ISO had passed an amendment
(similar to Intrinsic Functions) with a "well defined" OO specification -
amending the '85 Standard
and
there were a FIPS certification test (as there was for Intrinsic Functions - but
not the 2nd actual amendment)
and
the US government still required a certified COBOL compiler to be available for
HARDWARE (and O/S) sales to any US government body

Question:
Would OO COBOL have been available AND adopted by most COBOL user sites?

****

Follow-on question:
If there hadn't been 100-200 identical "public review" comments on the first
revision of the '74 Standard (what eventually became the '85 Standard) each of
them complaining about things being removed from the Standard (i.e. those things
that eventually become OBSOLETE) along with many public and private "threats" of
lawsuits if ANYTHING were dropped from the '74 Standard,
Would later revisions have come out more quickly? Would they have been
implemented and adopted?

(NOTE: Most of these comments came from IBM mainframe shops who never did
understand that IBM could keep the features - even if they weren't in the
Standard and almost NONE of them even knew how to run OS/VS COBOL or DOS/VS
COBOL compiles with ANSI-conformance checking turned on. Common complaint, for
example was the removal of EXHIBIT which wasn't even in the '74 Standard)

***

Next Question:
If the Intrinsic Function Amendment's first draft had either had decent error
handling or no error handling (rather than returned values that could have also
been good returned values)
and
if the Amendment process hadn't turned out to take 3-5 years for each amendment
and
If ANSI hadn't required that a 3rd amendment would mean that the entire Standard
would have to be republished
and
if the '85 Standard had actually existed in a machine maintainable format that
COULD have been republished

Question:
Would the amendment process actually be used to introduce "new and timely"
features into COBOL (besides the Intrinsic Functions Amendment which was slow
and had problems)

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

Howard Brazee

2007-10-05, 6:55 pm

On Fri, 05 Oct 2007 05:09:30 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>Hypothetical Situation:
> In 1995 (or so - but WELL before Y2K) ANSI and ISO had passed an amendment
>(similar to Intrinsic Functions) with a "well defined" OO specification -
>amending the '85 Standard
> and
>there were a FIPS certification test (as there was for Intrinsic Functions - but
>not the 2nd actual amendment)
> and
>the US government still required a certified COBOL compiler to be available for
>HARDWARE (and O/S) sales to any US government body
>
>Question:
> Would OO COBOL have been available AND adopted by most COBOL user sites?

My guess: Not a chance.

There are a couple of different trends that have happened with
languages - one of these is moving towards OO.

Another important trend is the moving towards library based languages.
IMHO, library based languages are harder to program, as commands
aren't as rigidly defined and controlled. But they are much easier
to write, modify, and evolve. They can be created by societies
instead of by management groups - and can be cheaply available to
everybody.

Make ANSI changes in CoBOL and wait for one company then another
slowly add those changes to its expensive compiler.

Make similar changes to C, and the libraries are quickly changed and
distributed.

And make changes to HTML, XML, Java, etc. and people are chomping at
the bits to play with the new powers they get.

Robert

2007-10-06, 3:55 am

On Fri, 05 Oct 2007 05:09:30 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>This is partially a response to the current "What is/was the problem with OO and
>COBOL?" discussion and partially a follow-up to the recent "Did the mainframe
>kill COBOL?" thread.
>
>Hypothetical Situation:
> In 1995 (or so - but WELL before Y2K) ANSI and ISO had passed an amendment
>(similar to Intrinsic Functions) with a "well defined" OO specification -
>amending the '85 Standard
> and
>there were a FIPS certification test (as there was for Intrinsic Functions - but
>not the 2nd actual amendment)
> and
>the US government still required a certified COBOL compiler to be available for
>HARDWARE (and O/S) sales to any US government body
>
>Question:
> Would OO COBOL have been available AND adopted by most COBOL user sites?

OO Cobol would have been adopted by most user (mainframe) sites in the mid '90s if it
could have been used, out of the box, to create Web pages. The missing features were class
libraries like those offered by Java -- GUI components similar to AWT, database via
ODBC/JDBC, XML, collection classes, a stack walker for debugging, remote deployment and
remote procedure calls and message passing similar to RMI/CORBA/EJB.

Mainframers were under pressure to create Web sites. If Cobol had been capable of doing
it, they would have learned and used OO Cobol rather than Java.

Government sponsorship didn't save Ada; IBM sponsorship didn't save PL/I. The Cobol
community didn't care about standards politics, it wanted a set of tools that could be
used NOW.

LX-i

2007-10-06, 6:55 pm

William M. Klein wrote:
> This is partially a response to the current "What is/was the problem with OO and
> COBOL?" discussion and partially a follow-up to the recent "Did the mainframe
> kill COBOL?" thread.
>
> Hypothetical Situation:
> In 1995 (or so - but WELL before Y2K) ANSI and ISO had passed an amendment
> (similar to Intrinsic Functions) with a "well defined" OO specification -
> amending the '85 Standard
> and
> there were a FIPS certification test (as there was for Intrinsic Functions - but
> not the 2nd actual amendment)
> and
> the US government still required a certified COBOL compiler to be available for
> hardware (and O/S) sales to any US government body
>
> Question:
> Would OO COBOL have been available AND adopted by most COBOL user sites?

That's difficult to answer. I've obviously read what some other folks
have said, and one of the complaints (other than the verbosity - but I
think that's a red herring) is the lack of libraries. If this had
happened the way you postulated above, would libraries have been
available (either intrinsically to COBOL, or an interface to Java or C++
libraries)?

For example, I know just recently (I believe) that the discussion on
"collections" was done. This is such a basic building block of most all
other OO implementations I've seen. Sure, you could implement it with
the facilities that exist already, but being able to extend that
collection building block make development time much quicker.

I think that, with the other political things you've described in your
other "what-ifs", it sounds like the customers got exactly what they
asked for. It seems to be a mindset shift. Look at the distrust that
Pete has encountered when he's posted about components - just yesterday,
someone said "we'll have to re-test everything!" :)

I've been in my current shop (Java) for about 6 months now, and I've
been amazed at how isolated I can make fixes. The code belongs to the
team, and the we can all work on whatever. I add a property to an
object, or a method to a service, there's no clamoring for a re-test on
everything.

I don't know that that's inherent in the language, or is part of the
design. I would tend to think it's more the latter. But, if we had
tried to do that at my last shop, we would have been laughed out the place.

So, to answer your "what-if", I'd say that it certainly would have
helped - but it still might not have been enough.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Robert

2007-10-06, 9:55 pm

On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:

>William M. Klein wrote:
>
>That's difficult to answer. I've obviously read what some other folks
>have said, and one of the complaints (other than the verbosity - but I
>think that's a red herring) is the lack of libraries. If this had
>happened the way you postulated above, would libraries have been
>available (either intrinsically to COBOL, or an interface to Java or C++
>libraries)?
>
>For example, I know just recently (I believe) that the discussion on
>"collections" was done. This is such a basic building block of most all
>other OO implementations I've seen. Sure, you could implement it with
>the facilities that exist already, but being able to extend that
>collection building block make development time much quicker.
>
>I think that, with the other political things you've described in your
>other "what-ifs", it sounds like the customers got exactly what they
>asked for. It seems to be a mindset shift. Look at the distrust that
>Pete has encountered when he's posted about components - just yesterday,
>someone said "we'll have to re-test everything!" :)
>
>I've been in my current shop (Java) for about 6 months now, and I've
>been amazed at how isolated I can make fixes. The code belongs to the
>team, and the we can all work on whatever. I add a property to an
>object, or a method to a service, there's no clamoring for a re-test on
>everything.
>
>I don't know that that's inherent in the language, or is part of the
>design. I would tend to think it's more the latter. But, if we had
>tried to do that at my last shop, we would have been laughed out the place.
>
>So, to answer your "what-if", I'd say that it certainly would have
>helped - but it still might not have been enough.

Development of the Cobol language was fettered by the culture of its users. The notion
that reusable code is bad because it requires re-testing every client program was a SHOW
STOPPER. It meant OO Cobol was doomed, would be rejected by its mainframe users.

As to Standard Libraries, consider that there *is no* Standard for Java. The formal spec
is controlled by the Java Community Process, a group of industry representatives
reminiscent of Cobol's origins in CODASYL. It handles a hundred changes, called JSRs, per
year. Anyone suggestsing 5 years or 17 years between versions would be laughed out of the
room. Putting Java into the Standards process, called ISO/IEC JTC1, would be the kiss of
death.

It is little known that CODASYL continued defining Cobol Enhancements AFTER it handed off
the Cobol language to ANSI in the mid '60s. They were trying to add database access to
Cobol. Their ideas didn't make it into the language Standard, instead were implemented as
calls to products such as IDMS. That chain of thought was replaced by relational databases
and SQL in the 1980s.

I mentioned that to say the Cobol language Standard should not be expected to describe the
entire computer environment. It should be open enough to interface with complimentary
technologies and languages. We FINALLY got that in the '02 Standard, which was too late.
If we had it in the '80s, when C++ was catching on, Cobol would have stood a chance.

LX-i

2007-10-06, 9:55 pm

Robert wrote:
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> Development of the Cobol language was fettered by the culture of its users. The notion
> that reusable code is bad because it requires re-testing every client program was a SHOW
> STOPPER. It meant OO Cobol was doomed, would be rejected by its mainframe users.

Right - that's what I meant when I said that the customers got exactly
what they asked for. I couldn't believe that people would sue over a
standard - especially when a vendor can pretty much do whatever they
want and label it an extension.

> As to Standard Libraries, consider that there *is no* Standard for Java. The formal spec
> is controlled by the Java Community Process, a group of industry representatives
> reminiscent of Cobol's origins in CODASYL. It handles a hundred changes, called JSRs, per
> year. Anyone suggestsing 5 years or 17 years between versions would be laughed out of the
> room. Putting Java into the Standards process, called ISO/IEC JTC1, would be the kiss of
> death.

It's interesting the way they handle deprecation. They put
"@deprecated" before the method declaration, then the compiler flags it.
However, I can't imagine a lawsuit over something in Java 5 that was
marked as deprecated being removed in Java 6. Then again, I never
understood how EXHIBIT was supposed to be better than DISPLAY - I guess
I was just late to the game. Yes, I removed them when I converted
programs from COBOL 74 to COBOL 85, but it was trivial, IMO.

> It is little known that CODASYL continued defining Cobol Enhancements AFTER it handed off
> the Cobol language to ANSI in the mid '60s. They were trying to add database access to
> Cobol. Their ideas didn't make it into the language Standard, instead were implemented as
> calls to products such as IDMS. That chain of thought was replaced by relational databases
> and SQL in the 1980s.

When I learned Unisys COBOL, I thought FETCH, MODIFY, et. al. *were*
part of COBOL. Only later did I learn that there was a preprocessor
(external for COBOL 74, integrated into the COBOL 85 compiler) that
converted all those statements to "CALL 'DBMS' USING ..." statements.
(This knowledge did help, though, when understanding why the DML "IF"
statement did not support "END-IF". I started using "PERFORM IF ...
ELSE ... END-PERFORM" to wrap it.)

> I mentioned that to say the Cobol language Standard should not be expected to describe the
> entire computer environment. It should be open enough to interface with complimentary
> technologies and languages. We FINALLY got that in the '02 Standard, which was too late.
> If we had it in the '80s, when C++ was catching on, Cobol would have stood a chance.

That's pretty close to what I was thinking. Also, the business model of
languages has pretty much been turned on its head. COBOL is expensive,
while you can download Java and Eclipse for free! C# and the Visual
Studio.NET express versions are free too, and the .NET runtime is an
integral part of Vista (which is where Windows is headed).

Like mothers have told their daughters for generations - why buy the cow
when you can get the milk for free?

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

Robert

2007-10-07, 6:55 pm

On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:

>Robert wrote:
[color=darkred]
>
>Right - that's what I meant when I said that the customers got exactly
>what they asked for.

The customers were not of a single mind. As happens so often in politics and consumer
goods, they all got what the dumb or vocal ones asked for.

> I never
>understood how EXHIBIT was supposed to be better than DISPLAY - I guess
>I was just late to the game. Yes, I removed them when I converted
>programs from COBOL 74 to COBOL 85, but it was trivial, IMO.

The advantage was in the NAMED option. EXHIBIT NAMED A B C displayed
A = xxx
B = yyy
C = zzz

Micro Focus still has EXHIBIT .. and also TRACE.

>
>That's pretty close to what I was thinking. Also, the business model of
>languages has pretty much been turned on its head. COBOL is expensive,
>while you can download Java and Eclipse for free! C# and the Visual
>Studio.NET express versions are free too, and the .NET runtime is an
>integral part of Vista (which is where Windows is headed).
>
>Like mothers have told their daughters for generations - why buy the cow
>when you can get the milk for free?

Mothers use that aphorism to caution daughters AGAINST giving it away without commitment.

Look what free did to television. It gave the world low quality, poor selection and a
biased point of view. Now people willingly pay for cable rather than watching what's free.

Jeff Campbell

2007-10-07, 6:55 pm

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
>
> The customers were not of a single mind. As happens so often in politics and consumer
> goods, they all got what the dumb or vocal ones asked for.
>
>
> The advantage was in the NAMED option. EXHIBIT NAMED A B C displayed
> A = xxx
> B = yyy
> C = zzz
>
> Micro Focus still has EXHIBIT .. and also TRACE.
>
>
> Mothers use that aphorism to caution daughters AGAINST giving it away without commitment.
>
> Look what free did to television. It gave the world low quality, poor selection and a
> biased point of view. Now people willingly pay for cable rather than watching what's free.

No, cable is quantity, not quality. 8-)

Jeff

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Clark F Morris

2007-10-07, 9:55 pm

On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:

>Robert wrote:
>
>Right - that's what I meant when I said that the customers got exactly
>what they asked for. I couldn't believe that people would sue over a
>standard - especially when a vendor can pretty much do whatever they
>want and label it an extension.

As someone who was involved in the fight, our understanding was that
the new standard mandated removal of function. Given the age of many
programs and the longer predicted life for them, a change in the
behavior of a compiler for existing code was not a welcome idea. As
an example, marketing programs I wrote in the late 1960's with ALTERs
were still running in the 1990's (not really meeting company needs but
no one could agree on what the replacement should be). Payroll
programs with ALTERs also were still alive but headed for extinction.
I believe that gratuitous changes like replacing EXAMINE with INSPECT
didn't help and that if ANSI had spent time on working out a way each
vendor could set up a migration path to new world. There were a lot
of discontinuities between the 1974 COBOL and the 1985 COBOL, most
worrisome of them being where constructs would give different
behaviors.
>
>
>It's interesting the way they handle deprecation. They put
>"@deprecated" before the method declaration, then the compiler flags it.
> However, I can't imagine a lawsuit over something in Java 5 that was
>marked as deprecated being removed in Java 6. Then again, I never
>understood how EXHIBIT was supposed to be better than DISPLAY - I guess
>I was just late to the game. Yes, I removed them when I converted
>programs from COBOL 74 to COBOL 85, but it was trivial, IMO.
>
>
>When I learned Unisys COBOL, I thought FETCH, MODIFY, et. al. *were*
>part of COBOL. Only later did I learn that there was a preprocessor
>(external for COBOL 74, integrated into the COBOL 85 compiler) that
>converted all those statements to "CALL 'DBMS' USING ..." statements.
>(This knowledge did help, though, when understanding why the DML "IF"
>statement did not support "END-IF". I started using "PERFORM IF ...
>ELSE ... END-PERFORM" to wrap it.)
>
>
>That's pretty close to what I was thinking. Also, the business model of
>languages has pretty much been turned on its head. COBOL is expensive,
>while you can download Java and Eclipse for free! C# and the Visual
>Studio.NET express versions are free too, and the .NET runtime is an
>integral part of Vista (which is where Windows is headed).
>
>Like mothers have told their daughters for generations - why buy the cow
>when you can get the milk for free?

LX-i

2007-10-07, 9:55 pm

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> The advantage was in the NAMED option. EXHIBIT NAMED A B C displayed
> A = xxx
> B = yyy
> C = zzz
>
> Micro Focus still has EXHIBIT .. and also TRACE.

DISPLAY "A = " A
DISPLAY "B = " B
DISPLAY "C = " C

I know, more verbose, but a guy in our shop wrote a SlickEdit macro that
did the conversion like that.

>
> Mothers use that aphorism to caution daughters AGAINST giving it away without commitment.

Yes, but the converse is that those who get the milk for free will
generally not see the need to buy the cow. :) As a programmer, I have
a wide array of programming language choices available to me at no cost.
Then there's COBOL..

> Look what free did to television. It gave the world low quality, poor selection and a
> biased point of view. Now people willingly pay for cable rather than watching what's free.

I don't know that quality is all of it. Our reception is crap, so cable
lets us see things much more clearly. We've had digital cable for the
first time, since we moved out here. I like the signal quality.
However, I still sometimes find myself with 300 channels of nothing to
watch. Thank goodness for Comcast OnDemand! :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

LX-i

2007-10-08, 3:55 am

Clark F Morris wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> As someone who was involved in the fight, our understanding was that
> the new standard mandated removal of function. Given the age of many
> programs and the longer predicted life for them, a change in the
> behavior of a compiler for existing code was not a welcome idea. As
> an example, marketing programs I wrote in the late 1960's with ALTERs
> were still running in the 1990's (not really meeting company needs but
> no one could agree on what the replacement should be). Payroll
> programs with ALTERs also were still alive but headed for extinction.
> I believe that gratuitous changes like replacing EXAMINE with INSPECT
> didn't help and that if ANSI had spent time on working out a way each
> vendor could set up a migration path to new world. There were a lot
> of discontinuities between the 1974 COBOL and the 1985 COBOL, most
> worrisome of them being where constructs would give different
> behaviors.

I promise I'm not trying to be obtuse or argumentative - I'm just trying
to understand the objections.

If these programs rely on these constructs, and there is no money or
time for modifications, why move them to COBOL 85? And, if they need to
be moved to COBOL 85, you're going to be working on the code anyway -
was it that painful to unwind and recode with a GO TO...DEPENDING ON or,
even less invasively, change the ALTER to set a flag in WS, then put an
EVALUATE at each switch point that checks the flag and directs program flow?

Regarding EXAMINE and INSPECT - if there are two keywords that do the
same thing, wouldn't removing one be the way to go, long-term? I know
it sucks if your favorite one is the one tagged for extinction, but
isn't simplification in a programming language a good thing?

And, regarding your last comment - which constructs gave different
behavior with the same syntax? I'll agree with you on that point -
that's not a good thing.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \/ _ o ~ Live from Albuquerque, NM! ~
~ _ /\ | ~ ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ Business E-mail ~ daniel @ "Business Website" below ~
~ Business Website ~ http://www.djs-consulting.com ~
~ Tech Blog ~ http://www.djs-consulting.com/linux/blog ~
~ Personal E-mail ~ "Personal Blog" as e-mail address ~
~ Personal Blog ~ http://daniel.summershome.org ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~

GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ !O M--
V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e h---- r+++ z++++

"Who is more irrational? A man who believes in a God he doesn't see,
or a man who's offended by a God he doesn't believe in?" - Brad Stine

William M. Klein

2007-10-08, 3:55 am

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:o1pig35pejmui3kni3r0nrosjekmo63q6h@
4ax.com...
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
<snip>
> As someone who was involved in the fight,<first draft of '85 Standard removing
> features that later got marked obsolete> our understanding was that
> the new standard mandated removal of function.

I never did figure out why the guy at Harford (or was it Aetna - smoe NH
Insurance company) was able to convince so many people that this was what was
"proposed" (in the first draft of what became the '85 Standard). It simply
REMOVED lots (well somewhere between 10 and 20 as I recall) items from the
Standard. There NEVER was any way that a Standard could PROHIBT a conforming
implementation from including "old" features in new compilers. (Well, I supose
if they created a new feature using an old reserved word, this might happen -
but even then vendors could and always have - provided "non-conforming" modes of
running).

Some how, it just never "sunk" in to shops (those who wrote all those letters)
that a vendor (aka IBM) that provided NOTRUNC and APOST compiler options and the
GOBACK verb would NOT have "removed" major upward compatibility. Of course,
given the problems that shops eventually DID have in moving from OS/VS COBOL to
VS COBOL II, the real problem turned out to be that IBM (and its customers)
didn't all of all the "undocumented extensions" that were in the older
compilers.

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

Arnold Trembley

2007-10-08, 3:55 am

LX-i wrote:
> (snip)
>
>
> Regarding EXAMINE and INSPECT - if there are two keywords that do the
> same thing, wouldn't removing one be the way to go, long-term? I know
> it sucks if your favorite one is the one tagged for extinction, but
> isn't simplification in a programming language a good thing?

Many years ago I wrote a program to convert OS/VS COBOL source to be
compatible with the IBM VS COBOL II compiler. One of the items that
caused some problems for me was converting EXAMINE to INSPECT. All my
program did was replace the EXAMINE reserved word with INSPECT. Due
to some differences in the syntax of the clauses about half of the
INSPECT statements generated compile diagnostics. Converting SERVICE
RELOAD and BLL cells was harder, but worked more reliably.

IBM's CCCA (or whatever it was called) and also their COBOL
restructuring facility were much more reliable. The only advantage to
my program was that it was about 80% effective and it was "free".

http://home.att.net/~arnold.trembley/prog.htm
http://home.att.net/~arnold.trembley/cb2align.zip

With kindest regards,

--
http://arnold.trembley.home.att.net/

Arnold Trembley

2007-10-08, 3:55 am

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>
> The advantage was in the NAMED option. EXHIBIT NAMED A B C displayed
> A = xxx
> B = yyy
> C = zzz
>
> Micro Focus still has EXHIBIT .. and also TRACE.

Back in the late 1980's I remember many IBM OS/VS COBOL programs that
used EXHIBIT NAMED to display summary totals at end-of-job.

It was convenient, and at the time I was not aware that it was an IBM
extension to COBOL specifically to support testing and debugging.

The problem with the DISPLAY verb in OS/VS COBOL was that it only
supported USAGE DISPLAY numbers. If your number was COMP-3
(Packed-Decimal) or Binary, the display was raw hex data. Completely
unusable.

At least with IBM VS COBOL II, the behavior of the DISPLAY verb was
enhanced to automatically convert any valid numeric to display format.

I still missed the ability to code EXHIBIT NAMED GROSS-PAY and get
GROSS-PAY = 00155.92, but at least I didn't have to worry about
writing additional code to convert packed decimal to display usage
before I could see the contents.

With kindest regards,

--
http://arnold.trembley.home.att.net/

Howard Brazee

2007-10-08, 6:55 pm

On Sat, 06 Oct 2007 01:05:31 -0500, Robert <no@e.mail> wrote:

>Mainframers were under pressure to create Web sites. If Cobol had been capable of doing
>it, they would have learned and used OO Cobol rather than Java.

I didn't see it.

When companies (I was familiar with) explored the concepts web sites,
they did not want to spend much money. They did not want them on
mainframes. Hire some kids to put them up on a cheap box and see how
it works.

Their previous experience of trying to control VisiCalc users by
programming it on mainframes didn't work, so they weren't interested
in integrating web services with the existing mainframe applications -
Especially if their data have been moved to databases.

Howard Brazee

2007-10-08, 6:55 pm

On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:

>I've been in my current shop (Java) for about 6 months now, and I've
>been amazed at how isolated I can make fixes. The code belongs to the
>team, and the we can all work on whatever. I add a property to an
>object, or a method to a service, there's no clamoring for a re-test on
>everything.

I'm not convinced that this change in attitude is the result of OO
being less likely to cause such failures than old mainframe. But OO
did mean that the old standards for testing would be too costly, so
they were re-evaluated.

It's odd though that my experience has been that the types of bugs we
find in our Web side are much less likely to be visually critical.
Usually those are bad updates - but the data are in databases designed
elsewhere. The critical errors we have had have seen tend to be
related to keeping an unsafe number in a buffer or error file, or some
sequencing errors with threads. These are more likely to be poor
system design than programming mistakes.

Howard Brazee

2007-10-08, 6:55 pm

On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:

>It's interesting the way they handle deprecation. They put
>"@deprecated" before the method declaration, then the compiler flags it.
> However, I can't imagine a lawsuit over something in Java 5 that was
>marked as deprecated being removed in Java 6. Then again, I never
>understood how EXHIBIT was supposed to be better than DISPLAY - I guess
>I was just late to the game. Yes, I removed them when I converted
>programs from COBOL 74 to COBOL 85, but it was trivial, IMO.

EXHIBIT NAMED CHANGED was useful for debugging.

It was the INSPECT/EXAMINE/TRANSFORM changes that bugged me.

Howard Brazee

2007-10-08, 6:55 pm

On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:

>When I learned Unisys COBOL, I thought FETCH, MODIFY, et. al. *were*
>part of COBOL. Only later did I learn that there was a preprocessor
>(external for COBOL 74, integrated into the COBOL 85 compiler) that
>converted all those statements to "CALL 'DBMS' USING ..." statements.
>(This knowledge did help, though, when understanding why the DML "IF"
>statement did not support "END-IF". I started using "PERFORM IF ...
>ELSE ... END-PERFORM" to wrap it.)

I stick END-IF commands after my IDMS commands:

OBTAIN CALC IAARCAA
ON DB-STATUS-OK
PERFORM 2000-FOUND-IAARCAA
END-IF.

This expands to:
* OBTAIN CALC IAARCAA
* ON DB-STATUS-OK
MOVE 11 TO DML-SEQUENCE
CALL 'IDMS' USING SUBSCHEMA-CTRL
IDBMSCOM (32)
SR1456
IDBMSCOM (43)
IF NOT DB-STATUS-OK PERFORM IDMS-STATUS;
ELSE
PERFORM 2000-FOUND-IAARCAA
END-IF.

Note that without an END-IF or a period, a programmer might get

about where the code that they don't see ends. When I can,
I include both for that reason. Generated code ads confusion that
can be solved similarly to adding "unneeded" parenthesis around
complex IF conditions.

Howard Brazee

2007-10-08, 6:55 pm

On Sun, 07 Oct 2007 11:54:02 -0500, Robert <no@e.mail> wrote:

>Look what free did to television. It gave the world low quality, poor selection and a
>biased point of view. Now people willingly pay for cable rather than watching what's free.

Cable gives biased points of view and freedom from federal decency
rules. I'm not sure that this is a significant improvement.

Howard Brazee

2007-10-08, 6:55 pm

On Sun, 07 Oct 2007 20:43:35 -0600, LX-i <lxi0007@netscape.net> wrote:

>DISPLAY "A = " A
>DISPLAY "B = " B
>DISPLAY "C = " C
>
>I know, more verbose, but a guy in our shop wrote a SlickEdit macro that
>did the conversion like that.

I automatically go a step further:
DISPLAY 'A1 A="' A '"'

I want to know which line displaying of "A=" is being run, and also, I
want to know if the size of A is as expected.

Howard Brazee

2007-10-08, 6:55 pm

On Mon, 08 Oct 2007 06:51:21 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:

>The problem with the DISPLAY verb in OS/VS COBOL was that it only
>supported USAGE DISPLAY numbers. If your number was COMP-3
>(Packed-Decimal) or Binary, the display was raw hex data. Completely
>unusable.

I have used compilers that did that worse - but sometimes had display
options to convert (Univac?)

I often include the following in my programs:
01 DISPLAY-FIELDS.
05 DISPLAY-NDX PIC 9(05).
05 DISPLAY-SORT PIC Z(05).
05 DISPLAY-AMT1 PIC --,---,---.99.
05 DISPLAY-AMT2 PIC --,---,---.99.
05 DISPLAY-AMT3 PIC --,---,---.99.
05 DISPLAY-AMT4 PIC --,---,---.99.
05 DISPLAY-NUM1 PIC --,---,--9.
05 DISPLAY-NUM2 PIC --,---,--9.
05 DISPLAY-NUM3 PIC --,---,--9.

I use this for displays. Index displays are a pain in debugging.

Howard Brazee

2007-10-08, 6:55 pm

On Sun, 07 Oct 2007 21:34:09 -0600, LX-i <lxi0007@netscape.net> wrote:

>Regarding EXAMINE and INSPECT - if there are two keywords that do the
>same thing, wouldn't removing one be the way to go, long-term? I know
>it sucks if your favorite one is the one tagged for extinction, but
>isn't simplification in a programming language a good thing?

When we changed (Univac 9030) compilers I saw that I would need to do
this conversion. I thought I would be smart and use a command that
was in both conversions for our greatest need - I changed the command
to TRANSFORM.

Which disappeared later.

Robert

2007-10-08, 6:55 pm

On Mon, 08 Oct 2007 09:09:30 -0600, Howard Brazee <howard@brazee.net> wrote:

>On Sun, 07 Oct 2007 11:54:02 -0500, Robert <no@e.mail> wrote:
>
>
>Cable gives biased points of view and freedom from federal decency
>rules. I'm not sure that this is a significant improvement.

Bias in US news reports is countered by news from other countries.

The real world isn't subject to federal decency rules, either.

Sponsored Links