Today’s highly competitive global market, with ever-increasing emphasis being placed on profit margins, dictates the more efficient use of business assets. In an article in CIO Update (“Apples and Oranges: Comparing IT Maintenance Costs to New Initiatives,” November 14, 2007, available at http://www.cioupdate.com/insights/article.php/3711106), Jan Vromant reports that IT departments typically spend as much as 80 percent of their budgets on legacy processing and maintenance costs. Today, IT finds increasing focus on profits and drastically shrinking budgets; this is forcing IT to find sophisticated, cost-effective processing, maintenance, and resource solutions.
Seamlessly bridging together legacy and modern IT solutions is the objective of Service-Oriented Architecture (SOA). For IT organizations with a diverse set of solution architectures, SOA is more problematic, as legacy architectures aren’t as flexible as modern, standards-based architectures such as Java 2 Enterprise Edition (J2EE). IT solutions housed in COBOL present the most difficulties for an SOA project. Historically, the two solutions for COBOL modernization are either expensive (rewrite) or introduce a level of complexity best avoided (wrapper/connector technologies).
Of the feasible approaches to modernize COBOL for SOA, the easiest is to exploit the technology of a compiler. A compiler transforms a development language (used by people) into an execution language (processed by computer platforms). The resulting execution language operates on the circuitry of the computer platform to produce the desired results.
This is nothing new; we don’t even give it a second thought. However, what could be changed to more easily modernize COBOL without incurring the painstaking effort of these other approaches?
Let’s look at what a modification to compiler technology does for COBOL modernization.
A compiler transforms source into an executable, which historically has been the “native” language of the target hardware platform. By using the modern architecture of J2EE and replacing the target hardware platform with the Java Virtual Machine (JVM), the new transformation language becomes Java. This modified compiler now transforms COBOL into a Java executable, while retaining the COBOL source as before and also generating Java, giving IT the options of maintaining in COBOL, in Java, or in both source languages.
Using Java is beneficial because of its portability across open systems and extensibility to other modern technologies. Java has unquestionably become the global de facto choice for Fortune 50 to Fortune 1000 companies; its many benefits make a compelling case for modernization and adopting the new compiler architecture.
By compiling COBOL into Java, all of Java’s benefits are now inherited by the COBOL source; this approach facilitates modernization and SOA compliance. By changing just one element in the compiler process, you can still retain the source (which all compilers do), yet the back-end executable is now deployed into the JVM.
The Modern COBOL Architecture
You might wonder: “Which aspects of the COBOL program architecture are modernized?” Figure 1 shows an IBM CICS/COBOL solution as it exists in the IBM z/OS environment and as modernized. The sample reflects that the COBOL processes VSAM data and displays BMS screens to the user.