IBM mainframe use of OO COBOL 
Author Message
 IBM mainframe use of OO COBOL

As a follow-on to earlier threads, I thought that I would add this
information concerning the use of OO COBOL in IBM mainframe shops (OS/390
and/or z/OS).

1) My internal sources indicate that IBM *does* know of some (more than
one - less than "lots") of shops using IBM COBOL's OO features.  None of
these shops, however, have gone thru the procedures to be an "official"
reference shop, so which they are is a "secret".

2) Enough shops are using (or considering using) this that IBM was "forced"
to keep the parts of SOMObjects needed for OO COBOL in LE (Language
Environment) when they removed it from being a "full feature" of OS/390 and
z/OS.

3) The SYNTAX on the Workstation (Windows and AIX) for OO COBOL from IBM is
totally compatible with that on OS/390 (and is INCOMPATIBLE with the current
draft of the next ANSI/ISO Standard).  Therefore, it is "highly likely" that
IBM will be needing to provide SOME migration path for existing IBM OO COBOL
source code.  (Whether this is a "source converter" or a "which OO dialect
switch" - is certainly unclear to ME now - but those internal to IBM are
*probably* thinking ahead to this already).

  ***

The issue of OO COBOL on IBM mainframes is related to the "perception"
(incorrect - but fairly common) that OO and GUI's are "inter-related".  Most
"enterprise" size shops that are looking at OO (any language) first (and for
some ONLY) look at it for "user interface code".  As "user interfaces" in
IBM mainframe environments are USUALLY handled by CICS, IMS, ISPF, etc -
this is a "non-issue" for their application development (and maintenance).
If they are moving to a "workstation front-end" for their applications, then
they do look at a GUI *and* OO programming environment.  HOWEVER, as such
programs (by their nature) are done from "scratch" - it is likely that shops
will look at the OO programming languages with the most "press" rather than
where they already have in-house expertise.  (Furthermore, as these UI
portions of applications PRIMARILY run on the workstation, it doesn't
involve any OO on the mainframe.)

Bottom-Line:
  Until it is commonly "perceived" that OO is beneficial to the
NON-user-interface business logic, I don't see OO COBOL catching on (very
much) in IBM mainframe environments. When/If there are *standard*
(off-the-shelf) OO Class Libraries for *BUSINESS* rules, then I think that
they will be "accepted" and brought into use in IBM mainframes - to a much
greater extent than today.

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



Fri, 06 Feb 2004 04:39:14 GMT  
 IBM mainframe use of OO COBOL
Bill,
I'm glad you brought this up.  We did an application recently that was based
upon VisualAge COBOL and DB2.  It troubled me that VA COBOL was generating OO
COBOL for the window interface, when there is no adopted COBOL standard that
includes Object Orientation.

Since we were using some IBM assistance to help us over the learning curve, I
asked whether the release of VA COBOL that we were using could be told to
generate "classic" COBOL.  I never got the answer.

I must admit to not having succeeded in using, or becoming used to, OO COBOL.
However, I have tried to play with the code that I've seen in articles, etc.
Often, the code doesn't even compile, because I'm using a different compiler
than the author.  To me, THIS ISN'T COBOL!  The reason COBOL is the most widely
used computer language is precisely because of the standard, that describes not
only the language syntax, but the results of using that syntax.  COBOL is
supposed to accept the same source code on all platforms, and the source is
supposed to perform the same everywhere.

I find the "early adoption" of OO COBOL to be an unfortunate by product of the
slow adoption of new COBOL standards.  People naturally want to try out "what's
now".  However, those who are using the OO COBOL than any vendor offers right
now are taking a BIG risk.

What do others think?



Sat, 07 Feb 2004 00:08:51 GMT  
 IBM mainframe use of OO COBOL


Quote:
> I find the "early adoption" of OO COBOL to be an unfortunate by product of
the
> slow adoption of new COBOL standards.

OO COBOL is part of the new Standards. The lack of this standard has led to
some vendors releasing their own versions of OO. By and large, they are
excellent implementations and we are fortunate that the vendors are more
interested in progressing COBOL than the Standards Authority appears to be.

I don't personally believe that the implementations are so far apart that it
is irreconcilable. The differences are slight. There have ALWAYS been
differences between various vendors' implementations of COBOL.

Quote:
>People naturally want to try out "what's
> now".  However, those who are using the OO COBOL than any vendor offers
right
> now are taking a BIG risk.

The "risk" in getting to grips with OO COBOL right now, is nowhere near as
high as the "risk" in NOT doing so...

Whether we like it or not, the future of computer programming lies in Object
Orientation. If COBOL misses this boat it will be dead in the water within
10 years.

The rise of OO languages like Java and C++ is not just down to fashion. It
is also because the Object Orientation makes them efficient and useful.

OO is the springboard that will give us components and that is where the
future is. (I have written at length elsewhere on this. If you want to see
the arguments go to http://www.aboutlegacycoding.com, take the "Archive"
link, and check out the main article ("Meet the Future") in the April issue
this year. In particular note the last paragraph of this article, where I
offer advice to COBOL programmers as to what to do next.)

You said in your post that you had trouble with understanding OO.

So did I.

OO COBOL is verbose and difficult when you approach it from a COBOL
background. The concepts are obscure and buried in new jargon. However,
there are shortcuts you can take and they are covered in the article
referenced above. Once you have the concepts, it falls into place pretty
quickly.

The game is coming down to using the best tools for the job. One single tool
won't hack it anymore. COBOL is still the best tool for certain jobs and is
likely to be for the foreseeable future.

But it is isolated by its archaic file system, and its lack of "object
awareness" which prevents it playing nicely with other languages.

OO addresses this and puts COBOL on the same footing as the other languages.
Components developed in OO COBOL behave just like components developed in
any other OO Language. The Source Language is irrelevant and should be the
one best suited to the purpose.

If you want to have a future using COBOL for anything other than Batch
Processing, learn OO and encourage others to do so too.

The future belongs to components, and you need OO COBOL to build them.

The "early implementations" which you perceive as "risky", are giving people
a chance to get with the program and improve their skill sets before it is
too late.

Apart from that, there are huge long term benefits in adopting OO, even if
you never write a single component with it.

Quote:

> What do others think?

<<<
(Bet you're sorry you asked...<G>)

Pete.

-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----



Sat, 07 Feb 2004 01:15:39 GMT  
 IBM mainframe use of OO COBOL



Quote:
> Whether we like it or not, the future of computer programming lies in
> Object
> Orientation. If COBOL misses this boat it will be dead in the water within
> 10 years.

Question to all:

Is Mr. Dashwood correct in his assessment?  Is he exaggerating?   What do
you think?



Sat, 07 Feb 2004 01:30:38 GMT  
 IBM mainframe use of OO COBOL

Quote:

> Bill,
> I'm glad you brought this up.  We did an application recently that was based
> upon VisualAge COBOL and DB2.  It troubled me that VA COBOL was generating OO
> COBOL for the window interface, when there is no adopted COBOL standard that
> includes Object Orientation.

> Since we were using some IBM assistance to help us over the learning curve, I
> asked whether the release of VA COBOL that we were using could be told to
> generate "classic" COBOL.  I never got the answer.

> I must admit to not having succeeded in using, or becoming used to, OO COBOL.
> However, I have tried to play with the code that I've seen in articles, etc.
> Often, the code doesn't even compile, because I'm using a different compiler
> than the author.  To me, THIS ISN'T COBOL!  The reason COBOL is the most widely
> used computer language is precisely because of the standard, that describes not
> only the language syntax, but the results of using that syntax.  COBOL is
> supposed to accept the same source code on all platforms, and the source is
> supposed to perform the same everywhere.

> I find the "early adoption" of OO COBOL to be an unfortunate by product of the
> slow adoption of new COBOL standards.  People naturally want to try out "what's
> now".  However, those who are using the OO COBOL than any vendor offers right
> now are taking a BIG risk.

> What do others think?

I wont comment on your references to IBM implementations, but my starting point is
your, "COBOL is supposed to accept the same source code on all platforms, and the
source is supposed to perform the same everywhere. ".

Couldn't agree more, and on that issue be nice if I could take IBM mainframe, PC
Fujitsu and Micro Focus source and could read a damned file from one to another.
Sure we have common OPEN, READ, REWRITE, WRITE etc. which all return the same
Standard-specified results - but we can't 'converse' because the internal
mechanics, (data structures, indexing etc.) are 'implementor defined'. Yes we can
read them - if we put them in DB tables.

Now when it comes to only using the 'written' standard we are currently talking
about COBOL '85, plus the '97 additions for Intrinsic Functions. Remembering the
'OO bit' started back in '89 and it will be 2002 before it is 'official' - where
would that put us ? OO-wise we would be in the 'COBOL Dark Ages" until about 2005
when developers dipped their feet into the waters to give it a try. As a
generalization I think it is accurate to say that vendor extensions (suck it and
see), have and always will be, in place before a feature is considered and becomes
part of the Standard.

As a small example, Micro Focus introduced a Level 78 :-

    78 ThisIsANumber                value 12.
    78 ThisIsATextItem               value "Hello World".

Apparently the idea appealed to J4, but they renamed these to CONSTANTS for COBOL
2002. (For 'Constant' read 'Concrete' - you can't change the value). Whether you
call it a Level 78 or a Constant - believe me, this is an extremely useful feature
and amongst other things, allows me to do the following :-

    01 myText    pic x(ThisIsANumber).

May look daft but extremely useful when part of a copyfile !

Back to OO :-

As regards writing the code once and then it is portable between compilers - to be
blunt - that is NOT in a compiler vendor's best interests is it ? Fortunately some
have noted the situation and WG4 representatives, (that's the ISO bit of COBOL
Standards) have hoisted a red warning flag about portability as applied to OO
collections.

Quote:
>I find the "early adoption" of OO COBOL to be an unfortunate by product of the
>slow adoption of new COBOL standards.  People naturally want to try out "what's
>now".  However, those who are using the OO COBOL than any vendor offers >right now

are taking a BIG risk.

"Slow adoption of new COBOL standards' - no disagreement from me - 1985 to 2002,
speaks for itself. I don't think one can refer to it as 'an early adoption' -
'early extension', if you like.  Not knowing the 'history' I'm willing to bet
compiler vendors were the original motivators, because they had their user-base
asking them about nifty features appearing in Windows and other OO  languages.

"People naturally want to try out "what's new". Certainly an element of truth in
that.
But that's not the case in my situation. I was happily working in DOS mode with the
M/F Screen Section. Knowing that 'monster' Windows 3.1 (?) was lurking in the
background, I was emulating menu-bars, pop-up menus and list boxes - albeit a bit
primitive, but they worked. Then my end-user started searching the 'Net. Cut a long
story short, we discovered a beta version of VISOC (now revamped as Net Express -
plus they jacked up the price !). I had absolutely no idea what the 'OO jazz' was
about, didn't even know the meaning of the words. The reason for switching - this
new product offered 'Windowing' - GUIs.

Had I been aware and searched around the 'Net I could have used any non-OO COBOL
and the Flexus product SP2 to give me Windowing/GUIs - would never have touched OO.
Do I regret the move - No. I wouldn't switched back to non-OO. Whether others will
see the light, remains to be be seen. (And it isn't truly going to take off in
COBOL until there are working compilers available for mainframes). Bill is right to
question whether OO COBOL will ever be popularly adopted - chicken and egg, no
compiler, no users.

Quote:
>  However, those who are using the OO COBOL than any vendor offers right
> now are taking a BIG risk.

I may be naive but I don't think there is the risk you suggest. Firstly the
Standard itself. J4 have been bending over backwards with new introductions or
changes to COBOL 2002 to ensure they are *backwards compatible* to COBOL '85. (I
don't know details - but '85 has ambiguities which can be read in different ways).
When it comes to vendors - same approach. They are in business to make a buck. That
example Level 78 I showed above. Even when COBOL 2002 introduces CONSTANTS be
assured Micro Focus will still allow me (for backwards compatibility) to use a
Level 78 - only snag with that is that you have lost portability to another
compiler.

As regards OO, a little more tricky. Micro Focus went to bat on a very early
version of the proposed Standard. Fujitsu and Hitachi picked up the baton but used
later (more definitive) versions of the standard. Similarly, as Thane mentioned,
Siemens are producing an OO compiler - and at this point in time Siemens is
probably 'closest' to what the Standard will be, (excluding OO
collections/dictionaries).

The 'guts' of OO is well defined, what classes and methods can do. In terms of
portable code the 'heading' of a Micro Focus source program looks different from
Fujitsu - the latter incorporate the later defined REPOSITORY Section. (Think in
terms of all those #include files that C or C++ source code has). So this will
present a problem, but with all the money already poured into development, be
assured each vendor will make it fit for backwards compatibility with existing
developer code.

An area which may present problems is collections/dictionaries. Again we have three
different versions, Fujitsu, Hitachi and Micro Focus, all supposedly based on
Smalltalk - hardly surprising, it has been around for 30 years and it works !
This may need some compiler vendor 'revamping' based on the final conclusions of
J4. But even that is not an insurmountable problem - given one vendor currently has
a method named "IwantToDoThis" and J4 decides there should be a method called
"ThisIsREALLYWhatIWantToDo" performing the same function - basically all our
intrepid vendor has to do for the interim :-

    *>---------------------------
    method-id. "IwantToDoThis"
    *>-------------------------
    Linkage section.
    01 ThisIsIn                            pic 9(03).
    01 ThisIsOut                         object reference.
    Procedure Division using ThisIsIn returning ThisIsOut.

        invoke self "ThisIsREALLYWhatIWantToDo"
            using ThisIsIn returning ThisIsOut

     *> and delete the code that appeared below for the original method

    End Method "IwantToDoThis".
    *>------------------------------

Presumably at some future date, (2, 3 years ?) the vendor drops all reference to
"IwantToDoThis" and  substitutes "ThisIsREALLYWhatIWantToDo".

Jimmy, Calgary AB



Sat, 07 Feb 2004 03:06:52 GMT  
 IBM mainframe use of OO COBOL
Well, being a "devil's advocate" - and knowing that I will upset Jimmy and
Pete (at least),

Several people said this same thing about 1994 when there was still hope
that the new COBOL Standard would be out by '97, i.e. that "COBOL would be
dead in 10 years - if there wasn't a STANDARD for OO COBOL by then.  Well we
are now MUCH closer to 2004 than we are to 1994 - and we still don't have a
STANDARD definition of OO COBOL.  (Well, actually, I think that the FCD is
pretty much set in concrete now - but there are ZERO implementations of its
complete OO definition).  Some how, COBOL is still not dead - and the place
where it is STILL most used (mainframes) is NOT clamoring for OO support.

It is my best guess (given the VERY slow adoption of '85 Standard coding
techniques in IBM mainframe COBOL shops - and possibly OTHER mainframe
environments), that COBOL will continue to be used (both for maintenance and
development) in LARGE enterprise (mainframe) environments for years and
years to come.  Furthermore, that MOST of the programs that will be
DEVELOPED (much less maintained) in these environments will be such that
they could ALMOST be compiled by an ANSI '74 compiler (at least a compiler
with a FEW extensions).

Now when it comes to moving out of "entrenched" environments, I totally
agree that not having OO support will harm the "growth" of COBOL.  However,
it is my perception (and of course I could be wrong <G>) that if COBOL did
everything but write itself and pay each programmer $1,000 per line of
code - it still has little or no chance of GAINING "market share" in the
programming environments in which it is not fully entrenched today.  The
"reputation" is just too bad - and the language itself is just too "out of
fashion" for it to gain in totally new environments - regardless of what
features are added or modified.

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

Quote:



> > Whether we like it or not, the future of computer programming lies in
> > Object
> > Orientation. If COBOL misses this boat it will be dead in the water
within
> > 10 years.

> Question to all:

> Is Mr. Dashwood correct in his assessment?  Is he exaggerating?   What do
> you think?



Sat, 07 Feb 2004 03:07:25 GMT  
 IBM mainframe use of OO COBOL

Quote:

> Well, being a "devil's advocate" - and knowing that I will upset Jimmy and
> Pete (at least),

Why not be the devil's advocate - I'm sure they call you all sorts of other
names at J4 <G>. Nope. You haven't upset me - your observations are accurate.
Does OO work - how can you really tell if you haven't access to a compiler.

You can spell out non-OO COBOL very clearly, (just so long as you don't
reference the FCD <G>). That's exactly what Thane has done in his book.

OO - different ball game. Given a mainframer had an OO compiler, might he not
just find it a little intriguing that you can write just ONE program that
accesses any ISAM file, (and that would negate all the sub-programming, nesting
or calling that was in the thread that started this topic).. Similarly, but this
is not parallel to Pete's components, your can write ONE program accessible by
all Dialogs. It's impossible to illustrate either of these concepts in a few
sentences.

All we can hope is that the mainframe vendors on J4 take the topic seriously and
DO produce mainframe OO compilers. Then people can experiment - OO in COBOL will
either fall flat on its face or take off.

I also agree with you on 'market share'. While still healthy in the States -
COBOL tuition elsewhere is diminishing. Those kids we lost to C, C++, Java,
Visual Basic or whatever - we are NEVER going to get them back.

Go chuck another bit of coal on Satan's fire <G>

Jimmy

Quote:

> Several people said this same thing about 1994 when there was still hope
> that the new COBOL Standard would be out by '97, i.e. that "COBOL would be
> dead in 10 years - if there wasn't a STANDARD for OO COBOL by then.  Well we
> are now MUCH closer to 2004 than we are to 1994 - and we still don't have a
> STANDARD definition of OO COBOL.  (Well, actually, I think that the FCD is
> pretty much set in concrete now - but there are ZERO implementations of its
> complete OO definition).  Some how, COBOL is still not dead - and the place
> where it is STILL most used (mainframes) is NOT clamoring for OO support.

> It is my best guess (given the VERY slow adoption of '85 Standard coding
> techniques in IBM mainframe COBOL shops - and possibly OTHER mainframe
> environments), that COBOL will continue to be used (both for maintenance and
> development) in LARGE enterprise (mainframe) environments for years and
> years to come.  Furthermore, that MOST of the programs that will be
> DEVELOPED (much less maintained) in these environments will be such that
> they could ALMOST be compiled by an ANSI '74 compiler (at least a compiler
> with a FEW extensions).

> Now when it comes to moving out of "entrenched" environments, I totally
> agree that not having OO support will harm the "growth" of COBOL.  However,
> it is my perception (and of course I could be wrong <G>) that if COBOL did
> everything but write itself and pay each programmer $1,000 per line of
> code - it still has little or no chance of GAINING "market share" in the
> programming environments in which it is not fully entrenched today.  The
> "reputation" is just too bad - and the language itself is just too "out of
> fashion" for it to gain in totally new environments - regardless of what
> features are added or modified.

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




> > > Whether we like it or not, the future of computer programming lies in
> > > Object
> > > Orientation. If COBOL misses this boat it will be dead in the water
> within
> > > 10 years.

> > Question to all:

> > Is Mr. Dashwood correct in his assessment?  Is he exaggerating?   What do
> > you think?



Sat, 07 Feb 2004 03:42:20 GMT  
 IBM mainframe use of OO COBOL


Quote:
> Now when it comes to moving out of "entrenched" environments, I totally
> agree that not having OO support will harm the "growth" of COBOL.
> However,
> it is my perception (and of course I could be wrong <G>) that if COBOL did
> everything but write itself and pay each programmer $1,000 per line of
> code - it still has little or no chance of GAINING "market share" in the
> programming environments in which it is not fully entrenched today.  The
> "reputation" is just too bad - and the language itself is just too "out of
> fashion" for it to gain in totally new environments - regardless of what
> features are added or modified.

That is my perception too.  There will continue to be some CoBOL programmers
who move to OO on the desktop, but I don't see Java nor C programmers
switching over to OO CoBOL.    Neither of us see new standards actually
changing the share of the market significantly.  The thing that makes CoBOL
out of fashion with techies is the same thing that makes it in fashion with
businesses - it is English like and wordy.

The one open issue is whether there will be any significant amount of OO
CoBOL on mainframe computers in an enterprise environment, replacing
standard business applications.   I haven't seen any evidence that this will
happen.

A niche market that might grow is mainframe web servers using OO CoBOL.



Sat, 07 Feb 2004 03:48:22 GMT  
 IBM mainframe use of OO COBOL
How many shops had some ANSI 68 CoBOL programs until Y2K got funding to
convert them?

I strongly suspect there are some large shops which had all of their
programs using a current compiler before the Y2K conversions - but this is
only a suspicion, they were outside of my experience as a contractor.

It is far more common to see the following code (and have programmers
understand it):

MOVE "GARBAGE" TO MY-FIELD
      PERFORM MY-PARAGRAPH
           UNTIL NEW-FIELD = MY-FIELD

than
PERFORM MY-PARAGRAPH WITH TEST AFTER
       UNTIL NEW-FIELD = MY-FIELD

Enterprise shops move slowly.   We get a new CoBOL standard - how long will
it take before half of its features become commonly used in most mainframe
shops?  (Don't even count OO features here - I don't know if they will EVER
be used in mainframe shops).



Sat, 07 Feb 2004 03:58:53 GMT  
 IBM mainframe use of OO COBOL
When it comes to IBM mainframe shops, one (aka I) wonder of the '68 Standard
and IBM "old" extensions will EVER die (especially as IBM now DOCUMENTS that
they support such object code - with the LE run-time library).

I really wonder how many programs still have TRANSFORM and/or READY TRACE
statements in them?  (interestingly enough, Micro Focus accepts both of
these AS EXTENSIONS - even if running in ANS85 "mode".  One of my favorite
examples of "odd dialect combinations" when I worked for MF was showing a
TRANSFORM statement nested within an EVALUATE statement <G>)

As for that "yucky" 01-level COPY syntax that works with LANGLVL(1) - I
shudder to think how many CICS programs STILL use it.  (From what I hear,
worse under VSE than OS/390 - but certainly STILL present there.)

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

Quote:
> How many shops had some ANSI 68 CoBOL programs until Y2K got funding to
> convert them?

> I strongly suspect there are some large shops which had all of their
> programs using a current compiler before the Y2K conversions - but this is
> only a suspicion, they were outside of my experience as a contractor.

> It is far more common to see the following code (and have programmers
> understand it):

> MOVE "GARBAGE" TO MY-FIELD
>       PERFORM MY-PARAGRAPH
>            UNTIL NEW-FIELD = MY-FIELD

> than
> PERFORM MY-PARAGRAPH WITH TEST AFTER
>        UNTIL NEW-FIELD = MY-FIELD

> Enterprise shops move slowly.   We get a new CoBOL standard - how long
will
> it take before half of its features become commonly used in most mainframe
> shops?  (Don't even count OO features here - I don't know if they will
EVER
> be used in mainframe shops).



Sat, 07 Feb 2004 04:52:11 GMT  
 IBM mainframe use of OO COBOL



Quote:
> Well, being a "devil's advocate" - and knowing that I will upset Jimmy and
> Pete (at least),

I am never upset by lively debate or opposing viewpoints. Besides, I really
don't care. As far as I'm concerned the evidence is in and I have stated my
position.

It doesn't matter to me whether people believe me or not.

Can you afford to take the risk that I may be right? I am strongly advising
COBOL programmers to do something about upgrading their skill sets. Even if
my assessment is wrong, (and in some ways I hope it is...) no harm can be
done.

Quote:
> Several people said this same thing about 1994 when there was still hope
> that the new COBOL Standard would be out by '97, i.e. that "COBOL would be
> dead in 10 years - if there wasn't a STANDARD for OO COBOL by then.

That is NOT what I am saying, and is NOT what I have ever said. It is a
cheap shot to equate what I DID say with the above standard. Seems all you
saw in my post were the words "10 years", Bill.

I do not now, and have never believed that the "life" of COBOL is  totally
dependent on the Standard.

I DO believe that the apparent impossibility to produce a Standard that is
meaningful to anybody, has certainly NOT helped the image or implementation
of COBOL, but this has been overtaken by events and is now irrelevant.

Object Orientation is a completely different matter.

COBOL (in my assessment) CANNOT live in splendid isolation from the rest of
the computing environment. The days when it was "the only game in town" are
over. Modern environments require a multitude of tools and COBOL is just one
of them.  UNLESS it can play with the others on their own ground, it WILL
fade into obscurity. OO COBOL is the only way I can see to achieve this.

Quote:
> Well we
> are now MUCH closer to 2004 than we are to 1994 - and we still don't have
a
> STANDARD definition of OO COBOL.  (Well, actually, I think that the FCD is
> pretty much set in concrete now - but there are ZERO implementations of
its
> complete OO definition).  Some how, COBOL is still not dead - and the
place
> where it is STILL most used (mainframes) is NOT clamoring for OO support.

That's no cause for smugness, Bill. It should be cause for alarm. Yes, the
mainframe sites remain as bastions of "fortress COBOL", resistant to change
and determined to continue as they always have. However, with the technology
which is set to emerge over the next few years they will HAVE to integrate
the mainframe with the rest of the Enterprise, or relegate it to a large
Batch processor.

More and more forward thinking organisations are seeing their mainframes as
fast, reliable, Web Servers. Standard COBOL does not lend itself easily to
this. OO COBOL and component engineering does.

Quote:
> It is my best guess (given the VERY slow adoption of '85 Standard coding
> techniques in IBM mainframe COBOL shops - and possibly OTHER mainframe
> environments),

(Has it occurred to you that this "slow adoption" could be because training
in COBOL '85 may be perceived as pouring good money after bad...? Where
training budgets are under pressure, people will want the best bang they can
get for their buck. Training keen young people into a 40 year old technology
MAY not be attractive, especially when the demands of the Enterprise are for
Network integration and Web enablement.)

Quote:
> that COBOL will continue to be used (both for maintenance and
> development) in LARGE enterprise (mainframe) environments for years and
> years to come.  Furthermore, that MOST of the programs that will be
> DEVELOPED (much less maintained) in these environments will be such that
> they could ALMOST be compiled by an ANSI '74 compiler (at least a compiler
> with a FEW extensions).

I don't disagree with this. Some sites will keep doing what they have always
done for as long as they can get away with it ("years and years"). However,
market pressures will finally drive the businesses they "serve" to work
"smarter" and the last bastions will gradually crumble. Long before that,
anybody who wants to make computer programming a career will have acquired
the necessary skills and languages to do so. Knowing '85 COBOL will not
carry a heavy price tag in the skills market.

Quote:
> Now when it comes to moving out of "entrenched" environments, I totally
> agree that not having OO support will harm the "growth" of COBOL.
However,
> it is my perception (and of course I could be wrong <G>) that if COBOL did
> everything but write itself and pay each programmer $1,000 per line of
> code - it still has little or no chance of GAINING "market share" in the
> programming environments in which it is not fully entrenched today.

So we agree OO is necessary for COBOL to progress...<G> And your last
sentence is certainly true if we DON'T do anything to enhance the language
and the skills of the people using it.

Quote:
> The
> "reputation" is just too bad - and the language itself is just too "out of
> fashion" for it to gain in totally new environments - regardless of what
> features are added or modified.

Nope. That is entirely a matter of opinion. What exactly are we talking
about when we say "fashion" in this particular context?

Languages like Java and C++ are not just "fashionable" because that's what
University Lecturers want to teach. They are low cost, efficient, EFFECTIVE
languages when used for the purposes for which they are intended.

So is COBOL (well...maybe not low cost <G>). The OO Extension to COBOL
allows it to provide the same programming advantages the other languages
provide, but in the area where it reigns supreme (data manipulation and
commercial problem solving). But, instead of racing to embrace it, the
attitude is:"Well, OO COBOL is pretty hard to take and I've always done OK
with standard COBOL...why bother?".

I have tried in my posts to this forum to get people to "wake up" and expand
their skill sets before it is too late. Posts like yours, Bill, simply
reinforce the "Hey, it's OK, we're here for years..." attitude which most
existing COBOL programmers WANT to believe. (This is not a criticism; I know
you honestly believe what you wrote, just as I do.)

Like I said at the start, I don't personally care whether they respond or
not. As long as I rang the bell and did my best...

But I can tell you if I was a career COBOL programmer right now, the thought
of spending the next "years and years" writing COBOL '85 on a mainframe,
wading through REXX, JCL, TSO, CICS  and all the ancillary stuff that is
required  before I can even BEGIN to exercise my COBOL skill, being paid the
minimum possible because I haven't got the new technology skills, and
sitting at the bottom of the heap as far as programmers go because I write
COBOL and don't understand Object Orientation and the reuse of encapsulated
common Objects... Watching the "other" programmers dealing with the new
technology, going on the courses, getting all the training, producing
exciting new services and facilities to the User base...

Well, I'd rather drive a truck...

Pete.

-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----



Sat, 07 Feb 2004 10:00:28 GMT  
 IBM mainframe use of OO COBOL
OK. I had another look at it...<G>

My 10 year comment applies to NON-mainframe COBOL.

I accept that mainframe COBOL will be with us for "years and years" as Bill,
puts it...

Pete.


Quote:



> > Whether we like it or not, the future of computer programming lies in
> > Object
> > Orientation. If COBOL misses this boat it will be dead in the water
within
> > 10 years.

> Question to all:

> Is Mr. Dashwood correct in his assessment?  Is he exaggerating?   What do
> you think?

-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----


Sat, 07 Feb 2004 10:27:23 GMT  
 IBM mainframe use of OO COBOL



Quote:
> OO - different ball game. Given a mainframer had an OO compiler, might he
not
> just find it a little intriguing that you can write just ONE program that
> accesses any ISAM file, (and that would negate all the sub-programming,
nesting
> or calling that was in the thread that started this topic).. Similarly,
but this
> is not parallel to Pete's components, your can write ONE program
accessible by
> all Dialogs. It's impossible to illustrate either of these concepts in a
few
> sentences.

This is the nub of it, Jimmy. "It is impossible to illustrate... in a few
sentences".

There is no glib way to show OO Concepts or actual programming, and
adequately demonstrate the power of this paradigm.

Java gets close, and I still see examples of OO technique in Java which
really blow me away, expressed in 30 lines of code... Try translating it to
OO COBOL and yes, it works and is good, but it is hundreds of lines and not
immediately obvious.

I found a really good Java introductory with simple elegant examples and
decided to translate the whole lot to OO COBOL as a primer for students. I
gave up. It just wasn't the same. (I might try again after I rethink the
whole process.. I think the problem here was not with OO COBOL but with
me...)

Having said that, I think the OO COBOL examples in Will's book are
outstanding and do give some insight into how it works.

But, as in your statement above, you do something really cool with OO COBOL
and realise what power it has. Then you try to explain it to someone with a
straight COBOL background. And you can't. Well, not in a simple succinct
"few sentences".

There is apparently no substitute for "biting the bullet" and learning the
concepts.

Quote:
> All we can hope is that the mainframe vendors on J4 take the topic
seriously and
> DO produce mainframe OO compilers. Then people can experiment - OO in
COBOL will
> either fall flat on its face or take off.

I hope vendors, whether they are on J4 or not, will produce OO
implementations.

Quote:
> I also agree with you on 'market share'. While still healthy in the
States -
> COBOL tuition elsewhere is diminishing. Those kids we lost to C, C++,
Java,
> Visual Basic or whatever - we are NEVER going to get them back.

Be careful about "Never"...I have recently had some enquiries from VB people
who want to learn COBOL <G>.

Pete.

-----=  Posted via Newsfeeds.Com, Uncensored Usenet News  =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
 Check out our new Unlimited Server. No Download or Time Limits!
-----==  Over 80,000 Newsgroups - 19 Different Servers!  ==-----



Sat, 07 Feb 2004 10:56:40 GMT  
 IBM mainframe use of OO COBOL


Quote:

> > I also agree with you on 'market share'. While still healthy in the
> States -
> > COBOL tuition elsewhere is diminishing. Those kids we lost to C, C++,
> Java,
> > Visual Basic or whatever - we are NEVER going to get them back.

> Be careful about "Never"...I have recently had some enquiries from VB people
> who want to learn COBOL <G>.

> Pete.

Well that at least that was heartening news. I was thinking along the lines of
the young 'kiddos' off to tech school where the instructor has deliberately
forgotten how to spell COBOL. In their wide-eyed innocence they accept his
dictum that Language X is the product du jour.

Your 'tentative' converts from VB - experienced hands, or are they 'beginners' ?

Jimmy



Sat, 07 Feb 2004 11:54:22 GMT  
 
 [ 84 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 

1. Any sites using OO (particularly OO COBOL) development on the mainframe

2. Any sites using OO (particularly OO) development on the mainframe

3. IBM Mainframe to IBM Unix Cobol conversion?

4. tandem COBOL to IBM Mainframe MVS COBOL Conversion

5. What's new *and* interesting for IBM mainframe COBOL programmers - in the next COBOL Standard

6. IBM Mainframe COBOL vs. AS/400 COBOL

7. OO Cobol Books for the Mainframe

8. IBM Mainframe - COBOL,IMS/DB/DC,CICS,DB2 immediate openings

9. VSAM Programming in COBOL vs Assembler on IBM Mainframe

10. IBM Mainframe COBOL "people"

11. Environmental Variables in LE COBOL on an IBM mainframe

12. IBM mainframes (was: COBOL needs your help.

 

 
Powered by phpBB® Forum Software