COBOL AND HPC - THE PRESENT

Various tools support migration of COBOL applications to HPC systems. There is potential benefit in overall throughput of programs by running the parallel system as n different processors. However, single applications still run on one processor. In practice, applications moved from IBM's MVS to UNIX usually require more execution time. A program that makes database calls may exhibit speedup as the calls may execute in parallel; if a program does not - the vast majority - it may exhibit parallel speed-down as the files accessed may be partitioned onto a number of disks causing increasing latency^1.1, and there is no parallel execution to make use of the increased availability of data.

Commercial users who ask for a migration path whereby their existing legacy COBOL systems - without database calls - can exploit a parallel system, are told that they can be re-written to call the database or the underlying operating system to execute user created threads. For example, MICROFOCUS offer user callable APIs and syntax for direct support of user level threading. MICROFOCUS also have a COBOL/SQL transparency system that enables applications to access relational databases using standard COBOL I/O syntax. However, this "rewriting solution" ignores at least two fundamental issues:

• commercial application programmers have expertise in COBOL and (usually) in the application domain in which they work; in general they do not have system-level or parallelisation skills;
• the nature of legacy systems means that many systems that are performance-bound are not well understood; they work, but defy attempts to modify them, and remain crucial to the organisation.

It is unrealistic to parallelise legacy systems in this way: The sheer volume of code prohibits such rewriting, and where attempts have been made there are more reports of failure than success (MacFarland, 1996). In particular, rewriting functioning business-critical applications is extremely high-risk.

The sheer number of COBOL programmers - 3 million - mitigates against retraining, allied to the realisation that these programmers' application knowledge represent significant investment and company knowledge (MacFarland, 1996; Sayles, 1996). Staff and installed systems represent massive investment and major assets for organisations. For most commercial IT departments the major investment is in staff skills, followed by investment in legacy applications (Teskey, 1996). In addition, a significant amount of new code is also being written in COBOL to address increasing demands for management information and decision support. As a result it is likely that COBOL will retain a primary position in commercial applications for many years (Bradley, 1996).

One solution is to apply compiler-based auto-parallelising techniques to COBOL as are currently available for FORTRAN, SQL and object-oriented languages. The data manipulation aspects of, and correspondence between, SORT and SEARCH in SQL and COBOL is obvious, as is the potential for using concurrent object techniques for the emerging COBOL-97. In the same way techniques to auto-parallelise FORTRAN DO loops can be applied to COBOL PERFORM loop.

Applying auto-parallelising techniques in this way is very attractive for commercial users as their software investment in COBOL is much larger than the corresponding investment in FORTRAN, and even modest benefits will have great impact.