Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO

From: Doug Scott (dwscott_at_ieee.org)
Date: 01/01/04 

Date: Thu, 01 Jan 2004 12:52:09 GMT

Peter,

> After some consideration I have reached the following conclusions:

We went through a similar line of reasoning ten years ago is determining the strategy for a large UK
financial. However, the conclusions differed:

> 1. SOME businesses will continue to use COBOL (I believe it will be mainly
> for Batch processing.).

As I've said, the tools industry has moved on, and I doubt that even OO COBOL will be able to provide a
resource-rich development environment which people like MS and Borland do.

Cobol does batch processing very well. C does it very poorly, so you might well be right there.

Batch processing may not continue to be done in Cobol, though. With the provision of large online
databases, the only uses of batch processing will be for analytical purposes, and something like SAS is
better suited to that.

> Distributed systems through Client Server and the Corporate
> Intranet will remove the need for Report runs off a central mainframe.

Well, we were already there twenty years ago. And a change in management /centralised/ everything again
(there's nowt so queer as folk).

If you have to produce monthly statements, then by definition it's a batch run to print them. And if
you're doing that, the most efficient way to do bulk printing is to centralise it.

Finally, distributed systems are over-complex to manage and an incredible waste of users' time and money.
Who manages a computer better - an amateur user or a professional operator? How many operators do you need
to run a billion-dollar site? Compare that to the estimate of, say, an hour a day for 10,000 users.

> the role of "bespoke software generation"
> will decline to the point where it will simply involve plugging a few
> standard components from the Corporate component repository into standard
> desktop software.

I remember an engineer tell me back in 1964 that this was going to happen, except that he said it would be
hardware-based. It never arrived, but I'm willing to concede that the large ERP products are managing to
sell their message to senior management more and more. The trouble is that they require an awful lot of
tailoring because every company works differently, and there could be a reaction to the inordinate amount
of learning and twiddling to get a package into a useful state. I don't know - it could work, or there
could be a reaction saying "dammit, I paid for all that functionality I never needed, and never will
need."

But I don't think it will ever be a case of plugging in software to a base package. Businesses, even
within the same industry, are too different. I've seen these packages be adopted, and then quietly
abandoned to be replaced by in-house developed stuff.

> (OO, which COBOL seems to have missed the boat on, is one
> of the major facilitators of this capability.)

Well, XML is a better contender for interoperability, and it doesn't mandate OO.

> When another report is required, most Businesses are not
> going to accept that a COBOL programmer is required to write it.

You're really going back into the ark with that one. We haven't used programmers to prepare reports for
years - we use a report program generator which allows users to select fields from a data dictionary and
report on them, with the reports automatically formatted.

> Because of tradition, these
> sites will support COBOL, but as the pressure comes on from cheaper
> alternatives, they will slowly disappear (or transmute into something other
> than what they are today...)

I don't know what you mean by "cheaper alternatives", but I will agree that Cobol is fighting a rearguard
action which it could well lose, regardless of its merits.

> (d) Many CEOs are wanting to get back to the Business they are in, and
> resent the huge budgets we have seen for in-house IT departments. If your
> business is Insurance (for instance...) you may resent spending 15% of your
> turnover on maintaining in house IT facilities

Wow. 15% of their turnover! The IT department deserved to be sacked. Most UK insurance companies spend
between 3% and 7% of turnover on IT - and 7% was a waste. 

---
Doug
dwscott@ieee.org

Relevant Pages

  • Re: (not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL
    ... COBOL will be able to provide a ... > Batch processing may not continue to be done in Cobol, ... >> Intranet will remove the need for Report runs off a central mainframe. ... the Networks of twenty years ago were ...
    (comp.lang.cobol)
  • Re: Telnet printing problem
    ... Application is in COBOL. ... to print a report for a specific batch of transactions. ... Do you know of any way to get around this (short of actually exiting ...
    (comp.sys.ibm.sys3x.misc)
  • Telnet printing problem
    ... Application is in COBOL. ... to print a report for a specific batch of transactions. ... Do you know of any way to get around this (short of actually exiting ...
    (comp.sys.ibm.sys3x.misc)
  • Re: COBOL Compiler for Windows
    ... Before we had online processing, batch processing was the only ... to "complete" transaction processing in batch diminished. ... suppose a certain "monthly report" was viewed as a report ... however the cheques are encoded you are still left with a ...
    (comp.lang.cobol)
  • Re: COBOL Compiler for Windows
    ... flavour of "batch processing" I WAS addressing. ... to "complete" transaction processing in batch diminished. ... requisite dates, do some figuring on each transaction, and place report ... however the cheques are encoded you are still left with a ...
    (comp.lang.cobol)