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=2.6 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,SYSADMIN,TO_NO_BRKTS_PCNT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mandrill!gatech!udel!rochester!pt.cs.cmu.edu!sei!ajpo!eberard From: eberard@ajpo.sei.cmu.edu (Edward Berard) Newsgroups: comp.lang.ada Subject: Ada Technology In a Business Environment Keywords: Ada, Business, CICS Message-ID: <345@ajpo.sei.cmu.edu> Date: 27 Jun 88 11:11:12 GMT List-Id: 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