I used Acucobol in an SCO Xenis environment in a previous job. I was happy with the product, so all I had to do to evaluate the Linux version was make sure it works as well as the Xenix one.
Yes, I've read the flame wars that have appeared in just about every comp.* newsgroup about COBOL. They are irrelevant to this article. In evaluating Acucobol as a product, I'm interested in whether the statements:
move 2 to x. add 3 to x.
produce a value of five, not whether it's better or worse to code:
x = 2; x += 3:
I used Acucobol in an SCO Xenix environment in a previous job. I was happy with the product, so all I had to do to evaluate the Linux version was make sure that it works as well as the Xenix one.
Like most commercial products currently available for Linux, Acucobol has been ported to a large number of platforms. Acucobol goes a step further. The Acucobol compiler actually translates the COBOL source into a “b-code” file. When you execute an Acucobol program, you actually run a b-code interpreter. It's no problem for a program compiled on one sort of machine to be executed on any other machine that runs Acucobol. You can compile programs on Linux and run them on Sun workstations, Vaxen, or even MS-DOS or Windows NT. (Yes, Acucobol is smart enough to convert / characters in paths to \. I'm not sure what happens when a component of the path is longer than eight characters, however.)
If your last exposure to COBOL was in a mainframe, batch processing environment, you will see some major differences. Acucobol is not very fussy about which column statements begin in. There are some significant new language features. One that I particularly like is the EVALUATE statement, which is similar to the switch statement in C. There are also a lot more places where an ELSE statement can be used. It's possible to reference substrings using what is known in COBOL as “reference modification”; the form is data-name (leftmost-position: length). The SCREEN SECTION, the windowing capability, and the ability for an ACCEPT statement to bring in an entire screen of data are Acucobol extensions. It's even possible to reference “embedded procedures” within the screen section.
Another new feature is a subprogram named W$MENU. Older versions of Acucobol came with a subprogram named MENUBAR. It was written entirely in COBOL and worked very nicely. W$MENU has all of MENUBAR's capabilities, except one. W$MENU is designed so that your menus are always activated by a hot key. Suppose you want the menu to appear whenever your program requires a menu choice The only way I could figure out to do it was to call another built-in subprogram, W$KEYBUF, which stuffs the input buffer. I used W$KEYBUF to stuff the hot key into the input buffer, and the menu appeared. (Acucobol Inc. has promised to provide a cleaner way of doing this in the future.) W$MENU is complemented by a rudimentary menu generator; it's batch, not interactive.
It's possible to develop C functions that can be called by Acucobol, and the manual does a good job of explaining how to do this. The only problem is, the functions must be linked into the b-code interpreter.
Acucobol uses neither termcap nor terminfo. Instead, it uses a file named a_termcap, which you would normally install in the /etc directory. The supplied a_termcap file contains an xterm entry, but this entry had no color or graphics support. I was able to create a color xterm entry by cannibalizing other a_termcap entries. It ended up looking like this:
xterm-c|color xterm:\
:GO=\E(0:GF=\E(B:GM=qxlkmjvtwun:VB:\
:C1=\E[30m:C2=\E[34m:C3=\E[32m:\
:C4=\E[36m:C5=\E[31m:C6=\E[35m:\
:C7=\E[33m:C8=\E[37m:\
:B1=\E[40m:B2=\E[44m:B3=\E[42m:\
:B4=\E[46m:B5=\E[41m:B6=\E[45m:\
:B7=\E[43m:B8=\E[47m:UL@:RU@:tc=xterm:
Acucobol comes with a reference manual and a user's guide. They are both loose-leaf and about 1,000 pages apiece. The manuals are used for all Acucobol implementations, including Unix, MS-DOS, and VMS.
Like any other COBOL implementation, Acucobol supports sequential, indexed, and “relative” (direct-access) files. Acucobol's indexed file system is called Vision, which is proprietary to Acucobol. Vision files have keys and data combined into a single file, and the index structure is b-tree. Vision is efficient and reliable. The only problem is that if you want non-Acucobol programs to access Vision files, you will have to buy a license from Acucobol Inc. A more interesting solution is an Acucobol add-on called “Plug and Play”. It works like this: All COBOL ISAM statements (READ NEXT, START, etc.) are mapped into a dispatch table. In the standard Acucobol run-time, the table entries point to Vision functions. You can replace this table with a different one, so that the table entries point to D-ISAM or Codebase functions. I have an evaluation copy of Codebase (the subject of my next review) on my desk, so I plan to actually try this.
Acucobol should be capable of compiling and running any standard-compliant COBOL program. However, unless the program has no user interface whatsoever, you're probably going to want to do some conversion work. In particular, Acucobol has an RM/COBOL compatibility mode. It works perfectly well, but my experience has been that it's still better to rearrange the way in which data is displayed on and accepted from terminal screens, because Acucobol allows you to do this in a less tedious fashion.
There's a substantial pile of application software and add-ons available for Acucobol. Two worth mentioning are the MCBA and Real World accounting packages.
I developed a simple benchmark for Acucobol, which is a translation of another benchmark I did for xBASE products. (See Linux Journal #14, June 1995, p. 27.) This benchmark processed a file containing 33,830 records and was run on a 66 mHz 486 with a SCSI disk.
It's reasonable to expect that Acucobol would be noticeably slower than Flagship, since Flagship programs are compiled into machine code, and Acucobol programs are compiled into b-codes, which must be interpreted at run time.
Figure 1. Benchmark Results
Acucobol Inc. hosts a developers' conference in San Diego every year. The next one is September 18-20. I haven't been to one of these yet, but I've had good reports from them; attendees are treated well by Acucobol, Inc.
There are references in the manuals to GUI and mouse support, but they seem to be only for Windows NT. Acucobol, Inc. does seem to be interested in offering some sort of UNIX GUI support eventually.
This product will probably not be of much interest to hard-core Linux people; they would rather program in C for free than pay big bucks to use COBOL. It should be of interest to the Linux community, though, that Acucobol, Inc. went to the trouble of porting their product, because it gives Linux more legitimacy.
However, the Linux version of Acucobol should be of great importance to another community: system houses that develop and maintain COBOL application software. When these system houses sell a product to an end user, the end user must not only purchase the application, s/he must also purchase the hardware the application runs on and the rest of the software environment. For example, if the application runs under Windows 95 or SCO Unix, either the customer or the systems house must buy a copy of Windows 95 or SCO Unix. A system house that has a COBOL application to sell can now try to convince customers to accept Linux as the software environment instead and can offer a lower total cost to the customer.
