eberard@ajpo.sei.cmu.edu (Edward Berard) (06/27/88)
Last month I posted a message requesting information on the use of Ada
technology for business applications. What follows are the responses I
received. All the responses except for Jerry Callen's were sent
directly to me. I am including his response, even though it was posted
to comp.lang.ada, for completeness. Once again, thanks to all who
responded.
-- Ed Berard
(301) 695-6960
P.S.: Since the entirety of my original message is contained in the
responses, I am not reposting the original message.
-------------------------
Subject: Re: Ada Vs. COBOL -- Looking for Inform
From: callen@ada-uts
> 1. They believed that most Ada compilers (in fact, any in the
> forseeable future) generate object code which is larger and
> slower than the object code which is produced for similar
> programs by COBOL compilers. One organization showed me a
> "benchmark" in which a company (well-known in the Ada community)
> had attempted to duplicate CICS (Customer Information Control
> System) in Ada. The Ada version was more than 50% slower and
> larger than the COBOL version.
I would like to add a few details and corrections to this comment.
The comparison was between two CICS transactions, one coded in Ada and
the other in Cobol. For those not "in the know", CICS is a
teleprocessing monitor for IBM systems that has been around since the
early 1960's. CICS can be considered a mini-operating system; thus,
the Ada runtime system had to be retargeted to this new "OS". The test
was performed on a VERY early release of the new RTS. The Ada
transaction was coded first (and to a tight deadline); the Cobol
version came later as a VERY simple attempt to gather some INITIAL
data comparing Ada and Cobol. I must emphasize that the Ada runtime
system and CICS interface used was VERY preliminary; it is by no means
optimal. The Cobol RTS and interface code has had 2 decades to mature.
The fact that the Ada came in 50% slower than the Cobol was NOT
particularly surprising, given these conditions. The figure can EASILY
be improved. This single, primitive data point has been blown
COMPLETELY out of proportion.
It is worth noting that the size of the object code for the actual
"mainline" program is SMALLER than that of the Cobol program! The
runtime system swamped this fact. Object code quality is BY NO MEANS
the problem, and as I said earlier, the RTS can be (and is being)
improved.
In case you can't tell, I wrote both the Ada and (shudder) Cobol code
for this "benchmark" (such as it is). Many years ago I did commercial
programming for online systems in Cobol. I KNOW Cobol. Why I'm
admitting this in public I don't know. :-) I have been writing Ada for
2 years, I think it's fair to say that I KNOW Ada, too. I can see
advantages and disadvantages to writing data processing code in Ada
rather than Cobol. But to use this ONE crude test to claim that
"Cobol outperforms Ada by 50%" is baloney.
-- Jerry Callen
Intermetrics, Inc.
733 Concord Ave.
Cambridge, MA 02138
(617) 661-1840
Internet: callen@inmet.inmet.com
UUCP: ...{harvard,ihnp4,ima}!inmet!callen
----------------------------------
From: actnyc!jls@uunet.UU.NET (Jonathan Schilling)
Subject: Re: Ada Vs. COBOL -- Looking for Information
1. Many MIS-type applications are not as obsessed about object code
size and speed as embedded systems applications are, due to their
being run on large computers or being I/O-bound.
2. CICS is written in IBM 370 Assembler, not COBOL; what was being
duplicated in this benchmark -- an application program *using*
CICS, or CICS itself?
Jonathan Schilling
-----------------------------
Date: Thu, 26 May 88 08:36:16 edt
From: geac!daveb@uunet.UU.NET (David Collier-Brown)
Subject: Re: Ada Vs. COBOL -- Looking for Information
Organization: The G. Yac Co. Ltd. Inc. Pty. Etc.
In article <342@ajpo.sei.cmu.edu> you write:
>Recently, I have talked to a number of MIS (Management Information
>Systems) professionals regarding the use of Ada technology in an
>environment which has been traditionally made use of COBOL, RPG,
>Fourth Generation Languages (4GLs), and classic DeMarco - Conastantine
>Structured Analysis and Structured Design, i.e., the typical business
>or MIS environment. The people I have been talking with have a number
>of observations which they conveyed to me:
>
> 1. They believed that most Ada compilers (in fact, any in the
> foreseeable future) generate object code which is larger and
> slower than the object code which is produced for similar
> programs by COBOL compilers. One organization showed me a
> "benchmark" in which a company (well-known in the Ada community)
> had attempted to duplicate CICS (Customer Information Control
> System) in Ada. The Ada version was more than 50% slower and
> larger than the COBOL version.
I think there's a misunderstanding here. CICS was written in /360
assembler by the team that did abort/dump in OS/MFT, and actually
contains substantial portions of OS/MFT code. (source: an ex-member
of the team doing a psyc degree at U of Windsor)
Besides being relatively tight assembler and not COBOL at all, it
was also written with explicit knowledge of the internals of the
operating system it was intertwined with. I suspect the Ada CICS was
a set of equivalent facilities, written from scratch in Ada, not
tightly coupled with the underlying OS and depending on standard
(slow) system services.
>
> 2. They asked me to identify any large organizations in the U.S.,
> which were capable of bidding on government contracts, which had
> both substantial MIS with Ada experience. They did not believe
> that there were any.
No information.
> 3. Although several DBMS (Data Base Management System) vendors
> claim to have an Ada interface to their products, when asked to
> produce these interfaces, the vendors admitted that the Ada
> interfaces were "still under development." Typically, the
> salesforces for these vendors were blissfully ignorant of the
> existence of any such interfaces.
This is a legitimate problem: one wants to use a high-level
interface to the DBMS (like SQL) from Ada, and it isn't obvious how
to mix and match a non-procedural style with Ada. A "simple"
interface is fairly easy (see the X11 bindings for an example), but
that assumes that the database will never change... We use an
3-schema architecture at Geac, so the interface is very
language-conformant, but the database is very independent of it.
And when it changes incompatibly, you fault at open time and have to
relink...
>
> 4. Those who advertise courses with themes such as "Ada for
> Business" or "Ada for COBOL Programmers" typically teach their
> students to write COBOL using Ada syntax and semantics, i.e.,
> "AdaBOL." The MIS professionals used this as a strong argument
> against going to Ada technology. "Why," they said, "should I
> duplicate my current technology in a new language?"
Its a symptom. I have a book on how to write FORTRAN in PL/1,
another on C in Modula II, etc, etc. See if there are not other
courses on "how to think in Ada".
>
>I am looking for substantiated warstories, benchmarks, products, et
>cetera, on Ada in a business environment. For example, while there is
>currently no standard Ada SQL binding, are there any any Ada SQL
>products available? Please send the information directly to me
>(eberard@ajpo.sei.cmu.edu) and I will post a summary of the results.
>
> -- Ed Berard
> (301) 695-6960
No, but if you're arbitrarily rich, I'll write Ada::=SQL for you
--dave ((:-)) c-b
--
David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb
Geac Computers Ltd., | "His Majesty made you a major
350 Steelcase Road, | because he believed you would
Markham, Ontario. | know when not to obey his orders"
------------------------------
From: portal!cup.portal.com!Charlie_Alan_Bounds@Sun.COM
Subject: Ada in a business environment
Ed,
I have been doing a prototype project on an IBM 3090-400 (if you are not
familiar with IBM, that is a big mainframe used mainly for commercial
applications). We use the IMS DBMS for which I wrote the Ada interface
for. The compiler is from Telesoft and it is HORRIBLE! It is almost
impossible to create a piece of code which when compiled and linked is
under 100K. The code section alone for the compiler is almost 4 megabytes
and it requires a minimum region of about 5.5 megabytes to run. Of course
the 3090 does have virtual memory but still for an Ada compiler to run in
5.5 meg while cobol will run in about 250K says something. The compiler is
designed to run in the foreground of an online system and going to the
system administrator and telling him that you need 5.5 meg for your online
sessions is a trial.
Another problem is that the compiler dynamically creates files. On a Unix
system I think that this is fairly common but the IBM operating system has
fairly comprehensive and friendly utilities for creating files so in
general one sets up a script to create all files and then call the
application which merely uses the files. The reason for this is that there
are many traps in creating files on the fly and the compiler does indeed
fall into one. It assumes that the files to be created are to go on a
specific disk unit called SYSDA. The problem is that at most shops, SYSDA
is the name used for a pool of disk units specifically set aside for
temporary files (edit work files, sort files, etc) and as soon as one tries
to create a permanent file on SYSDA your task is unceremoniously
terminated.
We fixed that one by dumping the compiler (all 4 meg), manually finding the
string SYSDA and patching it to a valid disk unit. This ain't great
because now ALL of our Ada programmers are creating libraries, listing
files, and other odds and ends on that one disk unit. This may get into
some contention problems as our usage grows and it may even someday fill
the disk.
Other than that we are progressing ahead and wondering where the next bear
is lurking.
Charlie Bounds Charlie@cup.portal.com
sun!cup.portal.com!charlie
--------------------------------
From: csed-1!csed-21!bryk@daitc.ARPA (Bill Brykczynski)
Subject: Business env reply
Ed,
In response to your posting on Ada in the business environment, I
can add some information regarding Ada interfaces to SQL. I am aware
of several DBMS vendors who supply Ada-SQL products. Oracle supplies a
precompiler for Ada, as does Ingres. These interfaces are of the
embedded type, which means that SQL statements are inserted into a
[Ada] program, then a preprocessor is used to generate something
which will compile. Oracle also has an High Level Interface (HLI),
which bascially passes strings to the database from the Ada program.
Also, Sybase has a product which supports Ada. I have not used it,
so I cannot vouch for its actual implementation. However, I have talked
with the guy who devised it.
On the non-profit side, (although it could easily be productized) the
WIS (remember those guys?) program has developed a native-Ada approach
called Ada/SQL. Ada/SQL is running on VAX VMS, using Oracle, and also
Unix on a Gould machine. It is substantially more developed than earlier
previous version.
Let me know if you have any questions.
Bill Brykczynski
IDA
BRYKCZYN@AJPO.SEI.CMU.EDU