OO COBOL - What if ???

  • Permalink
  • submit to reddit
  • Email
  • Follow


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 


0
Reply wmklein (2605) 10/5/2007 5:09:30 AM

See related articles to this posting


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.

0
Reply howard (6275) 10/5/2007 2:56:49 PM

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. 


0
Reply Robert 10/6/2007 6:05:31 AM

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
0
Reply lxi0007 (1830) 10/6/2007 8:46:38 PM

"LX-i" <lxi0007@netscape.net> wrote in message 
news:GbudnSpeY_qvaZranZ2dnUVZ_qelnZ2d@comcast.com...
> William M. Klein wrote:
<snip>
> 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.
>

Just in case I didn't post the "final" (for the moment) status on what happened 
with OO COBOL Collection Classes, I thought I would post it now.

The "end" results are:

1) The OO Collection Classes Technical Report (TR) passed its ISO ballot. 
Direction has been made to make some MINOR editorial (mostly) changes - but it 
should be published relatively soon.  The version that was balloted on can be 
viewed online at (down-loaded from);
  http://www.cobolstandard.info/j4/files/07-0048.pdf

2) At its most recent WG4 meeting, direction was taken to *NOT* include this 
facility in the draft Standard currently under devlopment.  Instead, it is 
intended to be "maintained" as a TR until (if ever) it is "widely implemented"

3) Many of those implementers who have current OO COBOL implementations
  - have their own (non-Standard/TR conforming) Class libraries
        and/or
  - have documented acces to C++, C#, and/or Java class libraries from COBOL

4)  I have not PERSONALLY heard of ny implementations "announced" (much less 
availabvle) that actually conform to the ISO TR.  My *perception* is that this 
is viewed as "too late" and that most OO COBOL users will use those libraries 
available from other OO languages.


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


0
Reply wmklein (2605) 10/6/2007 8:57:07 PM

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

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

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.
0
Reply Robert 10/7/2007 1:03:25 AM

Robert wrote:
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
>> 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. 

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
0
Reply lxi0007 (1830) 10/7/2007 1:22:06 AM

"Robert" <no@e.mail> wrote in message 
news:nu7gg354uulfv91l6e0fcd522r8plbobce@4ax.com...
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>>William M. Klein wrote:
<snip>
> 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.
>

To expand a little on this, ...

Up thru (including) the Intrinsic Functions Amendment to the '85 Standard, but 
their own rules, *ALL* development was done by CCC (CODASYL COBOL Committee - 
there were other CODASYL committees as well). X3J4 (I think the change to J4 was 
after the end of CCC - but I could be wrong on this) "adopted" development from 
the CODASYL Jeournal of Development.  For the 74 and '85 Standards, the MAJOR 
initial effort at X3J4 was to decide what portions of the "snap shot" JOD they 
would select to include in the "next" revision of the Standard.  This even 
applied to "fixes" related to interpreation requests (which were NEVER binding 
in the ANSI days).  What would happen would be that an interpreation request 
would come into X3J4, then would determine what they THOUGHT was the correct 
answer. Then if a "fix" were required, they would send this over to CCC 
(sometimes with a suggestions on how to fix it) and once CCC came up with the 
"fix" (change to the JOD, not the Standard) they would send it back to X3J4. 
Normally, X3J4 would accept the CCC fix, but sometimes these would go back and 
forth multiple times.  Only when X3J4 and CCC agreed would the interpretation 
response and "fix" get documented to go into the next (non-binding) CIB (COBOL 
Information Bulletin).

There are clasic examples of "odd" selections and differences between the JOD 
(at various stages) and the Standard:
  - NEXT SENTENCE with END-IF *was* allowed in the JOD
 - Several of the FD phrases (I think BLOCK CONTAINS and RECORD CONTAINS) were 
in the Select/Assign clause
 - At one time (early on, I think - not finally) "COMP-n" and COMPUTATIONAL-N 
(where "n" was a number) were in the JOD (as implementer defined)

   ***
It is also worth metnioning that it was about the time of the '85 Standard 
(originally planned for the EARLY 90's) that "coordination" between ANSI and ISO 
Standards became a "big deal".  I wasn't involved with the passage of the '85 
Standard itself, but I know that by the time of the Intrinsic Functions 
Amendment, we (X3J4/ANSI) could not do a "final" approval of the ANSI standard 
until the ISO vote finished (and all international comments were resolved).

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


0
Reply wmklein (2605) 10/7/2007 2:14:13 AM

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

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

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. 

>> 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?

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.
0
Reply Robert 10/7/2007 4:54:02 PM

"Robert" <no@e.mail> wrote in message 
news:6pahg3thm2uthlosrh69joht20033r1b9e@4ax.com...
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>
<snip>
>> 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.

I really liked using EXHIBIT with both NAMED and CHANGED.  It was a great help 
before interactive debuggers with "monitors" and "breakpoint upon value change" 
features.


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


0
Reply wmklein (2605) 10/7/2007 5:41:42 PM

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
>> 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.  
> 
> 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. 
> 
>>> 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?
> 
> 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 =----
0
Reply n8wxs (185) 10/7/2007 8:29:08 PM

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

>> much snipped
>
>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.

Has this affected reliability?  I know that operating system changes
and upgrades are at least partially tested in many IBM z series shops
to see if they have any effect on applications.  We were more casual
in the last shop I was a systems programmer (late 1980s, early 1990s)
because we didn't have a test system (separate computer or LPAR on
main computer).  If a component is changed or extended by whatever
method, what insures that existing invokers see no change?  If the
invokers are supposed to see a change what guarantees something
doesn't break?
>
>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.
0
Reply cfmpublic (387) 10/7/2007 10:56:31 PM

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

>Robert wrote:
>> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>> 
>>> 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. 
>
>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.  
>
>> 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?
0
Reply cfmpublic (387) 10/8/2007 12:40:01 AM


"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message 
news:ckoig31328bt681434l2c44o2qjhsrh5ps@4ax.com...
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>
<snipped>
> Has this affected reliability?  I know that operating system changes
> and upgrades are at least partially tested in many IBM z series shops
> to see if they have any effect on applications.  We were more casual
> in the last shop I was a systems programmer (late 1980s, early 1990s)
> because we didn't have a test system (separate computer or LPAR on
> main computer).  If a component is changed or extended by whatever
> method, what insures that existing invokers see no change?

Encapsulation. It is a foreign concept for people who don't use OO.

> If the
> invokers are supposed to see a change what guarantees something
> doesn't break?

Encapsulation.

Objects are encapsulated. Adding methods to a Class CANNOT affect the 
existing methods. Only apps that use the new methods can be affected.

Problems can arise when people who are new to OO development actually change 
class methods, but no serious OO programmer would do that, and it would be 
forbidden and trapped by shop standards for production code. There are 
facilities to extend a method via an interface and change THAT instead of 
the original method, if you REALLY need to modify the behaviour of an 
existing Method. (Daniel described this in his post.) In this way, ONLY the 
apps you change to invoke the "new" interface get that change and everything 
else processes just as it always has.

It is a hard concept for non-OO people to understand and that's why I more 
or less gave up trying to explain it here some time ago. Component based 
systems do NOT need maintenance in the same way that procedural COBOL code 
does, and there is no need for regression testing.

(Some sites are starting to realise that this alone is a good reasonm to 
move to OO... Unfortunately, in order to do this now, their option is Java; 
10 years ago it COULD have been COBOL.)

("unfortunately" above does not imply a criticism of Java, which is an 
excellent OO language; rather, it was "unfortunate" for COBOL...)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 10/8/2007 2:36:20 AM

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
>> 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. 

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.

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

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
0
Reply lxi0007 (1830) 10/8/2007 2:43:35 AM

Clark F Morris wrote:
> On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
>>> much snipped
>> 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.
> 
> Has this affected reliability?

Not negatively.  :)

> I know that operating system changes
> and upgrades are at least partially tested in many IBM z series shops
> to see if they have any effect on applications.  We were more casual
> in the last shop I was a systems programmer (late 1980s, early 1990s)
> because we didn't have a test system (separate computer or LPAR on
> main computer).

Each developer has an instance of Tomcat on their local machine - we'll 
do builds there and test, against a common development database.  Each 
day, we do a build on the central development machine (also pointed to 
the development database), and move that build to a test machine 
(pointed at a test database).  Part of Agile development is lots of 
communication among the team members - so, if a database change is 
needed, this is communicated during the day, and the change scripts are 
run on the test database as well.

It's a pretty good system - I've been impressed.

> If a component is changed or extended by whatever
> method, what insures that existing invokers see no change?  If the
> invokers are supposed to see a change what guarantees something
> doesn't break?

Most of our objects have two constructors - one that takes no 
parameters, and one that takes a "ReturnObject" (a row from the 
database).  The queries are stored separately by name.  So, we'll have a 
block of code in a service that says something like...

ReturnObject[] oReturn = getDbLayer().performSelect("module.query_name", 
new Object[] { param1, param2 });

OurObject oOurs;

if (ArrayUtils.nullOrEmpty(oReturn)) {
     oOurs = new OurObject();
} else {
     oOurs = new OurObject(oReturn[0]);
}

So, if we add/remove a property to/from an object/field to the query, 
it's picked up automatically.  (Adds are fine - referenced deletions are 
caught by the compiler.)  The ReturnObject has methods to get various 
types from the database columns that gracefully handle nulls and fields 
that don't exists.  (For example, if the query didn't return a field 
called "ooga_booga", and you had code that said something like

String oStr = oReturn[0].getString("ooga_booga");

, oStr would be null - it would not throw an exception.)  Of course, 
adding methods doesn't break existing ones, and removing methods will 
again be caught by the compiler.

Then you take into account unit tests - automated tests that verify each 
object.  We have a SQL script that loads data into the database, then 
there is Java code that instantiates objects using that code and checks 
to see that everything is set as it should.  We can also test the output 
of methods that way.  Currently, we run them on our own machine, but by 
the end of this month, we'll have a process set up where it will 
automatically get the latest code from Subversion, build it, then run 
the tests and give us a report of the failures.  It's called "continuous 
integration", and it can catch problems introduced by object and method 
changes.  It doesn't catch the overall system business rules, but it 
ensures we have quality building blocks to start with.

So, I guess the unit tests *may* count as "regression testing."  Of 
course, they're only as good as the imagination of the person writing 
them - but that's the general rule with any kind of testing.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ 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
0
Reply lxi0007 (1830) 10/8/2007 3:24:57 AM

Clark F Morris wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> 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.  

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
0
Reply lxi0007 (1830) 10/8/2007 3:34:09 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 


0
Reply wmklein (2605) 10/8/2007 3:48:10 AM

"LX-i" <lxi0007@netscape.net> wrote in message 
news:GIqdnW9gzIumOJTanZ2dnUVZ_oKhnZ2d@comcast.com...
> Clark F Morris wrote:
>> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
<snip>
> 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.
>

Each Standard (or at least all the ones that I know about - I have never 
"studied" the '68 and only glanced at an "offical" '74) includes a  section 
called

   "Substantive Changes potentially affecting existing programs"

These DO include cases where "old syntax" can give "new results".  Usually these 
are due to interpretation requests (usually places where the old standard didn't 
say what people wanted/expected).

One example, in the '02 Standard was what a program needed to do if a divide by 
zero occured in an arithmetic statement and no "ON SIZE ERROR" phrase was 
specified.  By "mistake" (according to many) the '85 Standard was interpreted as 
REQUIRING a conforming implementation to "silently continue" on after such 
statements.  Many implementations had "always" ABENDed or "abnormally 
terminated" at such times. The '02 Standard changed the wording to ALLOW this to 
happen in a conforming implementation - but this was a change from the previous 
Standard.

The classic example between the '68 and '74 Standard was how to interprete 
certain combined abrreviated expressions with NOT in them, e.g.
   A = B AND NOT LESS THAN C OR D

in the '68 Standard was equivalent to
  ((A = B) AND NOT (A < C) OR (A < D))

in the '74 (and later) standards it is equivalent to
   ((A = B) AND (A NOT < C) OR (A NOT < D))

I won't go into the history of how/why this happened, but this is the type of 
thing that DOES happen between Standards - and that is "so documented".



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


0
Reply wmklein (2605) 10/8/2007 3:56:14 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/
0
Reply arnold.trembley (268) 10/8/2007 6:44:15 AM

Robert wrote:
> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
> 
>> Robert wrote: (SNIP)
>> 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. 

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/
0
Reply arnold.trembley (268) 10/8/2007 6:51:21 AM

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.
0
Reply howard (6275) 10/8/2007 2:46:32 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.
0
Reply howard (6275) 10/8/2007 2:58: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.
0
Reply howard (6275) 10/8/2007 3:01:23 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
confused 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.
0
Reply howard (6275) 10/8/2007 3:07:39 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.
0
Reply howard (6275) 10/8/2007 3:09:30 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.
0
Reply howard (6275) 10/8/2007 3:11:58 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.

0
Reply howard (6275) 10/8/2007 3:15:04 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.
0
Reply howard (6275) 10/8/2007 3:17:08 PM

William M. Klein wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message 
> news:GIqdnW9gzIumOJTanZ2dnUVZ_oKhnZ2d@comcast.com...
>> Clark F Morris wrote:
>>> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
> <snip>
>> 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.
>>
> 
> Each Standard (or at least all the ones that I know about - I have never 
> "studied" the '68 and only glanced at an "offical" '74) includes a  section 
> called
> 
>    "Substantive Changes potentially affecting existing programs"
> 
> These DO include cases where "old syntax" can give "new results".  Usually these 
> are due to interpretation requests (usually places where the old standard didn't 
> say what people wanted/expected).

That makes sense...

> One example, in the '02 Standard was what a program needed to do if a divide by 
> zero occured in an arithmetic statement and no "ON SIZE ERROR" phrase was 
> specified.  By "mistake" (according to many) the '85 Standard was interpreted as 
> REQUIRING a conforming implementation to "silently continue" on after such 
> statements.  Many implementations had "always" ABENDed or "abnormally 
> terminated" at such times. The '02 Standard changed the wording to ALLOW this to 
> happen in a conforming implementation - but this was a change from the previous 
> Standard.

That too makes sense.  The people that wrote it know what they meant, 
but if they don't express it clearly enough, others don't get that 
insight.  Of course, there's also the desire of some folks to see 
something in particular, especially when their compiler already works 
that way.  :)

> The classic example between the '68 and '74 Standard was how to interprete 
> certain combined abrreviated expressions with NOT in them, e.g.
>    A = B AND NOT LESS THAN C OR D
> 
> in the '68 Standard was equivalent to
>   ((A = B) AND NOT (A < C) OR (A < D))
> 
> in the '74 (and later) standards it is equivalent to
>    ((A = B) AND (A NOT < C) OR (A NOT < D))
> 
> I won't go into the history of how/why this happened, but this is the type of 
> thing that DOES happen between Standards - and that is "so documented".

Yikes!  That's a horrendous construct to begin with...  But, I also 
realize that I came to COBOL *way* late in the game, so I have the 
perspective of learning from what others have done.  I first saw COBOL 
in February of 1998.  :)

Are you familiar with the rationale regarding combining EXAMINE, 
INSPECT, and TRANSFORM?  I had forgotten about transform - and the 
syntax seemed a bit more intuitive to me.  Of course, they trained us on 
COBOL 85, but then put us in a COBOL 74 shop - so, we didn't learn a 
whole lot about the features that had been removed in the 85 standard. 
Was it just an attempt to reduce the number of reserved words?  Why not 
keep EXAMINE and TRANSFORM and ditch INSPECT?  :)

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~     / \/ _ 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
0
Reply lxi0007 (1830) 10/8/2007 3:56:33 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:
>
>>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.

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

The real world isn't subject to federal decency rules, either.
0
Reply Robert 10/8/2007 5:16:44 PM

I don't know exactly why EXAMINE was removed and INSPECT was added.  As far as I 
can tell TRANSFORM was never part of any ANSI Standard.  In fact, the '74 
Standard did not have the functionality of TRANSFORM in its version of INSPECT. 
That came "back" with the '85 Standard when INSPECT CONVERTING (rather than 
REPLACING) was added.

If I had a copy of the '74 Standard, I probably could "look up" in its 
Substantive Change section what the rationale was.  However, they have scanned 
the '68 Standard, but not the '74 -- so I don't have a copy.  (EXAMINE was in 
it).

There is one VAGUE possibility (and I haven't researched this).  It seems to me 
that I heard at one time (maybe the '60 definition - maybe later) there was an 
attempt to have the first 2 characters of all COBOL verbs be unique.  EXAMINE 
and EXIT would have "violated" that.  However, I think that INITIATE (and RW) 
was in by '74, that doesn't sound like the reason. Furthermore, I thought that 
DISPLAY and DIVIDE were "always" in, so I am not certain that this was really 
ever true.

Bottom-Line:
   I don't know why they made the change.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"LX-i" <lxi0007@netscape.net> wrote in message 
news:ZsydnXb3zJqgzpfanZ2dnUVZ_tCrnZ2d@comcast.com...
> William M. Klein wrote:
>> "LX-i" <lxi0007@netscape.net> wrote in message 
>> news:GIqdnW9gzIumOJTanZ2dnUVZ_oKhnZ2d@comcast.com...
>>> Clark F Morris wrote:
>>>> On Sat, 06 Oct 2007 19:22:06 -0600, LX-i <lxi0007@netscape.net> wrote:
>> <snip>
>>> 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.
>>>
>>
>> Each Standard (or at least all the ones that I know about - I have never 
>> "studied" the '68 and only glanced at an "offical" '74) includes a  section 
>> called
>>
>>    "Substantive Changes potentially affecting existing programs"
>>
>> These DO include cases where "old syntax" can give "new results".  Usually 
>> these are due to interpretation requests (usually places where the old 
>> standard didn't say what people wanted/expected).
>
> That makes sense...
>
>> One example, in the '02 Standard was what a program needed to do if a divide 
>> by zero occured in an arithmetic statement and no "ON SIZE ERROR" phrase was 
>> specified.  By "mistake" (according to many) the '85 Standard was interpreted 
>> as REQUIRING a conforming implementation to "silently continue" on after such 
>> statements.  Many implementations had "always" ABENDed or "abnormally 
>> terminated" at such times. The '02 Standard changed the wording to ALLOW this 
>> to happen in a conforming implementation - but this was a change from the 
>> previous Standard.
>
> That too makes sense.  The people that wrote it know what they meant, but if 
> they don't express it clearly enough, others don't get that insight.  Of 
> course, there's also the desire of some folks to see something in particular, 
> especially when their compiler already works that way.  :)
>
>> The classic example between the '68 and '74 Standard was how to interprete 
>> certain combined abrreviated expressions with NOT in them, e.g.
>>    A = B AND NOT LESS THAN C OR D
>>
>> in the '68 Standard was equivalent to
>>   ((A = B) AND NOT (A < C) OR (A < D))
>>
>> in the '74 (and later) standards it is equivalent to
>>    ((A = B) AND (A NOT < C) OR (A NOT < D))
>>
>> I won't go into the history of how/why this happened, but this is the type of 
>> thing that DOES happen between Standards - and that is "so documented".
>
> Yikes!  That's a horrendous construct to begin with...  But, I also realize 
> that I came to COBOL *way* late in the game, so I have the perspective of 
> learning from what others have done.  I first saw COBOL in February of 1998. 
> :)
>
> Are you familiar with the rationale regarding combining EXAMINE, INSPECT, and 
> TRANSFORM?  I had forgotten about transform - and the syntax seemed a bit more 
> intuitive to me.  Of course, they trained us on COBOL 85, but then put us in a 
> COBOL 74 shop - so, we didn't learn a whole lot about the features that had 
> been removed in the 85 standard. Was it just an attempt to reduce the number 
> of reserved words?  Why not keep EXAMINE and TRANSFORM and ditch INSPECT?  :)
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~     / \/ _ 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 


0
Reply wmklein (2605) 10/8/2007 5:38:43 PM

On Mon, 08 Oct 2007 09:56:33 -0600, LX-i <lxi0007@netscape.net> wrote:

>Are you familiar with the rationale regarding combining EXAMINE, 
>INSPECT, and TRANSFORM?  I had forgotten about transform - and the 
>syntax seemed a bit more intuitive to me.  Of course, they trained us on 
>COBOL 85, but then put us in a COBOL 74 shop - so, we didn't learn a 
>whole lot about the features that had been removed in the 85 standard. 
>Was it just an attempt to reduce the number of reserved words?  Why not 
>keep EXAMINE and TRANSFORM and ditch INSPECT?  :)

Micro Focus retained the old forms. Why didn't IBM?
0
Reply Robert 10/9/2007 12:44:13 AM

On Mon, 08 Oct 2007 17:38:43 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>If I had a copy of the '74 Standard, I probably could "look up" in its 
>Substantive Change section what the rationale was.  However, they have scanned 
>the '68 Standard, but not the '74 -- so I don't have a copy.  (EXAMINE was in 
>it).

DEC's TOPS-10 Cobol 74 manual is at this link. It's not the Standard, but is better than
nothing.

http://www.bitsavers.org/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol10/AA-5059B-TK_cobol74.pdf
0
Reply Robert 10/9/2007 2:06:52 AM

When IBM went from OS/VS COBOL to VS COBOL II, they dropped MANY of their 
earlier extensions (e.g. TRANSFORM and ON statement) as well as '68 Standard 
features (e.g. NOTE statement and EXAMINE).  Micro Focus maintained (and 
maintains) compatibility with OS/S COBOL as one of its dialects. Therefore, if 
you turn on OSVS reserved words, EXAMINE will work - even if you aren't trying 
to use Micro Focus extensions.

IBM also had (and has) automated tools for converting older (no longer 
supported) syntax to newer syntax.  If you can do an automated conversion and 
use "new/ current Standard" syntax, I can't see any reason NOT to drop the older 
forms.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message 
news:huilg312u5a2hcvr2345ko48sjmeccp38m@4ax.com...
> On Mon, 08 Oct 2007 09:56:33 -0600, LX-i <lxi0007@netscape.net> wrote:
>
>>Are you familiar with the rationale regarding combining EXAMINE,
>>INSPECT, and TRANSFORM?  I had forgotten about transform - and the
>>syntax seemed a bit more intuitive to me.  Of course, they trained us on
>>COBOL 85, but then put us in a COBOL 74 shop - so, we didn't learn a
>>whole lot about the features that had been removed in the 85 standard.
>>Was it just an attempt to reduce the number of reserved words?  Why not
>>keep EXAMINE and TRANSFORM and ditch INSPECT?  :)
>
> Micro Focus retained the old forms. Why didn't IBM? 


0
Reply wmklein (2605) 10/9/2007 4:26:57 AM

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag 
news:DWtOi.74132$zh6.71755@fe10.news.easynews.com...
>I don't know exactly why EXAMINE was removed and INSPECT was added.  As far 
>as I can tell TRANSFORM was never part of any ANSI Standard.  In fact, the 
>'74 Standard did not have the functionality of TRANSFORM in its version of 
>INSPECT. That came "back" with the '85 Standard when INSPECT CONVERTING 
>(rather than REPLACING) was added.
>
> If I had a copy of the '74 Standard, I probably could "look up" in its 
> Substantive Change section what the rationale was.  However, they have 
> scanned the '68 Standard, but not the '74 -- so I don't have a copy. 
> (EXAMINE was in it).

ANSI X3.23-1974, page XIV-9...:
'2. APPENDIX B: THE REVISION OF AMERICAN NATIONAL STANDARD COBOL ...
2.3 DIFFERENCES BETWEEN X3.23-1968 AND THE REVISED STANDARD ...
2.3.2 Overview of the Revised Modules
As in X3.23-1968, the Nucleus is divided into two levels. The major changes 
introduced into the Nucleus are...
(2) The EXAMINE statement has been deleted in favor of the more general and 
powerful INSPECT statement. The INSPECT statement provides the ability to 
count (Format 1), replace (Format 2) or count and replace (Format 3) 
occurrences of  single characters or groups of characters in a data item.'

Not much of a reason given there

K. Kiesel
Fujitsu Siemens Computers, M�nchen 


0
Reply Karl.Kiesel (43) 10/9/2007 7:26:37 AM

On Tue, 09 Oct 2007 04:26:57 GMT, "William M. Klein" <wmklein@nospam.netcom.com> wrote:

>When IBM went from OS/VS COBOL to VS COBOL II, they dropped MANY of their 
>earlier extensions (e.g. TRANSFORM and ON statement) as well as '68 Standard 
>features (e.g. NOTE statement and EXAMINE).  Micro Focus maintained (and 
>maintains) compatibility with OS/S COBOL as one of its dialects. Therefore, if 
>you turn on OSVS reserved words, EXAMINE will work - even if you aren't trying 
>to use Micro Focus extensions.

I tried them. EXAMINE worked with default options (none in cobopt). TRANSFORM required
OSVS. 
0
Reply Robert 10/10/2007 12:13:48 AM

Try running your EXAMINE test with SETTINGS(COL3) specified and see whether OSVS 
is turned on.  According to the MF LRM (NetExpress 5),
  A) EXAMINE is *not* indicated as an MF reserved word (any level of MF(n))
  B) EXAMINE statement has an OSVS bubble - but no other dialect specified.

If you don't want to look at the settings in detail, try compiling with:

  NOOSVS NOVSC2 MF FLAG(MF) FLAGAS(S) WARNING(3)

I haven't tried this on my machine (with my version of N/E) but given that 
EXAMINE is *not* listed as an MF reserved word, your results surprise me.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Robert" <no@e.mail> wrote in message 
news:r36og3h06p9vq1dvkaei71o04c9sal28g5@4ax.com...
> On Tue, 09 Oct 2007 04:26:57 GMT, "William M. Klein" 
> <wmklein@nospam.netcom.com> wrote:
>
>>When IBM went from OS/VS COBOL to VS COBOL II, they dropped MANY of their
>>earlier extensions (e.g. TRANSFORM and ON statement) as well as '68 Standard
>>features (e.g. NOTE statement and EXAMINE).  Micro Focus maintained (and
>>maintains) compatibility with OS/S COBOL as one of its dialects. Therefore, if
>>you turn on OSVS reserved words, EXAMINE will work - even if you aren't trying
>>to use Micro Focus extensions.
>
> I tried them. EXAMINE worked with default options (none in cobopt). TRANSFORM 
> required
> OSVS. 


0
Reply wmklein (2605) 10/10/2007 2:23:49 AM

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5mtjd5Ff4j98U1@mid.individual.net...
>
>
> "Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
> news:ckoig31328bt681434l2c44o2qjhsrh5ps@4ax.com...
> > On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
> >
> <snipped>
> > Has this affected reliability?  I know that operating system changes
> > and upgrades are at least partially tested in many IBM z series shops
> > to see if they have any effect on applications.  We were more casual
> > in the last shop I was a systems programmer (late 1980s, early 1990s)
> > because we didn't have a test system (separate computer or LPAR on
> > main computer).  If a component is changed or extended by whatever
> > method, what insures that existing invokers see no change?
>
> Encapsulation. It is a foreign concept for people who don't use OO.

A blatant generalization! Encapsulation is a concept
associated with modular programming and modular
programming does not require OO.

For example, when I was doing embedded progamming,
I wrote a module, in C, to process memory requests to
access flash memory. A module was required because
the flash device had an addressing range greater than the
micro-computer and writes to the device required a
code sequence to "unlock" the device. A few years later,
a different device was substituted. I added code to
detect the type of device installed so the correct code
sequence would be used. Becuase the functionality was
encapsulated, the change was transparent to the rest
of the system and the updated program could be used
with either memory device. And, I had not used OO
before writing the original module.

> > If the
> > invokers are supposed to see a change what guarantees something
> > doesn't break?
>
> Encapsulation.
>
> Objects are encapsulated.

And in the same sense that data in modules and not
defined by OO classes is encapsulated.

> It is a hard concept for non-OO people to understand and that's why I more
> or less gave up trying to explain it here some time ago. Component based
> systems do NOT need maintenance in the same way that procedural COBOL code
> does, and there is no need for regression testing.

What of components written in procedural COBOL?

To be clear, I have written components in procedural
COBOL; but, to me, they were just modules. Once
again, this was before I had used OO, and, if I recall
correctly, before I knew what OO was!



0
Reply ricksmith (875) 10/11/2007 5:14:22 PM


"Rick Smith" <ricksmith@mfi.net> wrote in message 
news:13gsmjsr5p3572@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5mtjd5Ff4j98U1@mid.individual.net...
>>
>>
>> "Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
>> news:ckoig31328bt681434l2c44o2qjhsrh5ps@4ax.com...
>> > On Sat, 06 Oct 2007 14:46:38 -0600, LX-i <lxi0007@netscape.net> wrote:
>> >
>> <snipped>
>> > Has this affected reliability?  I know that operating system changes
>> > and upgrades are at least partially tested in many IBM z series shops
>> > to see if they have any effect on applications.  We were more casual
>> > in the last shop I was a systems programmer (late 1980s, early 1990s)
>> > because we didn't have a test system (separate computer or LPAR on
>> > main computer).  If a component is changed or extended by whatever
>> > method, what insures that existing invokers see no change?
>>
>> Encapsulation. It is a foreign concept for people who don't use OO.
>
> A blatant generalization! Encapsulation is a concept
> associated with modular programming and modular
> programming does not require OO.
>
> For example, when I was doing embedded progamming,
> I wrote a module, in C, to process memory requests to
> access flash memory. A module was required because
> the flash device had an addressing range greater than the
> micro-computer and writes to the device required a
> code sequence to "unlock" the device. A few years later,
> a different device was substituted. I added code to
> detect the type of device installed so the correct code
> sequence would be used. Becuase the functionality was
> encapsulated, the change was transparent to the rest
> of the system and the updated program could be used
> with either memory device. And, I had not used OO
> before writing the original module.
>
>> > If the
>> > invokers are supposed to see a change what guarantees something
>> > doesn't break?
>>
>> Encapsulation.
>>
>> Objects are encapsulated.
>
> And in the same sense that data in modules and not
> defined by OO classes is encapsulated.

Only partly. That's where we differ.
>
>> It is a hard concept for non-OO people to understand and that's why I 
>> more
>> or less gave up trying to explain it here some time ago. Component based
>> systems do NOT need maintenance in the same way that procedural COBOL 
>> code
>> does, and there is no need for regression testing.
>
> What of components written in procedural COBOL?

Depends how you define "Component".

I have wriiten many components in OO COBOL. I could not achieve the same 
functionality if they were written in procedural COBOL. (I couldn't 
implement the COM wrapping in procedural COBOL for a start. It is inherited 
from a Base Class)

A component is not just a module. A component is totally encapsulated and 
can only be used through its interface. Even the individual internal methods 
are encapsulated. Properties are accessed through GET and SET methods, 
explicitly or implicity. A component can be dropped into a web page, or 
embedded in a desktop application, with no change. It can be instantiated 
locally and remotely, and created and destroyed on demand; modules can't be. 
They have to be wrapped properly to enable it and that wrapping is most 
easily implemented through OO. Java Beans are true components, Programs 
implementing the COM interface are true components (The "O" stands for 
"OBJECT", however :-)), C# Assemblys are (usually) true components (the 
exception would be desktop apps where the interface is a command line... why 
is the command line a show stopper? Because you need to shell to use it... 
it is NOT an instantiable interface), but procedural modules are not. It is 
all about how you can interface and build them together. True components can 
be built into systems with other components that are not even written in the 
same language. That is true "Encapsulation".
>
> To be clear, I have written components in procedural
> COBOL; but, to me, they were just modules. Once
> again, this was before I had used OO, and, if I recall
> correctly, before I knew what OO was!
>

I had a feeling you would make this post, Rick :-)

I know what you are saying, but "Encapsulation" as represented by an OO 
Component (Like a COM Class) is NOT the same as "Encapsulation" as 
represented by modular programming.

However, I see no point in arguing it. If you are happy with modular 
"components", fine.

I need components that can run anywhere on anything, that can interface 
easily to similar components (not necessarily written in the same language) 
via a common interface; that's why I use OO for them.

I would not be able to leverage all of my existing COBOL if it were not OO, 
without major refactoring and rewriting. "Modules" simply wouldn't cut it 
(although it would certainly be easier to refactor than monolithic 
procedural COBOL).

For me, that is the decider. I have never regretted moving to OO, either in 
COBOL or in C#. In fact, I'm very relieved that I did :-).

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 10/12/2007 12:35:34 AM

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5n7tqmFgjcluU1@mid.individual.net...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13gsmjsr5p3572@corp.supernews.com...
> >
> > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> > news:5mtjd5Ff4j98U1@mid.individual.net...
[snip]
> >> It is a hard concept for non-OO people to understand and that's why I
> >> more
> >> or less gave up trying to explain it here some time ago. Component
based
> >> systems do NOT need maintenance in the same way that procedural COBOL
> >> code
> >> does, and there is no need for regression testing.
> >
> > What of components written in procedural COBOL?
>
> Depends how you define "Component".

As the respondee ("you", taken literally), I choose the
following definition.
-----
component

2. An individual modular software routine that
has been compiled, dynamically linked, and is
ready to use with other components or programs.
-----
Within the context of component software.
-----
component software

Modular software routines, or components, that can
be combined with other components to form an overall
program. A programmer can use and reuse an existing
component and not have to understand its inner
workings, just how to have another program or
component call it and pass data to and from it.
---
Microsoft� Bookshelf� Computer and Internet
Dictionary� 1997 Microsoft Corporation. All rights
reserved. Portions, Microsoft Press� Computer
Dictionary, Third Edition. Copyright � 1997 by
Microsoft Press. All rights reserved.
-----

Thus, it would seem that many "dynamically linked"
COBOL programs would qualify as components.

> I have wriiten many components in OO COBOL. I could not achieve the same
> functionality if they were written in procedural COBOL. (I couldn't
> implement the COM wrapping in procedural COBOL for a start. It is
inherited
> from a Base Class)

COM (Component Object Model) is only one possible
component model.

I find it curious that you seem to suggest that COM
requires OO, since COM is object-based.
-----
Object-Based Components: COM

Our definition of OLE describes services as being
"object-based." What does this mean exactly? What
are "objects"-the communication medium between
clients and servers-in the context of OLE? In order
to answer this question, we have to look at all the
various definitions of the term so we can really
understand why an OLE object is what it is. The
concepts that form the idea of an OLE object are
collectively called the Component Object Model,
or COM.
---
Kraig Brockschmidt, "Inside OLE 2", Microsoft Press,
1994.
-----
This book provides examples for creating COM
components in both C and C++. Perhaps I missed
something; but, from what I saw of the interfacing
requirements for C, it seems to me that procedural
COBOL, with the appropriate C-like extensions,
could be used to build COM components.

> A component is not just a module. A component is totally encapsulated and
> can only be used through its interface. Even the individual internal
methods
> are encapsulated. Properties are accessed through GET and SET methods,
> explicitly or implicity. A component can be dropped into a web page, or
> embedded in a desktop application, with no change. It can be instantiated
> locally and remotely, and created and destroyed on demand; modules can't
be.
> They have to be wrapped properly to enable it and that wrapping is most
> easily implemented through OO. Java Beans are true components, Programs
> implementing the COM interface are true components (The "O" stands for
> "OBJECT", however :-)), C# Assemblys are (usually) true components (the
> exception would be desktop apps where the interface is a command line...
why
> is the command line a show stopper? Because you need to shell to use it...
> it is NOT an instantiable interface), but procedural modules are not. It
is
> all about how you can interface and build them together. True components
can
> be built into systems with other components that are not even written in
the
> same language. That is true "Encapsulation".

H'm, "true" anything seems more opinion than fact!

[snip]
>
> I had a feeling you would make this post, Rick :-)

But, you phrased it as you did, anyway! <g>



0
Reply ricksmith (875) 10/12/2007 10:00:53 PM


"Rick Smith" <ricksmith@mfi.net> wrote in message 
news:13gvrpl68mj3v06@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5n7tqmFgjcluU1@mid.individual.net...
>>
>>
>> "Rick Smith" <ricksmith@mfi.net> wrote in message
>> news:13gsmjsr5p3572@corp.supernews.com...
>> >
>> > "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
>> > news:5mtjd5Ff4j98U1@mid.individual.net...
> [snip]
>> >> It is a hard concept for non-OO people to understand and that's why I
>> >> more
>> >> or less gave up trying to explain it here some time ago. Component
> based
>> >> systems do NOT need maintenance in the same way that procedural COBOL
>> >> code
>> >> does, and there is no need for regression testing.
>> >
>> > What of components written in procedural COBOL?
>>
>> Depends how you define "Component".
>
> As the respondee ("you", taken literally), I choose the
> following definition.
> -----
> component
>
> 2. An individual modular software routine that
> has been compiled, dynamically linked, and is
> ready to use with other components or programs.
> -----
> Within the context of component software.
> -----
> component software
>
> Modular software routines, or components, that can
> be combined with other components to form an overall
> program. A programmer can use and reuse an existing
> component and not have to understand its inner
> workings, just how to have another program or
> component call it and pass data to and from it.
> ---
> Microsoft� Bookshelf� Computer and Internet
> Dictionary� 1997 Microsoft Corporation. All rights
> reserved. Portions, Microsoft Press� Computer
> Dictionary, Third Edition. Copyright � 1997 by
> Microsoft Press. All rights reserved.
> -----
>
> Thus, it would seem that many "dynamically linked"
> COBOL programs would qualify as components.
>
>> I have wriiten many components in OO COBOL. I could not achieve the same
>> functionality if they were written in procedural COBOL. (I couldn't
>> implement the COM wrapping in procedural COBOL for a start. It is
> inherited
>> from a Base Class)
>
> COM (Component Object Model) is only one possible
> component model.
>
> I find it curious that you seem to suggest that COM
> requires OO, since COM is object-based.
> -----
> Object-Based Components: COM
>
> Our definition of OLE describes services as being
> "object-based." What does this mean exactly? What
> are "objects"-the communication medium between
> clients and servers-in the context of OLE? In order
> to answer this question, we have to look at all the
> various definitions of the term so we can really
> understand why an OLE object is what it is. The
> concepts that form the idea of an OLE object are
> collectively called the Component Object Model,
> or COM.
> ---
> Kraig Brockschmidt, "Inside OLE 2", Microsoft Press,
> 1994.
> -----
> This book provides examples for creating COM
> components in both C and C++. Perhaps I missed
> something; but, from what I saw of the interfacing
> requirements for C, it seems to me that procedural
> COBOL, with the appropriate C-like extensions,
> could be used to build COM components.

Yes, it can, and, in the very early days before I used OO COBOL, I did 
exactly that. It was a nightmare! All of the wrapping had to be done 
manually.  All of the mind-numbing background on Base Methods, interfaces, 
marshalling, Authentication, impersonation,  had to be read and understood 
then applied. With Fujitsu  OO COBOL (NetCOBOL and PowerCOBOL) it is a 
single line of code, inheriting from a provided COM Base class. You can 
build COM components in PowerCOBOL without having any understanding of OOP. 
It is all done for you under the covers.

>
>> A component is not just a module. A component is totally encapsulated and
>> can only be used through its interface. Even the individual internal
> methods
>> are encapsulated. Properties are accessed through GET and SET methods,
>> explicitly or implicity. A component can be dropped into a web page, or
>> embedded in a desktop application, with no change. It can be instantiated
>> locally and remotely, and created and destroyed on demand; modules can't
> be.
>> They have to be wrapped properly to enable it and that wrapping is most
>> easily implemented through OO. Java Beans are true components, Programs
>> implementing the COM interface are true components (The "O" stands for
>> "OBJECT", however :-)), C# Assemblys are (usually) true components (the
>> exception would be desktop apps where the interface is a command line...
> why
>> is the command line a show stopper? Because you need to shell to use 
>> it...
>> it is NOT an instantiable interface), but procedural modules are not. It
> is
>> all about how you can interface and build them together. True components
> can
>> be built into systems with other components that are not even written in
> the
>> same language. That is true "Encapsulation".
>
> H'm, "true" anything seems more opinion than fact!

Fair comment. That is my opinion.
>
> [snip]
>>
>> I had a feeling you would make this post, Rick :-)
>
> But, you phrased it as you did, anyway! <g>

I didn't do so to be argumentative and I don't entirely disagree with your 
position. It is just that I deal almost exclusively in component based 
systems and have done so for more than 10 years. They are a long way more 
capable than modular COBOL. (I spent more than 10 years writing that, too 
:-).

I should have perhaps stated that you CAN build what I consider to be true 
components (even if a limited subset) in COBOL, without needing to use OO 
COBOL.  But you CAN build computer systems in Hexadecimal representations of 
machine code... who would? :-)

Pete.
-- 
"I used to write COBOL...now I can do anything." 


0
Reply dashwood (4370) 10/13/2007 1:42:49 AM

Interesting discussion... Here are some thoughts and history you all
might find interesting.

I was deeply involved in trying to get OO COBOL off the the ground
while at Micro Focus. The general thought from a marketing perspective
was that a high percentage of "C" programmers had become C++
programmers, so it logically followed that a high percentage of COBOL
programmers would become OO COBOL programmers. Given that at the time
there were significantly more COBOL programmers than "C" programmers
when C++ came out, the general thought was that the OO COBOL market
would be huge. This never materialized.

I believe OO COBOL failed for 4 main reasons:

1. The God awfully slow ANSI COBOL committee argued over it for so
long and failed to produce a standard for so long it became
irrelevant.

2. OO COBOL was not just a simple enhancement to COBOL, but rather
almost a completely new language - particularly in the thought process
required to use it effectively. COBOL programmers who had the
opportunity to learn something new simply chose something more
mainstream - like C++ or JAVA (and later .NET languages). It was a
major mind leap for a COBOL programmer to write OO COBOL applications.

3. Lack of class libraries in early versions. There were few building
blocks that came along with it...

4. COBOL programmers felt they could do just about anything in
traditional COBOL that could be done in OO COBOL. Translation... - no
compelling reason to invest in OO COBOL.

Now a few interesting historical tidbits:

1. The founder and then Chairman to Micro Focus tried to swing the
company over to the Web - to build a "Web Workbench" based on Micro
Focus OO COBOL. Sounds a bit crazy, but MF COBOL was then on some 500
platforms with .INT based upon a virtual machine, a GUI library
(Panels/2) that was portable across platforms, and a design that was
actually well suited for internet applications. Micro Focus COBOL was
doing HTML stuff on the web before JAVA ever arrived.... The company,
however, simply did not invest in his vision.

2. Micro Focus attempted to acquire a product named "Frontpage" from
Vermeer Technologies Inc. (ever wonder what those "vti_" folder names
in Frontpage webs stood for..?) before Microsoft finally acquired
such. This was going to become the basis of a Web Workbench. Microsoft
outbid Micro Focus on Frontpage....

3. I hosted James Gosling (father of JAVA) at Micro Focus in 1996 (the
year of the first Java One conference at Masconi in S.F. if I remember
correctly...). There is a striking resemblance in the original
achitecture of JAVA (virtual machine code, AWT, etc.) to Micro Focus
COBOL. We were looking at ways to hook Java and COBOL up on the
web....

4. I attended the first Java One conference in S.F. the same year.
There was an optional first come first serve pre-conference Java
training session early the first morning, which had room for about 250
attendees and I believe over 750 people showed up and tried to cram
their way in. The session leader was a professor from some university
in New York as I recall (Maybe the Univ. of Rochester?). In any
regard, his opening words were "Welcome to the first conference on
interpreted COBOL!" - which drew a loud chuckle from the audience...
(I kid you not).....

When .NET arrived and I researched my book for Fujitsu NetCOBOL I got
incredibly excited that it was possible to use primarily procedural
COBOL with an Object Oriented framework (.NET) and could paint Web
Forms and Win Forms and generate COBOL. Unfortunately, it was simply
too late for COBOL by this time. Few people would build complex
graphical or web applications in COBOL. The future of COBOL in my
opinion is to leverage existing code on new platforms (e.g. move
mainframe COBOL to Windows) and try to modernize it using technologies
like Web Services and such. It is possible ot take existing COBOL
programs and turn them into Web services without a lot of work.

As far as writing new COBOL applications, there are a few of us that
can still write anything in COBOL that can be written in languages
like C# and VB.NET and JAVA (including, I suspect, several people on
this thread), but we are a dwindling number. Micro Focus still
maintains the most sophisticated COBOL programmers on the planet in
their own development teams (Much of Micro Focus COBOL and tool
continue to be written in - Micro Focus COBOL.

It's a shame, because COBOL is still the most easy to maintain
language I've ever worked in (and I'm even MCP certified in C#
now...), but the simple fact is that slow movement by the keepers of
COBOL (e.g. the ANSI COBOL committee) doomed COBOL in my humble
opinion by not keeping it quickly up to date with modern concepts.
ANSI 85 (1985) COBOL continues to be the most significant change to
COBOL in its history in my opinion, yet it took upwards of 15 more
years to get even a partial OO COBOL standard published. And more
years of argument followed after that...

-Howard Hinman

0
Reply hhinman (1) 10/17/2007 4:06:41 AM


<hhinman@awebdomain.com> wrote in message 
news:1192594001.276228.66560@q5g2000prf.googlegroups.com...
> Interesting discussion... Here are some thoughts and history you all
> might find interesting.
>
I, for one, found it VERY interesting. Thanks for posting it.

> I was deeply involved in trying to get OO COBOL off the the ground
> while at Micro Focus. The general thought from a marketing perspective
> was that a high percentage of "C" programmers had become C++
> programmers, so it logically followed that a high percentage of COBOL
> programmers would become OO COBOL programmers. Given that at the time
> there were significantly more COBOL programmers than "C" programmers
> when C++ came out, the general thought was that the OO COBOL market
> would be huge. This never materialized.
>
> I believe OO COBOL failed for 4 main reasons:
>
> 1. The God awfully slow ANSI COBOL committee argued over it for so
> long and failed to produce a standard for so long it became
> irrelevant.

I'm not going there, but let me just say that I completely agree with you.
>
> 2. OO COBOL was not just a simple enhancement to COBOL, but rather
> almost a completely new language - particularly in the thought process
> required to use it effectively.

I believe it was one of the finest feats of software engineering I have ever 
seen, in a career spannning  over 40 years. It was just that it was never 
properly "sold" to the target audience.

>COBOL programmers who had the
> opportunity to learn something new simply chose something more
> mainstream - like C++ or JAVA (and later .NET languages). It was a
> major mind leap for a COBOL programmer to write OO COBOL applications.

Absolutely. Especially if you tried to do it by teaching yourself from an OO 
COBOL manual.
>
> 3. Lack of class libraries in early versions. There were few building
> blocks that came along with it...

Later on Fujitsu provided some excellent Class libraries, but of course they 
were not compatible with any other vendor's...
>
> 4. COBOL programmers felt they could do just about anything in
> traditional COBOL that could be done in OO COBOL. Translation... - no
> compelling reason to invest in OO COBOL.

Spot on.

>
> Now a few interesting historical tidbits:
>
> 1. The founder and then Chairman to Micro Focus tried to swing the
> company over to the Web - to build a "Web Workbench" based on Micro
> Focus OO COBOL. Sounds a bit crazy, but MF COBOL was then on some 500
> platforms with .INT based upon a virtual machine, a GUI library
> (Panels/2) that was portable across platforms, and a design that was
> actually well suited for internet applications. Micro Focus COBOL was
> doing HTML stuff on the web before JAVA ever arrived.... The company,
> however, simply did not invest in his vision.

It's a pity.

>
> 2. Micro Focus attempted to acquire a product named "Frontpage" from
> Vermeer Technologies Inc. (ever wonder what those "vti_" folder names
> in Frontpage webs stood for..?) before Microsoft finally acquired
> such. This was going to become the basis of a Web Workbench. Microsoft
> outbid Micro Focus on Frontpage....

Actually, I did know what the vti stands for, but I didn't know MF had tried 
to acquire it :-)
>
> 3. I hosted James Gosling (father of JAVA) at Micro Focus in 1996 (the
> year of the first Java One conference at Masconi in S.F. if I remember
> correctly...). There is a striking resemblance in the original
> achitecture of JAVA (virtual machine code, AWT, etc.) to Micro Focus
> COBOL. We were looking at ways to hook Java and COBOL up on the
> web....
>
> 4. I attended the first Java One conference in S.F. the same year.
> There was an optional first come first serve pre-conference Java
> training session early the first morning, which had room for about 250
> attendees and I believe over 750 people showed up and tried to cram
> their way in. The session leader was a professor from some university
> in New York as I recall (Maybe the Univ. of Rochester?). In any
> regard, his opening words were "Welcome to the first conference on
> interpreted COBOL!" - which drew a loud chuckle from the audience...
> (I kid you not).....
>
> When .NET arrived and I researched my book for Fujitsu NetCOBOL I got
> incredibly excited that it was possible to use primarily procedural
> COBOL with an Object Oriented framework (.NET) and could paint Web
> Forms and Win Forms and generate COBOL. Unfortunately, it was simply
> too late for COBOL by this time.

Yes, it probably was. Even if it wasn't, there are so many things provided 
by the other languages that facilitated Web Development and that COBOL was 
weak in. I have done exactly what you describe and leveraged procedural (and 
OO) COBOL into the DotNET environment, using Interop Services and C#; the OO 
COBOL fares better...

> Few people would build complex
> graphical or web applications in COBOL. The future of COBOL in my
> opinion is to leverage existing code on new platforms (e.g. move
> mainframe COBOL to Windows) and try to modernize it using technologies
> like Web Services and such.
I agree that SOA and Web Services is the way to go for most companies. 
(Actually, the extension of this: SaaS, is likely to be the end result for 
(especially) SMEs that simply can't afford the cost of in-house development, 
even using OO languages, never mind Procedural COBOL...)


> It is possible ot take existing COBOL
> programs and turn them into Web services without a lot of work.
>
Depends on how they're written... :-) Most of mine are written as COM 
components anyway so very little sweat.

> As far as writing new COBOL applications, there are a few of us that
> can still write anything in COBOL that can be written in languages
> like C# and VB.NET and JAVA (including, I suspect, several people on
> this thread), but we are a dwindling number.

Can you read that again? I'm not sure what you are saying here.


> Micro Focus still
> maintains the most sophisticated COBOL programmers on the planet in
> their own development teams (Much of Micro Focus COBOL and tool
> continue to be written in - Micro Focus COBOL.
>
> It's a shame, because COBOL is still the most easy to maintain
> language I've ever worked in (and I'm even MCP certified in C#
> now...),
Strongly disagree :-) There's a lot more to "Maintenance" than simply 
changing lines of code.

I have reached a point now where I only use COBOL because I HAVE to. I'd 
rather maintain C#... the debugging tools are better, IntelliSense makes 
writing it a doddle, and there isn't all the regression testing you need 
with procedural code.

> but the simple fact is that slow movement by the keepers of
> COBOL (e.g. the ANSI COBOL committee) doomed COBOL in my humble
> opinion by not keeping it quickly up to date with modern concepts.

You should have been here a few years back... :-)

> ANSI 85 (1985) COBOL continues to be the most significant change to
> COBOL in its history in my opinion, yet it took upwards of 15 more
> years to get even a partial OO COBOL standard published. And more
> years of argument followed after that...

Yeah... we know... :-)

Thanks for a very interesting and informative post Howard.

Pete.
-- 
"I used to write COBOL...now I can do anything."


0
Reply dashwood (4370) 10/17/2007 1:54:48 PM

On Tue, 16 Oct 2007 21:06:41 -0700, hhinman@awebdomain.com wrote:

>I believe OO COBOL failed for 4 main reasons:
>
>1. The God awfully slow ANSI COBOL committee argued over it for so
>long and failed to produce a standard for so long it became
>irrelevant.

That's a big disadvantage in trying to modify an old tool instead of
creating a new tool.

>2. OO COBOL was not just a simple enhancement to COBOL, but rather
>almost a completely new language - particularly in the thought process
>required to use it effectively. COBOL programmers who had the
>opportunity to learn something new simply chose something more
>mainstream - like C++ or JAVA (and later .NET languages). It was a
>major mind leap for a COBOL programmer to write OO COBOL applications.

I believe we would have been better off with a new language that
incorporated CoBOL's strengths.

>3. Lack of class libraries in early versions. There were few building
>blocks that came along with it...

That just doesn't make sense with OO.   It could have started off
using some other language's compiled class libraries.

>4. COBOL programmers felt they could do just about anything in
>traditional COBOL that could be done in OO COBOL. Translation... - no
>compelling reason to invest in OO COBOL.

And since OO CoBOL is called CoBOL, nobody new was interested in it.
We needed a new language.   I think we still need one.
0
Reply howard (6275) 10/17/2007 2:18:11 PM

Hey Howard, good to see that you are still around.

Remember the problems that I had writing COBOL objects in net Express
3.0/3.1 and Fujitsu 6 for Macola? If I forgot to say it, Thanks for
your help on that project.
I swore that after that I would never use a bleeding edge compiler
again.. but that I was ordering Fujitsu Cobol.Net v1.
Your book/video was a great help getting me started. I would recommend
it to anyone who is just starting with the compiler.

Tom Leaders


0
Reply tleaders (26) 10/17/2007 2:30:41 PM

>>> On 10/17/2007 at 8:18 AM, in message
<n76ch3lecd0dvrnmintstnn1e2iqlp2db2@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Tue, 16 Oct 2007 21:06:41 -0700, hhinman@awebdomain.com wrote:
> 
>>I believe OO COBOL failed for 4 main reasons:
>>
>>1. The God awfully slow ANSI COBOL committee argued over it for so
>>long and failed to produce a standard for so long it became
>>irrelevant.
> 
> That's a big disadvantage in trying to modify an old tool instead of
> creating a new tool.
> 
>>2. OO COBOL was not just a simple enhancement to COBOL, but rather
>>almost a completely new language - particularly in the thought process
>>required to use it effectively. COBOL programmers who had the
>>opportunity to learn something new simply chose something more
>>mainstream - like C++ or JAVA (and later .NET languages). It was a
>>major mind leap for a COBOL programmer to write OO COBOL applications.
> 
> I believe we would have been better off with a new language that
> incorporated CoBOL's strengths.

I'm all for this.  When do we start?
:-)
 
>>3. Lack of class libraries in early versions. There were few building
>>blocks that came along with it...
> 
> That just doesn't make sense with OO.   It could have started off
> using some other language's compiled class libraries.
> 
>>4. COBOL programmers felt they could do just about anything in
>>traditional COBOL that could be done in OO COBOL. Translation... - no
>>compelling reason to invest in OO COBOL.
> 
> And since OO CoBOL is called CoBOL, nobody new was interested in it.
> We needed a new language.   I think we still need one.

I agree.  I have a lot of thoughts of what I think should be in a language
to replace Cobol.  I don't think any of them are 'original thoughts', but so
far as I can tell there isn't any single language that incorporates them
all.  I won't take a stab at posting these things here, as most of them are
only partially thought out and very poorly documented.  Still, its a dream
of mine.

Frank

0
Reply Frank.Swarbrick (670) 10/17/2007 4:49:23 PM
comp.lang.cobol 4203 articles. 4 followers. Post

46 Replies
354 Views

Similar Articles

[PageSpeed] 44


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

OO COBOL
Looking for something else, but see this reference to COBOL in an ADA FAQ :-) Some Other Programming Languages * C++ --a single-letter OO language, still far from being standardized [according to the comp.std.c++ FAQ] * Eiffel --a sophisticated language striving for "OO purity", the best for assertions * Common Lisp --a huge, parenthesized ()() language * Perl --The Practical Extraction and Report Language, is OO too * Tcl and Tk --the Tool Command Language and Toolkit * Python --yet another OO language * Fortran 90 --from "Night of the ...

XML and OO COBOL
I have been receiving a few mails lately, requesting some light on XML in COBOL. And I understand the Standards Committee are looking at including XML support into a future version of COBOL. I don't see any need for this (fashions change and the "replacement" for XML is already in the pipeline) but I guess if it keeps them off the streets, I have to vote for it <G> When it comes to XML you COULD write copious COBOL code to parse it and extract tagged data from it, but why would you? Those of us who use OO will simply use components to process it anyway. (Those of you who...

what is the status of oo cobol?
What is the status of OO cobol in Europe, US and the rest of the world? Are there any big companies using it and if so, where? What is the experience with using OO cobol? Can cobol really be combined with an OO approach? Why would someone choose to use OO cobol and why would they choose not to use it? Are there any inherent advantages or disadvantages to OO cobol? Is there a future for OO cobol? These are such good questions I felt compelled to respond... "oeij" <huitheng.oeij@cgey.nl> wrote in message news:5149d10b.0307310538.3ab3900d@posting.google.com... > What is the st...

Demo: OO Cobol
* [Continued from forest.cbl] * This demo of object oriented Cobol continues the theme of sorts and * trees. It inserts 50,000 random strings into a structure then does * 50,000 lookups. * * One of the main attractions of OO is reusable Components. So rather * than writing the code myself, as in previous demos, I chose to use two * off-the-shelf Collection Classes provided by Micro Focus. One is * called Sorted Collection and the other Dictionary. Both appear to use * hashing to file and locate entries. Sorted Collection has a method to * insert an entire Collection with a single operation; D...

SQL wrapper in OO cobol
Would someone be interested in writing (or has someone ever written) an OO cobol extension to wrap all the embedded sql statements ? We could have a db class with calls to it with something like object section. class-control. ooDB is class "oodb". ..... working-storage section. 1 aDb object reference. procedure division. invoke ooDb "new" returning aDb invoke aDb "Connect" using 'dbuser', 'dbpass', 'dbhost', 'dbport', 'dbname' move 'SELECT * FROM table WHERE foo=1 and bar=2' to query invoke aDb "...

Usesage OO (enterprise) COBOL
I am busy investigating the use and advantages of OO (enterprise) COBOL. After searching the Internet I got the feeling that OO COBOL isn't used much. Which companies already use OO COBOL? Was the conversion difficult? How is the interaction between COBOL and JAVA, .NET and other OO languages? Does the OO COBOL have advantages in practice? Thanks in advance, Patrick Heijne > I am busy investigating the use and advantages of OO (enterprise) > COBOL. After searching the Internet I got the feeling that OO COBOL > isn't used much. My observation is that OO COBOL ...

Earley Parser for OO-COBOL?
2005-12-15 12:09:06 MET Hi, I was told that there exists a context-free grammar for current OO-COBOL which can be parsed by the Earley-Algorithm. Did anyone have a real-life-contact with that sort of thing? Not that I advocate the use of this algorithm in real-life-compilers - they require too much resources. And as for a ESQL-Precompiler on which I work now, I am totally happy with YACC, because the Parser of a PreCompiler only sees part of COBOL. For playing with Earley-Parsers, see here: http://accent.compilertools.net/ I downloaded it and it could be made to run on Linux, on CygWin ...

OO Cobol nice things
Hello, I would like to share with you an example of how to use OO Cobol to post a Twitter status update. I wrote this using NetCobol.Net 4, but it is very ease to port to NetExpress). http://www.twitter.com/100CoolThings The code can be downloaded from my web site http://www.100coolthings.net Regards, Emerson ...

Cobol and OO programming: the final chapter!
The history of Cobol today is often modeled as an evolution in steps from the earliest primitive beliefs, through the modern classics, finally to what is referred to as OO programming Cobol, currently topping the model. The model is usually laid out to show how subsequent routines address problems inherent to earlier ones, while inevitably creating new more complex ones inherent to themselves, with the unenlightened implication being that this evolution naturally leads to superior routines, and possibly one day to an ultimate Cobol supreme. We all know that Cobol gets no respect these days...

Running a OO COBOL program from a JCL.
Hi, Has anyone been able to run this example successfully ? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/igy3pg32/2.3.2.3.1?SHELF=&DT=20061117131343 I am able to compile and link successfully. While executing, I get this error : IGZ0099C Internal error MAINCLAS was detected in module IGZCII1. The traceback information could not be determined. I checked the error message ; but, the module name is not mentioned in the list ! http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CEEA9150/SPTCS00519 Regards, Nags SCRATCH THE EARLIER POST. Sorry about the mi...

Is OO COBOL relevant today or is it unnecessary?
As an OO COBOL user for nearly 20 years now, and seeing some fairly direct criticism in the "Phase 1 - Rosetta bottles of beer" thread, I thought it might be interesting to see how people feel about OO COBOL, and why they feel that way (particularly if they have never used it, although not having used something doesn't preclude people having an opinion about it :-)) Jimmy Gavan posted an OO COBOL example of the well-known "Bottles of beer" problem. To an "ininitiated" (read "unfamiliar with OO COBOL...") eye this code looks like a severe depa...

php framework docs as cobol oo tutorial
From: Warren Simmons (wsimmons5@optonline.net) Subject: OO Tutorial View: Original Format Newsgroups: comp.lang.cobol Date: 2004-06-08 11:37:45 PST http://www.phppeanuts.org/site I've run into the site shown above which has a lot of detail on the OO approach . A tool to create programs (said to be of all kinds), it should be of interest to some of you. If NOT, forget it. (NJ talk.) Warren Simmons ------------------------------- ;-) Henk Verhoeven www.phppeanuts.org ...

Thoughts on teaching OO concepts to COBOL programmers
I've recently found myself tasked with teaching a few dozen IBM mainframe COBOL programmers the concepts of object oriented programming. No specific language syntax, just the concepts. These lucky few dinos will find themselves mixing their COBOL back-ends with standard Java apps, J2EE apps, C# apps, or Ruby apps. My specific goal is not to teach any language specific thing (though I might use Java for the examples and kill the J2SE, J2EE and C# syntax with a single invocation of the stone.throw() method). My purpose is to teach the simple "what is an object", "wh...

OO-COBOL and java Dynamic call to subroutine
I wrote a OO-Cobol wrapper class to call a cobol subroutine from Java. It works very well if i am doing static calls from the OO-Cobol wrapper class. But I want to using dynamic calls i.e. call the routine at runtime. This does not work because Compiler options dll and dynamic are mutually exclusive. I know that I can write my own JNI interface in C and have the C code dynamically load and call my (LE conforming) Cobol routine, but I want to use COBOL in that case. Has Anyone an idea ? All suggestions are welcome. Thank's very much. First, to those who don't recognize the "buzz-...

Re: OO-COBOL and java Dynamic call to subroutine
It's unfortunate they named the options DYNAM and NODYNAM. It really should be DYNAMALWAYS and NODYNAMALWAYS. n 2/24/2009 at 8:54 PM, in message <Qh3pl.54057$Rp1.2394@en-nntp-01.dc1.easynews.com>, William M. Klein<wmklein@nospam.ix.netcom.com> wrote: > First, to those who don't recognize the "buzz-words", this must be for > Enterprise COBOL on z/OS. > > Now to answer, I think that when the DLL compiler option is specified, > that you > MAY use > Call identifier > rather than > Call "literal" > > so you CAN sti...

"in search of" International (not the usual coutnries) OO COBOL users
I know that we have "lurkers" (and some more active participants) in this group from a number of counties (other than the "usual" US, UK, Germany, Canada, and New Zealand) If any of you reading this note A) Live and WORK in any of these countries: - Spain - France - Denmark - Australia - South Africa - Finland - Switzerland - Singapore - Czech Republic - Korea, Republic of - Belgium - (Ireland - China - Slovenia - Norway - Italy >>> AND <<< B) You currently work (or play <G>) with Object Orientation in COBOL (especially wit...

S013-C0 while compiling OO COBOL program using a job step.
Hi, I am trying to compile my OO COBOL program on z/OS using JCL. The program has been written in a HFS file. I am getting this message : IEC141I 013-C0,IGG0199G,S611204C,STEP1,SYSJAVA ACCESS INTENT(RW-) ACCESS ALLOWED(OWNER ---) EFFECTIVE UID(0000000237) EFFECTIVE GID(0000000191) whereas, in the JCL I have, //SYSJAVA DD PATH='/u/userid/java/&SRC..java', // PATHOPTS=(ORDWR,OCREAT,OTRUNC), // PATHDISP=KEEP, // PATHMODE=(SIRWXU,SIRWXG,SIRWXO) also, I have set the options of /u/userid/java to 777 (!). Can someone please tell me why thi...

ANSI/ISO TR (technical reports) for COBOL
To: comp.lang.cobol IBM-MAIN lngc distribution list Tek-Tips COBOL forum etc J4 and WG4 (the ANSI and ISO-ish) COBOL groups are progressing with their 2nd and 3rd TRs (Technical Reports) to "expand" the ISO 2002 COBOL Standard. Both of these reports (similar but not quite the same as previous "Amendments") will be processed by ISO via "national body" comments. If you are in the US (or deal with the US via COBOL activities) it is important that you get your comments on these drafts to J4 >>> BY MARCH 21 <<&l...

Re Thoughts on teaching OO concepts to COBOL programmers (by razor iruddock@blueyonder.co.uk)
my only suggestion would be to find someone else to teach the dinos as dinos are primitive creatures and will have no problem smelling the comtempt (ie: fear) you have of them. i speak from experience on this point as i am a dino who has been subjected to the taunts of fifth-reich oo storm troopers and their ..... i don't believe that a text book is what you need. i don't believe that you are the person for this job. sss --------------= Posted using GrabIt =---------------- ------= Binary Usenet downloading made easy =--------- -= Get GrabIt for free from http://www.shemes.co...

What Level of TRANSFINITY are you? oo^(oo^(oo^(oo^...oo)))
Moreover, the existential quantifier is interpreted only with respect to its status as a derivative concept relative to the universal quantifier. These are the underlying assumptions of construction that allow the self-inconsistency of a specific syntactic form to be extended to a metaphysical assertion of reality. ~ MITCH (sci.logic) - - - - - - - - - - - - - - - - - - - - - - - - - - - LEVEL oo^(oo^(oo^(oo^...oo))) The True Believer! "There are SOOO.. MANY more Reals than Naturals!" - - - - - - - - - - - - - - - - - - - - - - - - - - LEVEL ((((oo^oo)^oo)^o...

Oo, Oo, Oo! Buy a Surface NOW
Microsoft cuts Surface Pro tablet prices by $100 <http://news.cnet.com/8301-10805_3-57596910-75/microsoft-cuts-surface-pro -tablet-prices-by-$100/> Discounts come just days after the tech titan reveals that marketing the tablets has cost more than the revenue they have brought in. ** Apple's going bust any day now!!! :-D In article <fmoore-51DDB4.11293405082013@mx05.eternal-september.org>, Fred Moore <fmoore@gcfn.org> wrote: > Microsoft cuts Surface Pro tablet prices by $100 > <http://news.cnet.com/8301-10805_3-57596910-75/microsoft-cuts-sur...

Oo, Oo, Oo, I Can't Wait To Do THIS!
How to add emoji icons to file names in OS X <http://reviews.cnet.com/8301-13727_7-57546042-263/how-to-add-emoji-icons -to-file-names-in-os-x/> The closing paragraph is a masterpiece of understatement: 'Unfortunately since the emoticon fonts are Unicode-based, they will not work in some services that do not support Unicode. If you frequently use the OS X Terminal, then you will find that adding symbols to file names will have them appear as question marks in the Terminal, making them difficult to identify and manage.' I just LOVE the triumph of form over substa...

How much OO is too much OO?
Hello There seems to be lots of information out there on how to use good OO practices, principles and patterns, but it's not clear to me how far to go with these, and when. It seems some people go full tilt with all projects. For example, I read one post where the author states his base classes are always abstract and he never programs to concrete classes, but to interfaces, and so on. Others maintain that most of these practices are irrelevant until/ unless you need to make a change to your program and find out that it's inflexible or hard to grow in a certain area. Or, of course, ...

COBOL II to Enterprise COBOL
Hi, I need to change the some 1000 Program from COBOL II to Enterprise COBOL. What are the essential difference between COBOL II to Enterprise COBOL. How much can it affect my code ? (There are not much DB2,CICS in my code) Thanks, Dib If you are using the NOCMPR2 compiler option with your VS COBOL II compiler and you are using the LE run-time (with RES) then you will probably find that there is almost NO change required. (a few new reserved words, but not many). If you are using the VS COBOL II run-time and/or the NORES option, then you will need to do LOTS of testing for both change...