what is the status of oo cobol?

  • Permalink
  • submit to reddit
  • Email
  • Follow


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?
0
Reply huitheng.oeij (1) 7/31/2003 1:38:05 PM

See related articles to this posting


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 status of OO cobol in Europe, US and the rest of the
> world?

It is available in non-ratified versions (pre-releases that do not conform
to the ANSI Standard) from MicroFocus and Fujitsu (and possibly others that
I haven't checked out). IBM appear to have dropped support for it (Bill, can
you tell us what their current thinking is?).

The latest COBOL standard includes OO. Nobody has actually implemented it
yet. (Personally, I couldn't care less about the Standard and have been
using OO for around 3 years, but not everybody will share my view on this.)

> Are there any big companies using it and if so, where?

I know of none. There were some projects on a mainframe site in Germany some
time ago. No idea what happened to them.

> What is
> the experience with using OO cobol?

My personal experience has been excellent. I use the Fujitsu implementation
and find it superb. They also have a "Quick Build" GUI tool that uses OO
"under the covers" (PowerCOBOL). I have built several  live Windows
applications with this and it is excellent.

>Can cobol really be combined with
> an OO approach?

Yes, but it is a "bolt on" to COBOL. (Nevertheless, it is a beautiful job of
software engineering). COBOL can certainly be combined with OO concepts. It
makes sense to write Business Methods in COBOL. All of the things you would
expect (inheritance, encapsulation, polymorphism, interfacing, overloading,
etc.) can be implemented for COBOL classes just as any other classes.

>Why would someone choose to use OO cobol and why would
> they choose not to use it?

I chose to use it  mainly because I am committed to component based
development. I realised some years ago that components lend themselves to
more radical development approaches. Having tried several pilot projects it
became apparent that the ability to provide  reusable encapsulated
functionality to the business, designed and developed in conjunction with
the business, using interaction and iteration rather than the traditional
"waterfall", is a winning strategy for system development.

While you COULD implement this same strategy without OO, it is better if you
use OO.

I need OO to write components. Business components are best written in
COBOL. I happen to believe in a "building block" approach to system
development and OO supports this better than traditional development
methodologies. I could (and do...) use Java but there is no substitute for
COBOL when it comes to business data processing. For me, one of the major
benefits is that my COBOL components can be combined with components written
in other languages (the source is irrelevant), maybe provided by third
parties, and they can all play nicely together in the same playground. (And
that playground can be the Windows desktop or the Internet... Web Enablement
is a fringe benefit of using the component approach. Components plug easily
into Web Pages) With the advent of .NET more people are likely to realise
the advantages of this approach.

I would not use OO for Batch Processing.

> Are there any inherent advantages or
> disadvantages to OO cobol?

The advantages are the same as for any OO Language. (the traditional
strengths of COBOL for processing now become available in an OO
environment.)

It is interesting that one of the great strengths of COBOL (ease of
maintenance) is no longer relevant in the OO environment; this is because OO
Methods tend to be small and encapsulated, and components are not maintained
like traditional "integrated" COBOL programs that do "everything".

The disadvantages are that your COBOL Classes can't be called easily from
other languages (they can if you wrap them as components, and that is what I
do...), and the coding required is more than for Java or C++. (well, it IS
COBOL...you expect to write a bit more...<G>)

>Is there a future for OO cobol?

In a word, "No."

But then, the future is often what you make it.

Object Oriented programming is probably the most significant breakthrough in
the art of programming that has happened in the last 30 years (since
Djykstra's famous paper which formed the foundation for Structured
Programming). Most of the Programming community realises this, but COBOL
people (in general) don't.

(Some do, but feel it would be impossible to introduce anything OO COBOL on
the sites where they work. (sadly, they are right.) ).

I am at a loss to explain why OO has been so fiercely resisted (although
some recent discussions here in CLC have shed some light on it)

Adopting an OO approach (irrespective of OO COBOL) requires severe change in
the whole approach to system development. Young companies with no entrenched
"fortress" can make this adjustment much more easily than companies that
have been processing with COBOL for 20 years or more.

OO COBOL, in my opinion, is the best thing that has ever happened to COBOL
(and I have been writing COBOL since 1967).

The vendors have realised that if COBOL is to survive in the modern
marketplace it must be able to join the others in the playground.

Unfortunately, the parents won't give their permission and COBOL is confined
to the back yard, forlornly kicking the ball at the fence as it has always
done, while the others are racing up and down playing soccer on the field
next door.

At the moment the gate is barred. Whether it will stay that way remains to
be seen.

Some of us sneak out through a hole in the fence and play on the big field,
but we are a very small minority and certainly not enough to make our own
team and challenge the rest to a proper game.

Pete.


0
Reply dashwood1 (2140) 7/31/2003 11:11:50 PM

Sorry - yes, that was supposed to be "NOW focused on Java interoperability".

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"Harley" <dennis.harleyNoSpam@worldnet.att.net> wrote in message
news:tPEWa.84064$0v4.5608773@bgtnsc04-news.ops.worldnet.att.net...
> Is that a typo: "NOT focused on "Java interoperability" or "NOW focused on
> "Java interoperability"".
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:GQDWa.1974$kP6.1415@newsread2.news.atl.earthlink.net...
> | IBM dropped support for their previous "SOM-based" OO approach (for
> | mainframe OO COBOL) and is not focused on "Java interoperability".  They
> | certainly have NOT indicated when/if they will ever provide a 2002 ISO
> | conforming OO implementation, but as far as I know, only Micro Focus has
> | done this.  (Siemens/Fujitsu MAY have  or may be on the way to doing
so).
> |
> | --
> | Bill Klein
> |  wmklein <at> ix.netcom.com
> | "Harley" <dennis.harleyNoSpam@worldnet.att.net> wrote in message
> | news:BsDWa.83971$0v4.5600341@bgtnsc04-news.ops.worldnet.att.net...
> | >
> | > "Peter E.C. Dashwood" <dashwood@enternet.co.nz> wrote in message
> | > news:3f29a7cd_7@news.athenanews.com...
> | > | 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 status of OO cobol in Europe, US and the rest of the
> | > | > world?
> | > |
> | > | It is available in non-ratified versions (pre-releases that do not
> | conform
> | > | to the ANSI Standard) from MicroFocus and Fujitsu (and possibly
others
> | > that
> | > | I haven't checked out). IBM appear to have dropped support for it
> (Bill,
> | > can
> | > | you tell us what their current thinking is?).
> | >
> | > <<snip>>
> | >
> | > I hope that you're wrong about IBM dropping support.
> | >
> | > I looked at what I think is the latest compiler:
> | >
> | > Enterprise COBOL for z/OS and OS/390
> | > Language Reference
> | > Version 3 Release 2
> | >
> | > It seems to still have OO.
> | >
> | > FROM THE MANUAL
> | >
> | > COBOL class definition structure
> | > Enterprise COBOL provides object-oriented syntax to facilitate
> | > interoperation of
> | > COBOL and Java programs.
> | > You can use Enterprise COBOL object-oriented syntax to:
> | >  Define classes, with methods and data implemented in COBOL.
> | >  Create instances of Java or COBOL classes.
> | >  Invoke methods on Java or COBOL objects.
> | >  Write classes that inherit from Java classes or from other COBOL
> | classes.
> | >  Define and invoke overloaded methods.
> | > Basic Java-oriented object capabilities are accessed directly through
> | COBOL
> | > language. Additional capabilities are available to the COBOL
programmer
> by
> | > calling services through the Java Native Interface (JNI), as described
> in
> | > the
> | > Enterprise COBOL Programming Guide.
> | >
> | > METHOD-ID paragraph
> | > The METHOD-ID paragraph specifies the name by which a method is known
> and
> | > assigns selected attributes to that method. The METHOD-ID paragraph is
> | > required
> | > and must be the first paragraph in a method Identification Division.
> | > method-name-1
> | > An alphanumeric literal or national literal that contains the name of
> the
> | > method. The name must conform to the rules of formation for a Java
> method
> | > name. Method names are used directly, without translation. The method
> | > name is processed in a case-sensitive manner.
> | >
> | >
> |
> |
>
>


0
Reply wmklein (2605) 8/2/2003 2:07:12 AM
comp.lang.cobol 4195 articles. 3 followers. Post

2 Replies
236 Views

Similar Articles

[PageSpeed] 2


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

OO COBOL
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 c...

Status of OO in Forth?
I do NOT want to start a discussion about OO implementation variants in Forth. I am just curious whether there is a standardization proposal "under way" or had it been abandoned completely? And at least IMO it is closely connected to the libraries issue that had been discussed some years ago. Andreas "A. K." <akk@nospam.org> writes: >I am just curious whether there is a standardization proposal "under >way" No. > or had it been abandoned completely? No. There are some people who want a standard OO system for Forth. - anton -- M. Anton E...

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

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

File status in COBOL/400
hi everybody. i want to know what is the file status in cobol/400. what are the different values returned by file status other than the following, i.e. if file exist(00) or doesn't exist(35)? if there are any other status then what they denote and how they can be used? It is all documented in the InfoCenter: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp On Feb 20, 11:37 pm, "Arkaprav" <arkap...@gmail.com> wrote: > hi everybody. > i want to know what is the file status in cobol/400. what are the > different values returned by file status other ...

IBM and COBOL File Status = 39
To IBM-MAIN & comp.lang.cobol (and CC to others) When IBM first came out with their '85 Standard compiler (VS COBOL II, V3.0) all those YEARS ago, one of the major migration inhibitors was "file status = 39" for "fixed file attribute conflicts". As I recall it, it was one of the major reasons that SOME shops stayed with the CMPR2 compiler option. By the time that this "problem" was identified in IBM's implementation, ANSI/ISO had already "clarified" the requirement for FS=39 to state that it was IMPLEMENTOR DEFINED which attributes conflic...

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

Program Status Data Structure And COBOL
Is there something similar to the Program Status Data Structure in COBOL? On 10 Dec 2003 12:33:19 -0800, thad_rizzi@hotmail.com (Thad Rizzi) wrote: >Is there something similar to the Program Status Data Structure in COBOL? Thad What exactly are you trying to determine? I have a couple of copybooks that I use to check the file i-o and workstation attributes. You can also search the iSeriesNetwork Cobol forum (I hope this is right): http://www.iseriesnetwork.com/Forums/Index.cfm?CFApp=19 Terry Thad Rizzi wrote: > Is there something similar to the Program Status Data Structure ...

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

COBOL file status 9P after DDS change
We had a strange problem this morning resulting from a change that went in last night. We have a CL program that performs a STRCMTCTL, then calls COBOL program 1 which puts file A under Commit Control, then COBOL program 1 calls COBOL program 2 which also uses file A but not under Commit Control, when COBOL program 2 finishes it returns control to COBOL program 1, when COBOL program 1 finishes it returns control to the CL program, which performs an ENDCMTCTL. This all works fine. Last night, we amended the layout of file A by adding some extra fields to the end. We also added a new logical...

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

COBOL and message IWZ200S with file status 96
Hi! I'm receiving a message IWZ200Z with file status 96 - and I cannot find a description of this file status. Can anybody help me? Thanks Rolf In article <0c4c460b9fec524ca066d44971dcf48e@localhost.talkaboutprogramming.com>, rolf_cologne <rolf-peter_kollbach@msg-systems.com> wrote: >Hi! > >I'm receiving a message IWZ200Z with file status 96 - and I cannot find a >description of this file status. Platform/compiler? DD The platform is AIX with the IBM COBOL compiler. Regards, Rolf In article <42d70950a331579180cdea8da1c06eff@localhost.talkabout...

Using CKERROR to decode COBOL file status
Tracy Pierce wrote: >yep, as long as CKERROR is properly documented (that's from Cobol68, > right?), ksam-status "9{" really does equate to mpe error 123 - notice > that { is ascii(123). CKERROR was one of the "intrinsics" released with CM KSAM back before HP implemented COBOL 74 and the "Indexed I-O" module. The "CK" family of procedures have been retained for compatibility, but their use is discouraged now that HP COBOL has the ability to access KSAM files directly. Yes, CKERROR can be used to decode the two-byte COBOL...

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

Re: Using CKERROR to decode COBOL file status
Why not do the following in your Cobol85 programs: Add a 'Status Is CFE-STATUS' to all SELECT's [CFE-STATUS is an X(2)]. After every Close, Delete, Open, Read, ReWrite, Start and Write check CFE-STATUS. If it is not "00" then invoke a macro. Macro checks to see if CFE-STATUS[1:1] =3D "9". If TRUE it calls CKERROR and then FERRMSG to return the actual file system error message. Otherwise it is uses the whole of CFE-STATUS to select a message from the list documented in the Cobol II/iX Reference Manual. Have been using this method for more years th...

(OO) Collection Classes Draft Technical Report
I have previously told this group about the status of the Collection Classes DTR. In particular, I have indicated that Micro Focus (and I) oppose further processing of this document. The Draft DTR can be viewed at: http://www.cobolstandard.info/j4/files/07-0048.pdf There is currently an international ballot being processed. I can't tell each of you when your national standard's body will be submitting their ballot, but in the US, the J4-tag (US domiciled members of J4) are currently conducting a letter ballot on what the US position should be. The responses is scheduled to ...