larry@VLSI.JPL.NASA.GOV (08/25/87)
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
CONTR47@NOSC-TECR.ARPA (08/25/87)
Let me say all I know about this subject (this wouldn't take long). 1. I was contacted by several large DoD COBOL shops near Wash DC regarding Ada training so I visited one of them one day. I learned that their General had directed that Ada be used in place of COBOL and naturally the subject of Ada training came up. I was told that many of the "COBOL Programmers" performed maintenance only and had never written an original program. After grasping the enormity of the problem I can understand this. I have fixed many cars bt have never built one. It seemed to me that they need an Ada system which included CICS and probably many other things that I don't understand. 2. I stated that I could teach Ada but could not begin to teach them how to apply it to their system problem and also I suspected that huge pieces (e.g.:CICS) were missing from the Ada system. They said that Alsys was conducting an experimental course to learn how much Ada could be taught to the COBOL people. I don't know how this turned out. 3. I determined that I could teach the people generics, tasking abstraction etc. given enough time. I suspected that I might have to preceed the Ada course with one semester of Computer Science. I decided to stick to my realtime Ada knitting and leave the COBOL to Ada transition to those who understand the system problem. It is my impression that Dr. Robert Dewar of NYU is an expert in both COBOL and Ada and could probably provide language guidance. However in addition system knowledge is needed (he may have that also). 4. A friend of mine taught 2 weeks of Ada to COBOL people at a military base and at the end of 2 weeks they didn't yet understand the difference between an object and a type. I'm not putting anyone down, just pointing out that pre-Ada training may be necessary. --- To develop a successful product, system etc: step 1 - Understand the Customers Problem -- regards, sam harbaugh ---------------------
dbrauer@humu.UUCP (David L. Brauer) (08/27/87)
You may be interested to know that Ada is beginning to make headroads into the logistics arena. I am part of a team at NOSC-Hawaii that is developing an embarkation planning system for the Marine Corp. We have been mandated to use Ada for the application. Here's the real kicker -- the target machine is the new Marine Corp 286 computer (IT&T XTRA). It looks like we'll probably be using Alsys Ada for the development. The real tricky part is going to be handling screen graphics (the system requires CAD type operations). Any ideas or references would be appreciated. David C. Brauer Computer Sciences Corporation