From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!VLSI.JPL.NASA.GOV!larry From: larry@VLSI.JPL.NASA.GOV Newsgroups: comp.lang.ada Subject: Ada as a Successor to CoBOL Message-ID: <870824185151.02a@VLSI.JPL.NASA.GOV> Date: Mon, 24-Aug-87 21:51:51 EDT Article-I.D.: VLSI.870824185151.02a Posted: Mon Aug 24 21:51:51 1987 Date-Received: Wed, 26-Aug-87 01:15:57 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet List-Id: 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