Cobol - OO past and future was Re: How proprietary is the "COBOL file system"

Author

OO past and future was Re: How proprietary is the "COBOL file system"

Clark F Morris

2007-10-07, 9:55 pm

On Thu, 4 Oct 2007 12:23:58 +1300, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:

>
>
>"Howard Brazee" <howard@brazee.net> wrote in message
> news:bsc7g316u2gfrjltfjr24jodq99hcjckbe@
4ax.com...
>
>Not sure if you are asking me or Bill, Howard.
>
>In case it's me, here's what I think: :-)
>
>1. Very little OO COBOL is being used.
>
>2. No, the growth is not significant enough to impact the demise of COBOL.
>
>This, to me, is a tragedy. Vendors (Fujitsu and MicroFocus, and I believe
>there are some others...even IBM) went to great trouble to include OO
>support into their products. (Why do you suppose they did that?) It was an
>amazing feat of software engineering. Nobody cared. Smugness, arrogance,
>inertia, and ignorance on the part of the user community decided it was not
>needed.

I saw the IBM version at the time and not only did I not understand it
after reading the manual, I didn't see where it could be used.
Websphere wasn't out at the time. There was no repository. There
were no class browsers and all of the other tools that you mention
that C# has. There was no description of how we could access objects
regardless of language. The needed infrastructure wasn't there.
Initially, OO solved problems for C/C++ that didn't need to be solved
for COBOL and OO in that environment gradually grew to the point where
it started solving problems that also needed to be able to be solved
in the COBOL environment.
>
>Now, there are some in the COBOL community who are starting to realise that
>maybe there could be something in this alternative paradigm. Too little too
>late.
>
>It isn't just about OO, it is about different ways of developing systems.
>Component based systems, built around encapsulated objects, require less
>maintenance, less regression testing, are more flexible, get developed
>faster using different development methodologies that are iterative and
>interactive (evolutionary), and get many times more reuse than thousands of
>lines of procedural code. It's like building a house with prefabricated
>steel, glass and concrete, as opposed to using bricks...

Is the Windows Operating System OO (as opposed to providing OO
facilities)? If so how would you compare the reliability to other
operating systems? Are any of the major packages, SAP, Oracle
business applications, etc. OO and if so are they fully OO? Oracle
Financials at one point in the 1990's was generating COBOL. Peoplesoft
was in COBOL.
>
>But apart from that, there is growing disillusionment in industry with the
>spiralling cost of procedural code. It is labour intensive and many (I
>personally know of five, and I have been out of circulation for a few years
>now; I will be interested to see if this trend is reflected in Europe next
>year) companies are finding that the costs of in-house development on the
>traditional mainframe cannot be warranted. Using Java shows major savings
>over using COBOL, but, my personal opinion is that many companies will move
>off Java too in the (near?) future and decide their core processing can be
>done by a package, and they will retain minimal staff to simply keep the
>network running and provide a helpdesk for departments who will use their
>own spreadsheets and databases, built with standard tools. These "local
>nodes" will be networked, and required to share critical data with the core
>package. The need for IT "specialists" will gradually be removed or
>outsourced. Software will get smarter and the end users will be more
>computer literate. The rising generation don't know what it is to NOT have a
>computer and the Internet is as familiar to them as their cell phones and
>texting.

Procedural code is hideously expensive in many ways. Testing and
verification is even more expensive. I am not certain that ongoing OO
systems (ones that have been in production for at least three years
and gone through at least one major upgrade) are more reliable than
conventional ones. They should be if the testing and regression
testing is done and that should be easier from what I read from both
you and Judson. I don't yet have any warm fuzzies based on your (Pete
Dashwood) comments about need for regression testing for changes. I
know that I shudder when I think of table changes in something like
SAP (or many home grown systems and other packages including some that
have been in shops where I was). The level of simulation and testing
of what can be far reaching changes is less than desirable all too
often.
>
>Eventually, web services will inherit the Earth and any function you need
>will be available as a service from a server somewhere. The software
>industry will go on for the foreseeable future, but in-house development
>won't.

From a security point of view, I am skeptical. I don't know that I
want to trust key systems to vendors with whom my organization doesn't
have a close relation and who aren't big enough to be sued
successfully (i.e. the damages can be collected).
>
>Pete.

Pete Dashwood

2007-10-08, 3:55 am

"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:bl2jg31fer7d3u2397sv5vj1eeodcip3oj@
4ax.com...
> On Thu, 4 Oct 2007 12:23:58 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I saw the IBM version at the time and not only did I not understand it
> after reading the manual, I didn't see where it could be used.
> Websphere wasn't out at the time. There was no repository. There
> were no class browsers and all of the other tools that you mention
> that C# has. There was no description of how we could access objects
> regardless of language. The needed infrastructure wasn't there.
> Initially, OO solved problems for C/C++ that didn't need to be solved
> for COBOL and OO in that environment gradually grew to the point where
> it started solving problems that also needed to be able to be solved
> in the COBOL environment.

Thank you for writing that, Clark. It is the first time I have seen anyone
make an explanation of how it was for THEM. And it is honest and succinct.

I stand corrected. Not EVERYBODY was smug, arrogant, inertial or ignorant...
:-) (And I can totally relate to how simply reading about OO COBOL shed no
light at all, because I had the same problem.) In retrospect, OO COBOL could
have been "sold" better...

>
> Is the Windows Operating System OO (as opposed to providing OO
> facilities)? If so how would you compare the reliability to other
> operating systems? Are any of the major packages, SAP, Oracle
> business applications, etc. OO and if so are they fully OO? Oracle
> Financials at one point in the 1990's was generating COBOL. Peoplesoft
> was in COBOL.

Modern packages use OO inasmuch as they use components which are OO based. I
can't speak for the ones you quote but I would suggest that if their revenue
is not declining it is because they have kept up and are responsive. Windows
OS is certainly component based. An Object Browser reveals several thousand
useful components.

[color=darkred]
>
> Procedural code is hideously expensive in many ways. Testing and
> verification is even more expensive. I am not certain that ongoing OO
> systems (ones that have been in production for at least three years
> and gone through at least one major upgrade) are more reliable than
> conventional ones. They should be if the testing and regression
> testing is done and that should be easier from what I read from both
> you and Judson. I don't yet have any warm fuzzies based on your (Pete
> Dashwood) comments about need for regression testing for changes.

That simply reflects a lack of understanding of OO. (Not being critical or
accusatory, just a statement of fact.) Anyway, your warm fuzzies are
entirely your own affair and no concern of mine :-)

It isn't just about OO vs Procedural, it is a whole shift of paradigm.
Different ways of developing systems, interacting with users of those
systems, delivery, deployment, response to change, it is much bigger than
just programming.

Actually, I've given up persuading (or trying to) people about OO and
components. I'm not on commission and it's really no skin off my nose if
they can't or won't see there are better ways to do things, and many more
options than we had in the 1960s.

I have learned from experience that heated debates here, where I invested
much energy and time, simply stressed me out and then 3 or 5 years later
when it is blatantly obvious to everybody, the people who fiercely resisted
what I was proposing just turn around and do it anyway, because they are
pebbles and the landslide catches up with them. I saw it with RDB and I saw
it with OO. I advised people to learn Java and expand their COBOL skill sets
10 years ago and more here. I received scorn and sometimes venom. I did it
becauseI was genuinely concerned for peoples' jobs and careers, not for the
sake of winning arguments. ("This was the noblest Roman of them all..." :-))

Fortunately, just like everybody else, I too can learn from experience.
These days I really don't care whether people embrace OO or not. I'm not
going to waste time seriously arguing it. I don't mind if people genuinely
enquire, but if you already have a position and a closed mind, forget it...
:-)
[color=darkred]
> I
> know that I shudder when I think of table changes in something like
> SAP (or many home grown systems and other packages including some that
> have been in shops where I was). The level of simulation and testing
> of what can be far reaching changes is less than desirable all too
> often.
>
> From a security point of view, I am skeptical. I don't know that I
> want to trust key systems to vendors with whom my organization doesn't
> have a close relation and who aren't big enough to be sued
> successfully (i.e. the damages can be collected).
So you won't be using open source any time soon, then :-)?

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

Sponsored Links