Ada as a Successor to CoBOL

[larry@VLSI.JPL.NASA.GOV]

In the DoD world weapons are the primary focus, followed by C3I.  
So when the military talks about using Ada, those are the types 
of systems that get the most attention.

Yet there's another area that's at least as important: logistics.  
It's not very glamorous, calling up images of supply sergeants 
loafing in warehouses and truck drivers safely behind battle 
lines.  Yet without logistics military forces can survive only a 
few days--at least as effectives.  In high-consumption groups 
like fighter squadrons, survival may only be measured in hours.  
Another important area for similar reasons is personnel.

Computer programs supporting these two areas are important to DoD 
for another reason: sheer quantity--by several measures, includ-
ing frequency of use, CPU/IO time spent during each use, amount 
of source code, amount of programmers' time writing and maintain-
ing the programs, and cost of hardware.  Compared to embedded and 
real-time programs, I guesstimate we spend at least 1000% more on 
such "unglamorous" computer processing.  (Can someone refer me to 
estimates so I won't have to quess?)

But what language is used to write logistics and personnel pro-
grams?  Probably greater than 95% of it is in CoBOL.  More, they 
are usually run on IBM mainframes which (because of IBM's success 
in locking out competition) is not the most cost-effective hard-
ware.  And they are usually run under MVS, one of the most 
archaic and inefficent operating systems still widely used.

I think it's time DoD began to make the transition to Ada in such 
areas.  (Perhaps it already is but that I'm just not aware of it 
because I'm involved in "astronics" type software.)

In some ways this ought to be easier than using Ada for real-time 
embedded systems, which is not as simple as many of us first 
thought when we began trying to do that.  The relative simplicity 
of CoBOL and the typical CoBOL programs should lend itself to 
machine translation to Ada.  (Or am I being naive in this?  It's 
been almost 15 years since I worked my way through university 
writing CoBOL (and ForTran) programs.  What's been people's 
actual experiences in doing this?)

Also, both host and target computer can be the same, decreasing 
the need for special-purpose APSE tools like simulators, cross-
compilers, and debuggers supporting host-target hardware probes.  
Performance, size, and reliability requirements are less than for 
real-time, embedded computers.  (Note that I said "less," NOT 
"nonexistent.")

I'm not naive enough to think this conversion would be easy, 
cheap, or quick.  It would have to be planned, managed, and done 
in a phased manner.

It would also require some APSE tools.  One of them would be some 
way to access DBMS's and DBMS utilities such as data-definition 
interpreters from Ada--DBMS's are repositories of reusable code 
which it would (usually) be foolish to reproduce in Ada.

Also needed would be a substitute for CoBOL's data-formatting 
facilities (a capability available in almost no other language).  
I'd guess that the best way would be something like CICS, which 
is a library of screen- and page-layout routines and menu-driven 
programs giving access to the library.  With CICS one can quickly 
"paint" a complex input or output format with field-correctness 
checking.

Comments?                                   Larry @ jpl-vlsi