From Newsgroup: comp.lang.cobol
On 25/11/2017 5:59 AM, Bill Gunshannon wrote:
On 11/24/2017 05:34 AM, pete dashwood wrote:
On 23/11/2017 3:38 AM, Bill Gunshannon wrote:
I see no point in arguing something that is already fait accompli (the
FACT that use of COBOL has diminished dramatically from what it was in
the 1970s, and this trend is continuing) and especially when no minds
will be changed, so I'll just make a few quick responses interspersed below.
Just thought I would throw out a few numbers to confuse the waters
a little more.
DFAS - Defense Finance and Accounting Service-a -- IBM COBOL
-a-a-a-a-a-a-a Payroll for 2,877,620 military and civilians.
IRS-a - Internal Revenue Service -- Unisys OS2200 COBOL
-a-a-a-a-a-a-a Income tax for all US Citizens, don't know how many resident >>> -a-a-a-a-a-a-a foreigners and of course, US Corporate taxes
GDIT - DOD EMR System -- IBM COBOL
-a-a-a-a-a-a-a Medical system for all DOD Medical and Dental Facilities. >>> -a-a-a-a-a-a-a 1,341,665 Military and their dependents.-a About 50 Hospitals,
-a-a-a-a-a-a-a 600 Medical Clinics, unspecified number of Dental Clinics. >>> -a-a-a-a-a-a-a DOD claims 9.6 million beneficiaries.
METLIFE - Insurance and Financials -- IBM COBOL
-a-a-a-a-a-a-a-a-a-a 37 on the Fortune 500 list.
Prudential - Insurance and Financials -- IBM COBOL
-a-a-a-a-a-a-a-a-a-a-a-a-a 48 on the Fortune 500 list.
These are just a few of the bigger ones I know of from personal
experience.
Some observations on the above:
1. There are around 230 countries in the world with a population
approaching 7.3 BILLION. (The largest number in the above is just
around .128% of that number; "large" is relative...)
Sorry if I sounded America-centric, but I did say "from personal
experience" and that kinda limits it to America.
2. The USA is ONE country with a population still under .37 billion.
And it is #3 in population according to the UN.-a Also, I'll bet it's
more computerized than even #2.
3. ALL of the examples above are from the USA. (I guess some people
who live there think it is the ONLY country in the world; I would not
diminish its importance, but it is obviously NOT the only country in
the world...And it is certainly not the only country in the world that
use (s/d) COBOL.)
See comment to #1 above.-a I can only speak of the US "from personal experience".
4. Many of the applications noted are of great importance (let's agree
"essential") for the well being of many people.
Agreed.
5. However, the argument being presented is that, because they are
currently running in COBOL, they must continue to do so, and that is
patentently not the case.
Three of the ones mentioned above have stated that they have no
intention of converting from COBOL to anything.-a (One publicly,
one semi-publicly and and one to me personally)
And you don't think that people (especially managers) sometimes say
things that are intended to "encourage the troops"?
It actually doesn't matter what they SAY; the pressures of the market
place, advances in technology, and changes in the way the World does
business will force change upon them. The question is not IF they will
move, but WHEN...
And to support the notion that converting from COBOL to anything is not
the simple task you seem to think it is, let me throw in the place I
worked at briefly in 2012.
As I have worked with COBOL conversions for the last 20 years, I KNOW it
is not simple, and I never said it was. "Difficulty in moving" is part
of the Business case that has to be evaluated and considered before
conversion can be undertaken.
The reason I left was because they claimed
the COBOL was going away and being as I went there to work on the COBOL
I saw no reason to remain.-a I have spoken with them within the past two months.-a The COBOL is still there and there are no longer any plans to eliminate the COBOL even though they have had no luck finding a COBOL programmer to fill my old position.-a Unless, you think these people all
have a reason to mislead others about their intentions.
Even a sincerely held belief can be wrong...
6. BECAUSE these applications are essential, and because it is getting
harder to find COBOL skills,
At least one has attacked this problem by training their own
potential replacements themselves through an internship program.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a and because the cost of running COBOL is
way more expensive than other,
What on earth would make you think that?-a Unless you assume that running COBOL requires some expensive hardware that no other language requires.
With the exception of GNU COBOL, there are no free COBOL compilers. The
cost of maintaining COBOL is higher than the cost of maintaining other languages (which are free...) because of the labour intensity of
maintaining millions of lines of code as opposed to maintaining
thousands of lines. (Or hundreds of lines in encapsulated Classes).
Hardware costs for a large mainframe and the infrastructure it requires
are still more than an equivalent Network, but this particular gap is
closing.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a possibly more modern, options, and
because even the way these traditional systems do business is under
pressure from a population with mobile technology and expectations
that don't gel well with overnight processing,
A lot of processing is still done "overnight" or even longer.-a But
instant results does not preclude the use of COBOL.-a I have written interactive web applications using COBOL.-a I am working on a demo
program now uses COBOL to take data from a web page, query a database,
return the information in a dynamically generated web page.-a Quit
thinking of COBOL in terms of the 1970's.-a COBOL, like other languages,
has moved forward.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a and because... but you can
add your own reasons if you look around, talk to some of the clients
of these systems,
Who do you mean by "clients"?-a The actual "clients" have no idea what
COBOL is or how the systems are actually used.-a Much like the clients
of any other company that uses computers.
-a-a-a-a-a-a-a >-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a and think about it... for
ALL of these reasons a
NON-COBOL solution becomes increasingly desirable.
Sorry, but I still fail to see why.-a Very little of the reasons you
state above hold water according to my personal observations.
I can do nothing about your state of vision, sorry.
(This is no fault of COBOL; the world changed and the IT devices and
paradigms along with it.
And COBOL changed as well.-a Oh wait, we're back to that paradigm thing.
If it ain;t OOP it's got to be wrong.-a And COBOL refused to drink the KoolAid.
The arguments leading to the paradigm change are covered at:
http://primacomputing.co.nz/PRIMAMetro/objectsandlayers.aspx (3 web pages)
It does not say that "If it ain't OOP, it's got to be wrong". It says
that if you are implementing for a Network, OOP will serve you better
than Procedural code, and it explains WHY this is so. (Perhaps it might
be fairer if you read my arguments before trying to push them to a
position they never held.)
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a Not only that, but the general population
became more "computer literate".
You would never prove that by me.
I don't have to. The rising generation is quite familiar with computer technology and what can be done. They use it every day and many of them
even write their own apps and scripts. (Even the ones that don't, still
have no trouble using phones, tablets, and laptops.) It is their
familiarity with technology that leads to a service expectation, and
that was the point of the example quoted below.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a I have never forgotten the CEO of a
very large company in the UK asking me "why our IBM mainframes were
not signing letters to customers".-a "Hell, Pete, my Kid can do that
with his Amiga..." He was right, and, within a few weeks, I made sure
that letters from the mainframe carried proper signatures, despite
fierce resistance from certain technical people who enjoyed saying
"No" to people wanting service.
That is a totally different problem not related to COBOL at all.
Really?
It was an entrenched COBOL IT shop that had never heard of AFP and when
it was explained to them, resisted fiercely. (I threatened to write it
myself and, once they were persuaded that a "manager" was capable of
actually doing it, they reluctantly applied themselves. To be fair, some
of the younger team members were excited at the prospect...) Nowadays,
all of this functionality has been removed from the mainframe and
branches print their own (signed) letters to customers. The use of AFP
bought time for the Local office system to be developed.
People will get want they want and if the service level they require is
not provided by their IT department, they will find other solutions.
-a I
often complained about the level of service from the datacenter at
the University who seemed to think users change to suit the computer
rather than the other way around.-a Oh yeah, and they didn't change
this attitude when the IBM Mainframe and COBOL left and Java came in.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a The point here is, that BEFORE his kid had an
Amiga, he just had to accept the line that it "couldn't be done")
Again, no relation to COBOL.
It was the COBOL people who were saying it couldn't be done...
I dealt with the same thing when
the University Print Shop wanted to take jobs directly from users
PC's and the Datacenter said that was impossible even while the
vendor of the Printing equipment insisted it was possible.-a I set
a system to do it in just over one day.-a No COBOL involved. :-)
It is and was more about political control from the Datacenter.
It IS difficult for some of the areas noted above to spread their risk
and move away from COBOL. But it is NOT impossible, and inroads are
being made into the "COBOL base" every year. (How do you eat an
elephant? ONE bite at a time...)
Wishful thinking.-a Can you name any places as large as the ones I
mentioned that you can provide any evidence of re-writting major
COBOL systems into some other language?
The Company I mentioned above had 8,000,000 customers and they no longer service them by mail from the mainframe using COBOL... It is a process
of gradual evolution driven by the factors already covered.
In the insignificant islands where I live, despite COBOL being the
"only game in town" during the last century, it is now extinct,
The smaller the system the easier to convert.
That is not necessarily true, but it holds as a general rule, yes.
-a Would be interesting
to learn what the real reason for the conversion was.-a I would bet
on politics rather than technical.
If you call the driving factors already covered, "politics", then, yes.
It still requires a technical "adjustment".
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a even the
Banks, Insurance companies, (not sure about DOD - they are sometimes a
littler slower than the rest...) have either moved or are in the last
phases of moving away from it.
Not here, sorry.
No, I am aware of the state of large corporate IT generally in the USA.
And I said "outside the USA" in my original post on this.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a The interesting thing about this (to
me, at least) is that none of the services have suffered as a result.
In fact, Banking, just to take one example, has never been easier or
offered more services, with seamless integration between personal
devices and the Bank's own system. The days of having to key Bank
Statements into accounting software, for small businesses are a thing
of the past, and for large businesses B2B is doing the work. It is
many years since I last wrote a cheque (or received one) or even took
a paper statement out of the mailbox.
And ,as I demonstrated above, we still use COBOL and I have all the
same services.-a I get no statements n the mail.-a I deposit checks
with my phone.-a Do all my business remotely.-a COBOL has nothing
to do with this.
So, what do you imagine IS providing all these services. You say "COBOL
has nothing to do with it". What then? Magic IT pixies? It is
alternatives to COBOL.
Obviously if you have only 4,000,000 people to practise on, you can
try stuff and get it right; it is much more frightening if .35 billion
are potentially affected. :-)
The IRS does much more than .35 billion.-a There are only two countries
in the world with larger populations according to the UN.-a In neither
case can I attest to what they use for computers or languages.
The point is that COBOL is NOT the ONLY solution,
No one ever said COBOL was the only solution but that isn't the problem.
The problem is people who continue to say it is never the solution and anything currently written in COBOL MUST be rewritten in something else.
It is a simple matter to ask them to support their case.
-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a and the fact that
it is still running in places where it makes sense for it to, does not
mean that the ONLY solution is to keep it so.
So, even if it is the best solution to a problem it should be replaced?
No, it might be the best CURRENT solution and, for that reason should
not be replaced immediately. But it would be foolish to expect this will ALWAYS be the case and the time should be used to plan a phased evolution.
Interesting logic, that.-a Even if it runs and meets the requirements of
the task it should be replaced?
While it might be a good solution in some areas of the business, it may
not be for all the other areas. On balance, it may need to be replaced.
All conversions should meet a business case, and if they don't, then
defer conversion until they do.
It is the pressure of what you choose to call "politics" that gets
factored into the Business case.
-a Definitely interesting logic.-a And some
people still wonder why the COBOL community rejected attempts to break
the language they were using.
Eventually the inexorable ROI and customer demands will force change.
Why on earth would that be?-a Change for the sake of change?
No, change because the pressures on the business have reached a point
where change is required in order to meet them.
-a If the
system already exists and works perfectly and has minimal maintenance requirements (because the system is, for the most part, stable) how
can the cost of re-writting it in some other language have a better ROI?
That is one contrived scenario which cannot justify change. (Give it a
few years in which the competition is developing newer, better
competitive edges while you remain "stable", then see whether change is required or not...)
Rewriting in another language is not an end in itself. Rather, it is
something that may be required as part of a strategy going into the
future. It can (and, in my opinion, should...) be phased, with
individual subsystems being converted in a manageable way and without pressure.
A problem associated with this is new technology having to do overnight
feeds to the legacy because they are running separate data repositories
or even flat files. We advocate converting the DATA before any attempt
to convert CODE. Both new technology AND legacy should be able to share
the SAME data repositories, and this is easily implemented with a Data
Access Layer available to both old and new code. There are tools
available to automate this refactoring of the existing COBOL code so it
uses the DAL, and new code will use DAL as a matter of course. The DAL
objects can also be generated with tools.
(See:
http://primacomputing.co.nz/PRIMAMetro/RDBandSQL.aspx (4 web pages
and a portal)
You can't buck the market.
It seems your market is just bent on wasting time, money and effort.
It isn't MY market...
-a-a I guess COBOL really is dead.....
Yep, pretty much.
Keep telling yourself that.-a I expect COBOL will still be around
long after my demise.
It really doesn't matter what you or I think, Bill.
Change is inevitable. (There can be no progress without it). And that
includes change to COBOL based IT systems.
Pete.
--
I used to write COBOL; now I can do anything...
SEEN-BY: 154/30 2320/100 0 1 227/0