Mainframe migration: Background

 

BACKGROUND

Migration of mainframe legacy systems to newer platforms has been receiving lots of attention as organizations have to shift to distributed and Web-enabled software solutions. Different approaches have been explored, ranging from wrapping existing systems with Web-enabled software layers, to 1-to-1 automatic conversion approaches for converting programs in COBOL to 4GL. Therefore,current literature presents many related experience reports. Because migration has been a problem since the first enterprise systems started to become obsolete, there is plenty of work on this topic. For instance, researchers have developed several methodologies for migrating system from their original technology to newer technologies, such as Cold Turkey, Chicken Little and Renaissance. Yet, these methodologies do not explicitly address how to migrate systems to SOA. To solve this issue, researchers have developed Service-Oriented Migration and Reuse Technique (SMART) for selecting migration strategies, but there is a lack of tools for assisting developers to apply it. In addition, SMART does not take into account SOA frontier quality as a main concern in this kind of migration. Another COBOL to SOA migration methodology is SOAMIG that , in contrast with SMART, provides both a migration methodology and tools. The migration methodology consists of four phases and each of these phases might be carried out in several iterations. The main idea behind SOAMIG is to transform the original system into a SOA oriented one using several translation tools. For instance, it proposes to use a tool that translates COBOL code to Java code which is easier to expose as Web Service. However, this approach might negatively impact on the quality of the SOA frontier because COBOL code was designed using out-of-date design criteria, and this kind of tools do not redesign the system. In addition, COBOL impose some length limitations to routine names and comments that might be probably translated to the SOA frontier, which might also represent a quality issue for the SOA frontier. In this context, migrating legacy systems to SOA, while achieving high-quality service interfaces instead of just “webizing” the systems is an incipient research topic. Harry Sneed has been simultaneously researching on automatically converting COBOL programs to Web Services and measuring service interfaces quality . The author presents a tool for identifying COBOL programs that may be servified. The tool bases on gathering code metrics from the source to determine program complexity, and then suggests whether programs should be wrapped or re-engineered. As such, programs complexity drives the selection of the migration strategy. As reported in, Sneed plans to inspect resulting service interfaces using a metric suite of his own,which comprises 25 quantity, 4 size, 5 complexity and 5 quality metrics. The author presents a framework and guidelines for migrating a legacy system to SOA, which aims at defining a SOA frontier having only the “optimal” services and with an appropriate level of granularity. The framework consists of three stages. The first stage is for modeling the legacy system main components and their interactions using UML. At the second stage,service operations and services processes are identified. The third stage is for aggregating identified service elements, according to a predefined taxonomy of service types (e.g. CRUD Services, Infrastructure services, Utility services, and Business services). During the second and third stages, software analysts are assisted via clustering techniques,which automatically group together similar service operations and services of the same type. This work presents a comparison of applying different migration approaches. Two of them together with their prosand cons are well-known with in the community,while the other is a new approach that aims at obtaining the pros of both previous migration without their cons. The following section discusses the case study used for this analysis.

Case Study

The case under study in this work consists of a data-centric system composed of several subsystems for maintaining data records related to individuals including complete personal information,relationships,work background,received benefits,and so forth. The system is written in COBOL, run so nan IBM mainframe and accesses a DB2database with around 0.8 PetaBytes. On the other hand, there are some COBOL programs accessing historic data through VSAM (Virtual Storage Access Method), a storage and data access method featured by a number of IBM mainframe operating systems. Moreover, some of the COBOL programs are only accessed through an intra-net via 3270 terminal applications, while other programs are grouped in CICS (Customer Information Control System)transactions and consumed by Web applications. CICS is a transaction manager designed for rapid, high-volume processing, which allows organizing a set of programs as an atomic task. In this case, these programs consist of business logic and database accesses, mostly input validations and queries, respectively.
Table 1: Characteristics of most important system transactions according to the mainframe load in terms of executed calls during January 2010.

tablesrt2MM

For the sake of illustration, a brief overview of only 6 transactions is shown in Table 1, which indicates the number of non-commented source code lines2, the number of SQL queries performed, and the number of lines and files associated with a transaction. When a program P1 calls a program P2, or imports a Communication Area (COMMAREA) definition C, or includes an SQL definition S, it is said that P1 is associated with P2, or C, or S, respectively. On average, each transaction had 18 files, comprised 1803 lines of code, and performed 6 SQL SELECT statements.