From Newsgroup: comp.lang.cobol
On 14/10/2018 1:39 PM, Clark F Morris wrote:
I never saw the need for Object Orientated code in the environment I
was working in - IBM 360/370/390 on MVS in batch and CICS. This was
because the needs OO was designed for were already addressed by other mechanisms and the infrastructure was not available at the time to
make it worth while to change. It also would have required a major management commitment. This was probably also true of the Unisys environments and any other classic mainframes that survived.
This is very fair comment, Clark. Sites who had no intention of moving
to a Networked environment had no incentive to learn about OO,
particularly because, in a centralized mainframe environment, doing
mostly batch processing, everything works pretty well and there is
little need to rock the boat.
You may think that a mainframe running CICS is a lot like a Network with multiple client/servers, or at least is doing the same job. But such is
not the case... (CICS is just a parasite and isn't even in the same
league as mainframe TP monitors like TaskMaster or Shadow or even
IMS/DC... so the remainder of this post excludes CICS.)
OO
probably is better once the environment is there and in one sense
probably was needed more by C/C++ than it was for COBOL.
With the benefit of many years hindsight, I can agree that OO COBOL was
not essential for mainframe COBOL processing. Probably the main reason
it was important to ME was because I moved off mainframes (but not COBOL
at that point) and the "environment" as you say, was different.
As I grew into the environment and OO it just made sense to discard OO
COBOL and use a language like C# which was designed for that.
I have given a lot of thought to why I consider OO so important (at
least in a Networked environment) and my conclusions are explained at:
https://primacomputing.co.nz/PRIMAMetro/objectsAndLayers.aspx
On the
UNIX/LINUX/WINDOWS systems when OO penetrated it probably was a
different story for COBOL. Also there were probably no conversion
tools in the early days of OO COBOL to help get systems from old
paradigm to OO so a massive effort would have been needed even to
ready a system to take advantage of OO.
Absolutely correct! Looking at the tools now available it is a much
different picture and I have spent the last 15 years working on such
tools. Today, we can move COBOL '85 into OO COBOL with a mouse click
and, during the same process we can design, build, and load an optimized relational database to replace the indexed files, generate a modern OO
Data Access Layer to manage the new RDB, and refactor all of the COBOL
IO verbs in the legacy COBOL that address the indexed files, to be
invokes of the DAL objects... None of this was available when OO COBOL
was first released, and doing it manually would be a huge task. (I did 2
of these migrations manually and the experience prompted me to write the
tools we now have...)
Another major difference in environments is that the IBM Mainframe and probably the other mainframe environments are more record oriented
than string and array oriented and natively support indexed files (the
z series COBOL support is a subset of the total VSAM capabilities). Assembler, PL1, IDCAMS, SORT and proprietary languages such as DYL280
(now Vision something or other) and Easytrieve all support VSAM - the
IBM sequential, indexed and relative record access method support.
I would call Easytrieve a utility rather than a Language, but it is
around 30 years since I last used it so it may have been enhanced :-).
COBOL on the UNIX/Windows platform has to interface with a package and proprietary indexed file system to have the same capability.
That's true, but both Fujitsu and Micro Focus provide excellent ISAM
support with their COBOL compilers.
In this
environment going directly to using the data base used by all other
packages and programs running on the system makes sense. Of course
that assumes that the business / government department / academic
institution was smart enough to standardize on one DBMS be it Oracle,
DB2, whatever the Microsoft SQL database manager is or the Linux DBMS.
The secret here is separation and layers. (See the web pages referenced above).
There is really no problem running 2 or 3 different RDBMS as far as the applications are concerned, PROVIDED you don't go and plug Embedded SQL
into the application code. Applications see an interface and all of the
data manipulation is done by the objects in the DAL layer. (THESE
objects can have SQL in them, although nowadays, we generate LINQ
because it is many times more efficient and the source language of these objects doesn't matter because they are never maintained.(They contain
code to do every possible action against an RDB, and they are generated
with a mouse click...)
See:
https://primacomputing.co.nz/PRIMAMetro/RDBandSQL.aspx
... for my thoughts about this.
COBOL at best was mediocre for report writing even with the REPORT
WRITER. DYL280 (now Vision something or another), Easytrieve and
other packages were and are far superior. Putting Screen handling in
COBOL may also have been a waste of time.
I remember when there was no other option (not even CICS... :-))
While waterfall probably was the least bad method of setting up the
early systems, it carried on longer than it should have because whole bureaucracies had grown up around it.
Amen to that! (
https://dzone.com/articles/cretaceous-cobol-can-spawn)
It was not the COBOL
programmers who were rigid so much as the management. Then management
has become interested in packages so COBOL is the backwater in many organizations. Now the trend is to put things in the cloud. The
common thread in all of these environments is that there is probably
not current documentation of what these various systems as customized
for the organization do and how.
That's certainly true, but it is no longer the powerful argument it once
was. Programmers today have much better tools and it is quite possible
to analyze undocumented code and determine what it does.
If we thought COBOL programs or
assembler could be inscrutable, where does that put systems that are
control table (or Windows registry) driven with mediocre front ends
for maintaining those tables. How many of the organizations test
changes to these tables before putting them in production? How well
are these tables which control some basic processing documented?
Clark Morris
An interesting post, Clark.
Thanks,
Pete
--
I used to write COBOL; now I can do anything...
--- Synchronet 3.20a-Linux NewsLink 1.114