Carrying COBOL Applications Into the Next Generation
From "Special Report",  Access to Wang, May 1994
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

The Wang VS and COBOL have been a strong combination since the very beginning, offering developers a reasonably powerful implementation of COBOL and extensive, integrated utilities for development. Besides being well-supported, VS COBOL is also among the best-performing languages available for the VS. Small wonder that the majority of VS applications were developed in COBOL.

But many Wang shops are moving to other platforms where COBOL development tools are not as well integrated. Further, the use of COBOL for commercial applications has also drawn increasing fire from the academic world due to its reputation for large maintenance costs and non-standard syntax. Though COBOL has dominated the commercial software industry for over three decades, many are now considering moving to other development platforms - a difficult and costly process that puts the information assets of the corporation at risk.

This discussion will attempt to put some perspective on the features of the COBOL development environment we have enjoyed on the Wang VS and what can be expected in other systems.

Commercial applications and COBOL

There are several attributes of COBOL that make it attractive to commercial applications development. COBOL programming skills are widely available in the employment market. COBOL is a readable language; carefully-constructed programs do not need extensive technical documentation to be understandable to those who must maintain the programs later. The data structures used by COBOL - though unique among programming languages - are also very consistent between implementations of the language, allowing easier movement of data between platforms.

COBOL's detractors point to its large keyword set, vendor- specific extensions, and wordy syntax as evidence that it is not a modern language. Theoretical studies of system development in the late 1970's and beyond decried complex, single-program solutions in favor of smaller modules that are more easily understood. Until the COBOL 85 standard was released, there was little provision for development of modular programs; instead, program subroutines had to be bound together with inflexible data calls between them, increasing their complexity and, therefore, the chance for error.

The COBOL 85 standard changed some of that be improving the methods available to couple program code with standard routines. It is now possible to effectively use standard program sections for common routines (file I/O, screen handling, etc.) without need to pass fixed data elements between modules. For example, COBOL 85 now allows subprograms to be nested within other programs, using data items defined by the main program.

Of course, new language features are of little value unless they are actually used in programs. Most VS applications are written within Wang's standard COBOL compilers, which contain a subset of the COBOL 74 standards. Worse, some of the syntax of the 85 standard is not compatible with the 74 standard and many of the COBOL products on the market only support 85 syntax, forcing a conversion. Wang's own product for open systems - COBOL ReSOURCE - uses COBOL 85 syntax. Before evaluating your choices in migrating COBOL applications you should determine your future development direction. All of the source code converters on the market translate COBOL 74 code to 85 syntax, but none take full advantage of the new features of the language. If you plan to continue new COBOL development you should consider rewriting your applications to do so.

Defining the Development Environment

Programmers find that the integration of the VS editor and debugger make development much easier by combining all functions into a single set of tools. Editing, testing, and debugging can all be performed within the editor. With the addition of VS Multistation, multiple windows and a macro language can improve the programmer's workbench. This integration makes up for some of the limitations of the Wang editor, such as the sluggish modal operation and a lack of integrated version control.

As a Wang developer, what are your expectations? Most VS COBOL programmers count on:

• Support for COBOL style conventions, including formatting elements (tabbing, etc.), upper-case program syntax, etc.

• Full access to compiler and linker options, with visual selection.

• Full integration with a symbolic debugger.

• On-line access to a source listing, including a cross- reference of program section and variable usage.

• Access to other system tools as desired.

• Access to file management and operational control resources (e.g. the Command Processor).

• Review of system resources as the program executes (the Command Processor again).

• Related program development tools, including screen designers, code generators, and support for COBOL file definitions.

COBOL development tools on other platforms

While the Wang development environment was well-integrated, there was also little choice about what you would use, since there were few competitors. Development tools for open systems offer a great number of choices; in fact, most come ala carte and you will have to blend items from several sources to get a working environment that matches your expectations. Some products offer a reasonable editor, some a good symbolic debugger, and some have strong language features; no product offers a complete, integrated solution to development.

Editors that meet the expectations of COBOL programmers are particularly difficult to find. Most editors that come with open operating systems fall far short in their usefulness to the COBOL programmer. For example, the vi and emacs editors in the Unix environment are excellent for C programming but do not work well for the indented style of COBOL. Plan to spend some time and money for an editor that meets your needs.

One of the many things you will not find in most other development platforms is the rich set of code generators on the VS. Several COBOL products have screen-painting tools (like EZFORMAT), report generators (like EZPRINT, RPTGEN), or mass- compile utilities (like COMPILE), but few can compete with COBGEN, the data entry form of EZFORMAT, menus created by MENUGEN, or generation of File Descriptions from CONTROL definitions. Okay, code generators do not often produce attractive source files, but an embarassing number of VS applications began as the results of a COBGEN session followed by extensive modifications.

COBOL development on open systems often requires the use of development tools from several sources and the corresponding lack of integration between those tools. In this "roll your own" environment, you will have to apply some creativity to build smooth interfaces between tools. Often the best development tools are available for the MS-DOS environment.

Choosing a development environment

While developers of VS software have few choices about their development platform, those migrating to open systems face a number of options for both. Unlike the VS, COBOL programs may now be developed and tested on one platform and moved to another. Typically, this means that program development can be performed in the PC environment to take advantage of the lower costs and better flexibility of PC applications.

Developing COBOL on a PC and moving the resulting code to another system can mean faster development, since programmers are not affected by a slow production machine, maintenance, or other constraints. Many times this results in better code. It also becomes possible to consider working away from the office, which can improve programmer productivity and morale.

Using PCs to development applications can also save money. Compilers are priced by the capacity of the target platform, and it is often cheaper to buy several copies of a PC-based compiler but only a run-time module for the larger production machine.

Here are some things to look for in your development environment:

1. Source compatibility: Some COBOL products offer more compatibility with other versions of the language. Unfortunately, most of that compatibility is with mainframe versions of COBOL - not with the VS. Still, adherence to industry standards could help you move between versions or even products in the future and should be sought.

2. Portability: Some compilers claim portability when they really mean they are based on standards, while other can be moved between environments with little or no effort. The object form of interpretive compilers such as Acucobol and RM/COBOL allow you to move the compiled program directly to another environment without recompiling. This reduces the effort of developing in another environment and moving the resulting code after testing. Software vendors find this alternative particularly attractive. Native object compilers such as Micro Focus and CA-Realia must be recompiled in the target environment.

3. Performance: Not surprisingly, native-code compilers produce the fastest execution times. Interpretative compilers can be acceptably fast for most commercial purposes.

4. Licensing costs: As with Wang software, the costs of most compilers is usually based on the capacity of the target platform. Run-time modules cost less than full compilers.

5. Vendor support: Get refererences and check them. You will need plenty of help initially.

6. Support for data base systems: If you are likely to migrate some applications to data base management, look for compilers that can support these products.

Choosing a production environment

It's likely you have already made your choice for the target production environment, but new COBOL products can make some new options more realistic. For example, traditional terminal-based COBOL applications can gain a new look when run within a Windows run-time system, bringing some of the advantages of Windows (multi-tasking, color screens, access to PC memory, local print spooler, etc.) with little or no program modification. Naturally, such conversions do not make extensive use of Windows features but they can solve the need for concurrent access and improve PC memory management.

Fast LAN-based file access can be an alternative when your applications require quick access to smaller data files. Again, it may be possible to easily convert host-based VS applications to use this approach.

Most shops will turn to host-based use of Unix or DEC platforms as the best place for their host-based VS applications, since these machines are similar to the VS in their use and maintenance. This still allows many choices in configuration, including use of dedicated application servers that are specifically tuned to each major application with cross-platform network access to tie them together at the desktop.

Indexed file support

The COBOL standard specifies support for Indexed-Sequential files - the approach most often used by VS COBOL applications. Indexed files are supported directly by the Wang VS operating system. Since there is no direct support for indexed files on Unix or MS- DOS platforms, it is up to the application developer to support them. Most COBOL products support their own indexed file system and at least one aftermarket indexed file product, such as C-ISAM or Btrieve. Some also support access to data base products, allowing COBOL applications to remain in production even after a conversion to a relational data base for information access.

Since no indexed file systems are similar you will have to rely on vendor-supplied tools to create and maintain your files. Good tools will include several means of checking the physical and logical health of the files and a means of importing and exporting text from indexed format. As with the VS, prudent system administrators should set up routine processes for file system evaluation and repair.

All popular index systems support alternate keys, but not always in the manner you expect. Unlike VS DMS files (but like VS Indexed-Plus files), reading along an alternate key path where duplicates are allowed does not return records ordered by the primary key. The VS DMS files accomplish this trick by appending the primary key to alternate keys with duplicates, effectively creating a two-level key sort. The same effect can be had in other index systems by arranging the file elements so alternate keys include the primary key or by specifying a segmented key - one that includes two or more non-contiguous elements within its area. In all cases this form of alternate key significantly increases the file's overhead and reduces performance.

The future of COBOL

Though many have announced the death of COBOL in the past, it continues to flourish as businesses strive to reengineer aging applications. The ANS COBOL 85 standard did much to modernize the language, but additional pressures continue to push COBOL toward further innovations. In the next COBOL standard to be issued (probably in 1995) look for object-oriented language elements, additional language elements, a more standard approach to data base access, better support for graphical environments, and better integration with other languages.

Look for additional COBOL development tools as more mainframe shops move their programming to PCs, including graphical debuggers and support for code libraries (like C libraries). Commercial products may not be the only force, either: there are rumors that the Free Software Foundation (a.k.a. Gnu) has a version of COBOL 85 in the works, which would further COBOL's encroachment into the Unix and PC environments by providing a cheap and universal development language.

Are we seeing the last days of COBOL? Could be, but there are many vendors and IS professionals out there that believe there is still some life left in the old workhorse. It is difficult to see how existing COBOL applications can be incorporated into any other development tools presently on the market. For now, most of us will have to carry our COBOL code into new world and start an evolutionary process towards a new development paradigm.