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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide