Moving Mainframe Applications to Windows

Considering the options to preserve, translate, or rewrite

Custom Research Note

Author: Dr. Mike Gilbert, Legacy Directions Published: February 2008 For the latest information, please see www.microsoft.com/mainframe

Analyst Dr. Mike Gilbert of Legacy Directions Limited wrote this custom research note for Microsoft Corporation. Interested readers should contact the author at [email protected] to arrange further discussion or an interview.

Contents
Introduction.................................................................................................................................................... 2 Mainframe modernization .............................................................................................................................. 3 Application migration ................................................................................................................................. 3 Mainframe programming languages ......................................................................................................... 5 Windows compilers for mainframe languages .............................................................................................. 6 Vendor solutions ....................................................................................................................................... 7 Case study: The Italian Department of Social Security............................................................................. 9 Language conversion tools ......................................................................................................................... 10 Vendor solutions ..................................................................................................................................... 11 Case study: GDC A/S ............................................................................................................................. 12 Services and tools to rewrite mainframe applications ................................................................................. 14 Service providers .................................................................................................................................... 14 Legacy analysis tools .............................................................................................................................. 15 Case study: The Schwan Food Company .............................................................................................. 17 Analysis of language migration options ....................................................................................................... 18 Windows compilers for mainframe languages ........................................................................................ 19 Language conversion tools ..................................................................................................................... 20 Services and tools to rewrite mainframe applications ............................................................................. 20 Conclusions ................................................................................................................................................. 22 Looking forward ...................................................................................................................................... 22 Appendix A: Compiler product profiles ........................................................................................................ 24 Appendix B: Conversion tool profiles .......................................................................................................... 26 Appendix C: Service provider profiles ......................................................................................................... 29 Appendix D: Analysis tool profiles ............................................................................................................... 30 Appendix E: The Object Management Group ............................................................................................. 31

Moving Mainframe Applications to Windows

Introduction
According to a 2003 report by the Aberdeen Group , investment in legacy applications, which account for upwards of 70 percent of enterprise business operations, consumes as much as 80 percent of enterprise software budgets as IT organizations struggle to align those systems to current and future business 2 needs. In a September 2006 report , Aberdeen Group claims that The global economy runs on legacy systems that represent hundreds of billions of dollars in investments that enterprises have made over decades. Many of these applications were first built 30 or 40 years ago with a life expectancy of 10 years or so, but IT organizations have a poor track record of refreshing investment in software infrastructure. Instead, we have added to, updated, and integrated these applications with new systems as business needs grew, until they became the foundations of present-day business processes. But these foundations are still locked in a technology time capsule; they become harder to modernize as they are more deeply embedded in their surrounding technology infrastructure. One of the key reasons for this difficulty is that the applications are defined by huge volumes of platform-specific source code written many years ago. It is not unusual to find a major bank or insurance company that maintains an inventory of 80100 million lines of code. This requires a large team of mainframe programmers, but these skills are becoming harder to find. Many organizations are now seeking ways to escape from this technology time capsule. Those who have decided on a move to a new platform must consider how to make best use of their investment in existing applications. This paper presents three options and analyzes the impact that these choices have on the business. Business leaders will benefit from a high-level understanding of the issues and conclusions addressed in this paper, but our intended audience is chief information officers and chief architects who are tasked with critical technical decisions that match IT spending (and hence, systems architecture) with business benefits. The paper aims to raise awareness of the available software solutions that can be used to move mainframe language applications to the Windows operating system, and to indicate additional resources for the reader who wants to delve more deeply into the subject. In the sections that follow, we describe briefly the broader issues concerning modernizing mainframe applications and the options available, and we then explore three solutions to the language problem, ranging from recompiling the application on Windows to a complete rewrite. A further option, to replace the existing custom code with a packaged solution, while entirely viable and commonly adopted for generic business applications, is outside the scope of this paper. In each of the three solutions presented here, we provide a list of vendor offerings, a selection of vendor and product profiles, and a case study to illustrate the solution. In the analysis, we look at the business impact of each of these solutions in terms of cost, risk, skills, agility, and innovation.
1

1 2

IBMs Legacy Application Antiques Road Show. Aberdeen Group. April 2003. The Legacy Application Modernization Benchmark Report. Aberdeen Group. September 2006.

Moving Mainframe Applications to Windows

Mainframe modernization
Applications written for the earlier IBM mainframe systems and plug-compatibles from Hitachi and Amdahl continue to give service today on System i and System z mainframes. Unisys continues to support early Burroughs and Sperry applications alongside Windows applications on its latest ClearPath hardware. Fujitsu and Fujitsu Siemens help organizations to maintain operations that use applications written for early ICL and Siemens mainframes. Meanwhile, the few organizations that are still using Wang, Bull, Data General, and older machines run the risk of unrecoverable failures. Many are planning to replace these systems with packages or to migrate them to newer platforms. Companies may extend and integrate mainframe applications to use these applications in new business contexts, but this does not help them to rationalize platform choices. The last decade has seen a huge increase in the number of servers deployed to support new business initiatives, but we now recognize that uncontrolled growth has created a large cost and carbon footprint. Businesses today want the flexibility to support consolidation to strategic platforms. In a 2006 report , Gartner suggests that organizations need a wholesale re-architecting of the application platform, and conclude that CIOs and their IT executives must complete enterprise platform migration by 2009. Ultimately, IT organizations that choose a non-mainframe enterprise platform will want to close down their legacy platforms. But legacy applications do not move easily, because they were built on mainframe-specific and often proprietary operating environments. This leads organizations to consider one, or possibly many, of a number of options to move their legacy. These are: Rehost the application with minimal change on a new platform. Convert the application using tools to automate source changes. Rewrite the application to exploit new languages and platforms. Replace the application with a commercial package.
3

We do not address the use of commercial packages in this paper, but we do address the language issue from the perspective of three complementary technology solutions: Compilers for mainframe languages that can be used to rehost applications on Windows Tools that can be used to convert application code to COBOL, C#, or Java Services and tools to rewrite a mainframe application in C# or Java

This paper will help you make a choice between these language solutions and the broad approaches to legacy modernization that they support. Following a review of language solutions, vendors, and case studies, we will analyze the benefits and disadvantages of each solution and present summary conclusions.

Application migration
There is no universally right or wrong approach to legacy modernization. Organizations should take account of business goals as well as technology goals when making a decision to modernize. It is imperative to balance the cost and risk of each approach against your business need for the different benefits that accompany them. For example, rehosting an application without changing the source code language may involve less cost and risk than rewriting the application, but this will not help you deal with a potential future shortage of developers who are skilled in the legacy language. Regardless of the approach taken, application migration requires specialist skills to deal not only with proprietary languages but also with platform-specific batch processing environments, online transaction
3

The Gartner Scenario 2006: The Current State and Future Direction of IT. Gartner. October 2006.
Moving Mainframe Applications to Windows 3

processing systems, and non-relational database systems. Project management, data migration, testing, and deployment add to the list of skills required for successful migrations. While some organizations choose to do this work themselves, the majority recognize that the one-time skills needed for migration are best provided by a specialist vendor. Systems integrators provide an industrialized process and manpower to scale the delivery of modernization services through a methodology that is likely to include the following activities: Feasibility study and pilot projects Business impact and continuity planning Inventory and migration of source code and data Identification and impact assessment of existing application interfaces Composite platform architecture definition and planning Application analysis and project scope assessment Code conversion, synchronization, and regression testing Data conversion, synchronization, and validation Performance benchmarking and user testing Platform configuration, operational setup, and handover Training in new application development tools and techniques Ongoing mentoring and support

You can find further advice on tools and services for application modernization on the Microsoft mainframe modernization Web site (www.microsoft.com/mainframe). This site is constantly updated to provide up-to-date information from analysts, vendors, and others about the issues surrounding mainframe modernization. For example, earlier papers published by Microsoft have considered Windows4 5 based solutions for batch processing and mainframe-compatible transaction processing . This paper considers only the programming language issues when rehosting, converting, or rewriting mainframe applications for the Windows platform. The Mainframe Migration Alliance (MMA), founded by Microsoft in 2004, brings together companies that offer software and services to migrate workloads from the mainframe to Microsoft software (see (www.mainframemigration.org). The purpose of the alliance is to: Provide a community where members can collaborate. Provide co-marketing, sales, and support to partners and customers. Raise awareness of the viability of the Windows platform. Raise awareness of the viability of workload migration. Provide a central point for publishing relevant information.

On its Web site, the MMA currently lists over 100 member companies that cover a full spectrum of service providers, software vendors, and technology specialists.

4 5

See Job Scheduling on Windows at www.microsoft.com/mainframe. See Mainframe-Compatible Transaction Processing on Windows at www.microsoft.com/mainframe.

Moving Mainframe Applications to Windows

Mainframe programming languages

Mainframes have accumulated a large legacy of second-generation (2GL), third-generation (3GL), and fourth-generation (4GL) programming languages. Some of these are clearly very proprietary, and some are general-purpose standards-based languages. Table 1 lists the most popular 3GL and 4GL languages that are used to build mainframe applications.

Table 1. Popular 3GL and 4GL mainframe languages

3GL mainframe programming languages
Ada Algol C, C++ COBOL FORTRAN LINC (Unisys) Pascal PL/I REXX RPG

4GL mainframe programming languages

ADS/Online (ADSO) Application Master APS CA Ideal COOL:Gen CSP DYL-260/280 Easytrieve Plus FOCUS Mantis Natural Telon

Many of the 4GL languages are closely related to proprietary databases such as CA-IDMS (ADSO), CA Datacom (CA Ideal), Supra (Mantis), and Adabas (Natural). Conversion of the language normally involves conversion of the database also. This paper does not provide details of database conversion tools, but these are generally available from the same vendors that specialize in conversion tools for the language. 2GL languages (assembly languages) are tied to the hardware and operating system, and are generally highly proprietary in nature. IBM 370 High-Level Assembler has been used widely to implement mainframe applications, including those running under TPF (Transaction Processing Facility), an operating system geared to high transaction throughput. Many applications written using 3GL and 4GL languages use some Assembler code for platform-specific functions. Job control languages such as IBM JCL (MVS and VSE variants), ICL SCL, and others form another category of platform-specific code that contains business rules embedded in batch processes. Finally, both through and in spite of standardization, many of the languages already mentioned come in a variety of dialects. Tools to analyze, compile, and convert legacy applications support specific subsets of these dialects. For example, COBOL, which has four standards (COBOL 66, 74, 85, and 2002) and one addendum (COBOL 89), has hundreds of platform-specific dialects, vendor releases, and extensions. Many of the vendors discussed in this paper specialize in tools and services for a specific platform. Here you will find the greatest support for platform-specific languages such as 2GLs, JCL, and dialects of the more common languages.
Moving Mainframe Applications to Windows 5

Windows compilers for mainframe languages

Windows implementations of mainframe language compilers provide the foundation for application rehosting solutions. In its simplest form, the mainframe source code is downloaded to Windows and recompiled to create a clone of the original application. Such an application provides the same (or equivalent) appearance and functionality as the original. This approach is most appropriate when the application serves a critical business need well yet the IT organization is seeking to lower costs by consolidating operations on a contemporary platform such as Windows. Although rehosting brings the application closer to new platform technologies, it does not change the application source language or user interface, and thus it minimizes the impact in terms of changes to the user and developer communities. Organizations that implement a standard package for business operations frequently encounter specialized but isolated mainframe applications that are not easily replicated using the standard package. Such applications may be rehosted to the new platform, allowing the mainframe to be turned off to fully realize anticipated cost savings. One of the key technical considerations is the degree of compatibility provided by the new compiler. Mainframe languages like COBOL provide little independence from the underlying hardware and software; there may be issues such as memory addressing, character encoding, and collating sequence differences that require attention. In addition, most applications make calls to subsystems and databases (such as CICS and IMS) that are not present on Windows. Some vendors provide solutions by implementing clones of these subsystems as optional extensions to the run-time environment for compiled applications. In other cases, the organization may need to combine the use of a mainframe language compiler with conversion tools (discussed in the next section) to switch from using the mainframe subsystem or database to a Windows equivalent. Compilers may be hosted in a vendors integrated development environment (IDE) or inside the Microsoft Visual Studio development system. The advantage of using a compiler hosted in Visual Studio is that developers use the same tools as those provided for Microsoft languages, such as the project management functionality in the Visual Studio Team System, the WinForms and WebForms forms designers, and the integrated debugging feature of Visual Studio. Many vendors provide both options. Managed code Managed code compilers generate executable code in the form of Microsoft Intermediate Language (MSIL). MSIL code is executed by the common language runtime (CLR), a component of the Microsoft .NET Framework. A variant of MSIL, called verifiable code, allows the CLR to guarantee that .NET applications do not violate current security settings. As an example, if the current security settings prevent code from writing to disk, then the CLR can determine that the verifiable component meets this requirement before executing any of the code. Typically, verifiable code is used for applications that are downloaded to a browser from the Internet or from applications running as components of Microsoft SQL Server database software. Managed code compilers implement object-oriented (OO) language features to provide close integration with the.NET Framework. Through these features, legacy programs that are moved to the managed environment have full access to the .NET Framework. Applications can be extended or integrated with components developed with C# or the Microsoft Visual Basic .NET development system, and can use .NET Framework capabilities such as Microsoft ASP.NET to build Web front ends, the Windows Presentation Foundation to create desktop user interfaces, the Windows Communication Foundation to interoperate with remote applications, and the Windows Workflow Foundation to assemble legacy components into workflows.

Moving Mainframe Applications to Windows

Unmanaged code Unmanaged code compilers generate executable code that is targeted for the processor or other run-time environment outside the CLR. Because unmanaged code executes outside the .NET Framework, it does not benefit from the rich class library and tools that Microsoft provides for .NET-based applications. However, these applications can communicate with .NET-based applications via a special interface. It is also 6 possible to create .NET-based assemblies that communicate with unmanaged code to act on their behalf. Unmanaged code compilers are classified in the tables below as those that generate one of the following: Intel x86/x64/IA64 code that is run directly on Windows Java code that is compiled and run on a Java Virtual Machine (JVM) C code that is subsequently compiled by a C compiler into unmanaged code A proprietary intermediate code that requires an unmanaged interpreter to run

Vendor solutions
Over the years, COBOL has become the most widely adopted programming language for business applications. FORTRAN is almost as popular as COBOL, being the preferred language for scientific applications. PL/I (which stands for Programming Language 1) was introduced by IBM in the early 1960s as a single language for both business and scientific applications. Although PL/I did not gain the same popularity as COBOL, many large IT organizations adopted PL/I and have significant ongoing investment in the language. RPG has become the adopted language of the IBM System i (and its predecessors the iSeries and the AS/400). Compilers for COBOL, FORTRAN, PL/I, and RPG are shown in Tables 2 through 5, along with an indication of the generated code options.

Table 2. COBOL compilers

Vendor
Acucorp (Micro Focus) Envyr Corporation Fujitsu IBM Corporation INFINITE Software LegacyJ Liant Micro Focus Veryant

Product
ACUCOBOL-GT ICOBOL
8

Generated code
x86 x86 x86, MSIL (verifiable) x86 C Java Intermediate code x86, MSIL (verifiable) Java
7

NetCOBOL for .NET Universal Rational Developer for System z INFINITEzSeries PERCobol RM/COBOL Net Express isCOBOL

6 7 8

These .NET Framework components would not be verifiable because the CLR could not ensure that they will comply with the current security settings. This is shorthand for x86, x64 and IA64 native code for Intel and AMD processors. Data General COBOL.

Moving Mainframe Applications to Windows

Table 3. FORTRAN compilers

Vendor
Absoft Intel Lahey/Fujitsu Silverfrost The Portland Group

Product
Absoft Pro Fortran Visual Fortran Compiler Lahey/Fujitsu Fortran FTN95 PGI Visual Fortran

Generated code
x86 x86 x86 x86, MSIL x86

Table 4. PL/I compilers

Vendor
IBM Corporation Liant

Product
Rational Developer for System z Open PL/I

Generated code
x86 Intermediate code

Table 5. RPG compilers

Vendor
BluePhoenix Solutions IBM Corporation INFINITE Software

Product
ASNA Visual RPG VisualAge RPG INFINITEiSeries

Generated code
MSIL (verifiable) x86 C

In addition to the compilers shown above, there are also open source projects such as COBOL for GCC , 10 11 12 13 TinyCOBOL , OpenCOBOL , pl1gcc (PL/I for GCC) , and G95 (Fortran) . Compilers for many other languages (with the exception of Algol) are freely available on both mainframe and distributed platforms. For example, mainframe C++ applications can be moved to Windows and .NET using the Microsoft Visual C++ development system. Appendix A includes profiles of compilers from four vendors that address application rehosting by providing mainframe-compatible syntax and commonly used IBM platform-dependent services. The following case study shows how a Windows COBOL compiler was used to help move a mainframe application to .NET.

See cobolforgcc.sourceforge.net See tiny-cobol.sourceforge.net See www.opencobol.org See pl1gcc.sourceforge.net See www.g95.org

10 11 12 13

Moving Mainframe Applications to Windows

Case study: The Italian Department of Social Security

The Italian Department of Social Security, INPS (Istituto Nazionale della Previdenza Sociale), provides pensions as well as care for the elderly, disabled, and unemployed. The department employs 30,000 people in over 300 branch offices. AS/400 computers in each office ran COBOL applications comprising 24 million lines of code. INPS wanted to provide public access to data, and also sought a way to reduce its dependence on proprietary platforms with more portable and reusable components. IBMs WebSphere was considered, but with 500 COBOL programmers already in place, there was no desire to rewrite the applications. INPS chose the Microsoft .NET Framework to host the COBOL code. Accenture won the modernization contract and worked closely with Bizlogica (a distributor for Fujitsus NetCOBOL products) to detail the approach taken. The conversion project required data to be moved from COBOL ISAM and DB2/400 databases to SQL Server 2000; 5250 screens were changed to ASP.NET forms, preserving screen layouts and flows to minimize retraining. Data access and user interface code was converted to C#, but approximately 90 percent of the original code remained to provide the business logic layer. Applications were segmented into 12 business domains, 11 of which have been converted and are in production at the time of writing. This has allowed INPS to decommission 250 of the AS/400 branch office machines and replace them with a centralized configuration of IBM System x servers running Windows. This configuration includes 10 terabytes of SAN storage, 8 database servers, 10 Web and application servers, 9 batch servers, and 3 gateway servers to an IBM System z mainframe. INPS plan to maintain the current base of COBOL (about 22 million lines of code) but will specify C# for enhancements and new applications.

Moving Mainframe Applications to Windows

Language conversion tools

Automatically converting a legacy application to an application that exploits the latest language and platform is likened by many to the alchemists dream of turning lead into gold. There have been many software startup companies founded in this dream; some have foundered, but fortunately many have persevered and flourished. In contrast to the rehosting approach discussed in the previous section, language conversion tools provide greater opportunities to modernize application source code, databases, user interfaces, and development tools. Modernization may be driven by a need to reduce or remove dependency on legacy technologies such as an unsupported database or an obsolete 4GL language, or by a concern that the skills to maintain these applications may be in short supply. Such changes, even when automated, carry a higher risk than straightforward rehosting, because of the impact on the user and developer communities. However, converted applications that fully embrace a new platform such as the .NET Framework or Java Platform, Enterprise Edition (Java EE) are easier for appropriately skilled developers to extend and integrate. The fundamental question remains: is automated language conversion a realistic proposition? Can we trust the fidelity of the results, and will we be in a better or worse position when we need to rapidly adapt the application to new business needs? For example, many of the early COBOL-to-Java converters generated unwieldy procedural Java code. Not all real-world conversion problems are hard. Table 6 shows the relative difficulty of converting 4GL application definitions or proprietary COBOL dialects to industry-standard, cross-platform COBOL or an OO language such as C# or Java.

Table 6. Relative levels of conversion difficulty14

To:
Industry-standard COBOL C# or Java easy hard

From:

4GL Proprietary COBOL

easy easy

Choosing a target language is a complex consideration that will be discussed further in the analysis section of this paper. For some organizations, conversion to standard COBOL meets their current business and technical needs. This has driven the development of tools to convert legacy 4GL languages to COBOL and tools that convert proprietary COBOL dialects to standard COBOL. These tools leave us with the option of compiling the application for Windows using one of the compilers discussed in the previous section. These conversions are relatively easy, which is to say that they are no harder than writing a compilera task that is based on well-established software engineering principles. Converting an application written using a 4GL language to an OO language like C# or Java is also relatively easy. 4GL languages are based on the now-familiar three-tier architecture of user interface (screens), business logic, and data access, which provides a convenient application model from which to build an object model.

14

This table is provided to illustrate that many conversion problems are relatively easy; it does not in any way reflect the sophistication of these tools.

Moving Mainframe Applications to Windows

10

The same is not true for applications built using a 3GL language like COBOL. Statement-level analysis is not sufficient to discover a complete object model. Some converters do not attempt to discover an object model, and settle for basic conversion strategies. Others gather high-level design information by user survey, and couple this with source code analysis to build an object model. More sophisticated tools allow the conversion specialist to adapt the model (and its links to the original source code) to refine the architecture of the resulting application. However, there is no guarantee that even sophisticated conversion tools can build a satisfactory object model for all applications. The engineering principles behind automated language conversion are still a work in progress. Development of standards for interoperability between tools is being coordinated by the Object Management Group, as described in Appendix E.

Vendor solutions
As a market has grown for tools that transform applications from those built for one legacy platform to those built for a more contemporary platform, conversion specialists have emerged. Their principal offering is most often service-led, based on a deep knowledge of specific technologies. This knowledge is supplemented by technology that was developed during prior engagements to help automate application and data transformations. Most conversion specialists work with global and regional systems integrators to scale their solutions. Table 7 provides a representative list of conversion specialists and the primary mainframe languages that they can convert.

Table 7. Language conversion tools

Vendor
Anubex Asysco ATERAS BluePhoenix Solutions Cornerstone EZ Legacy Forecross Freesoft Idea Integration Information Analysis Infosol Jazillian Keous Solutions

Technology
SLAM LION DB-Shuttle LanguageMigrator G4-Technology EZ Target Convert/ADSO, Convert/CSP, Redirect/COBOL Code Liberator Rules-Based Transformation Engine, LincXGEN filter ICONS Phoenix Technology Jazillian Keous toolbox

Mainframe Languages
Unisys LINC, COBOL

15

ADSO, COBOL, JCL, Natural

ADSO, Assembler, COBOL, Focus, JCL, Natural ADSO, Assembler, COBOL, COOL:Gen, CA Ideal, Mantis, Natural, PL/I Assembler, COBOL, Mantis, PL/I , RPG COBOL, JCL, Natural ADSO, CSP, COBOL COBOL, Natural, RPG Unisys LINC, COBOL CA Ideal GCOS COBOL & JCL C, C++, COBOL Assembler, COBOL

15

Many of these vendors also convert other mainframe and non-mainframe languages that are not listed here.

Moving Mainframe Applications to Windows

11

Legacy Software Downsizing Make MetaWare move2open Micro-Processor Services MigrationWare Millenium Technics MOST Technologies MSS International PBSI PKS Quipoz Relativity Technologies Semantic Designs Software Migrations SoftwareMining Sykora-ML The Software Revolution Transoft (IRIS) Trinity Millenium Group

PowerDrive TLM Refine I2C Various Various Various OnTarget migrate!COBOL, migrate!LINC .NETigration Migration Tools 400 EGL, SmartEGL Transformation Engine Transformation Assistant DMS FermaT COBOL Translation Toolkit ML-iMPACT JANUS
2

Application Master, COBOL, SCL COBOL, JCL, Natural, PL/I, RPG C, COBOL, FORTRAN, PL/I CA Ideal, MetaCOBOL Assembler, COBOL, PL/I CSP, Easytrieve, CA Ideal, Natural, Mantis Algol, COBOL, LINC, RPG Natural COBOL, LINC RPG, CL COBOL, Natural, RPG COBOL, CSP, LINC, Mantis, Natural, PL/I, RPG COBOL Ada, C, C++, COBOL, FORTRAN, JCL, Natural, Pascal Assembler COBOL RPG, CL Ada, Assembler, C, COBOL, FORTRAN, JCL, Magna X, Natural, PL/I COBOL Most mainframe languages

Legacy Liberator TMGi-SAT, TMGi-BRH

Appendix B shows the most common capabilities that are provided by language conversion tools, and includes profiles of three vendors that offer language conversion solutions. The following case study is an example of an automated conversion from Software AGs Natural to Java and C#.

Case study: GDC A/S

GDC A/S is a major distribution and logistics company for home entertainment and electronics in Scandinavia. A computer system developed in the 1970s using Software AGs Adabas/Natural on the IBM System/370 provided purpose-built sales, rental, stock management, distribution, and copyright management functions. Maintenance and operations were outsourced to an external service provider many years ago. GDC looked at various options to reduce the U.S.$1.4 million annual charge for hosting and maintaining its system, including a version of the application running on IBM System p computers and a commercial enterprise resource planning (ERP) package. Both options required significant customization to meet
Moving Mainframe Applications to Windows 12

GDCs needs. A $2.6 million rewrite proposal was ruled out on cost grounds. GDC considered moving the outsourcing contract, but could not locate a supplier with sufficient Adabas/Natural skills. Eventually the company conducted a proof-of-concept project with BluePhoenix Solutions, and decided to migrate the application to a Windows .NET-based platform to be operated and maintained internally. BluePhoenix tools for converting Adabas/Natural to Java were more efficient than those for C#, and time was a critical factor for GDC. As an interim measure, the migration team converted the 540,000 lines of Natural code and screens into Java and JSP, and the Adabas database to SQL Server; JCL and Assembler code was rewritten by hand. The replacement application went into production in May 2007 (less than a year after the project started) on two 8-way application servers and two 8-way database servers that are running the Windows Server 2003 operating system. GDC has reduced its annual costs to $360,000 with this move. This includes the cost of internal staff dedicated to maintaining and operating the application. The company reports that the converted code is not as easy to maintain as custom-coded Java. The next phase, to convert the original Adabas/Natural application to C#, is planned for 2008.

Moving Mainframe Applications to Windows

13

Services and tools to rewrite mainframe applications

Earlier we stated that organizations consider one, or possibly many, of a number of options to move their legacy to a new platform. These were: Rehost the application with minimal change on a new platform. Convert the application using tools to automate source changes. Rewrite the application to exploit new languages and platforms. Replace the application with a commercial package.

Rewriting a large mission-critical application is a complex undertaking that may involve greater costs and a greater risk of failure than other solutions. This does not mean that this is not a viable solution, but it does suggest that such projects should be undertaken with care, and only when lower-risk solutions have been ruled out. One such lower-risk solution is to consider implementing a standard (off-the-shelf) package to replace a custom application. Standard packages are available for a wide range of cross-industry business needs such as HR, payroll, finance, stock control, resource management, and customer relationship management (CRM). Packages are also available for the specific needs of industries such as banking and insurance. Generally, organizations choose to rewrite an application when there are compelling business reasons to upgrade the functional characteristics of the application. Consider, for example, modernizing a single currency application to support business expansion into global markets. This upgrade is likely to involve widespread changes to enable operation in multiple currencies, as well as significant new functionality to handle currency exchange and localized tax and import/export regulations. Rewriting may be the best option; cost and risk can be minimized with judicious selection of a services partner and legacy analysis tools.

Service providers
Most large systems integrators and outsourcing firms offer modernization services. Table 8 shows a representative selection of global service providers that have built modernization practices to focus internal expertise and resources on clients modernization projects. These firms supplement technical implementation services with consulting services to develop a modernization plan based on an initial assessment phase. The level of assessment offered by these companies ranges from a focused technology assessment (for example using application portfolio management software) to a high-level strategic business and technology plan for a phased, multiyear IT modernization initiative.

Moving Mainframe Applications to Windows

14

Table 8. Global service providers with modernization practices

Accenture Atos Origin BT Global Services Capgemini Cognizant CSC Deloitte DTS Latin America Technology EDS (Electronic Data Systems) Fujitsu Services / Fujitsu Consulting Getronics HCL Technologies HP Consulting IBM Global Services Infosys LogicaCMG / Unilog Satyam Computer Services Sonata Software Tata Consultancy Services T-Systems Unisys Wipro Technologies

Appendix C includes profiles of two global service providers that offer modernization services. There are also many regional service providerstoo many to list in this paperthat have developed modernization capabilities. Many of the language conversion tool vendors that are listed in Table 7 also provide assessment and implementation services to rehost, convert, or rewrite mainframe applications.

Legacy analysis tools

Modernization planning services invariably include portfolio analysis to determine an approach to modernizing each application based on options similar to those discussed above. Service providers have built alliances with technology vendors to provide the tools necessary to underpin portfolio analysis and each type of modernization engagement. Legacy analysis tools help to mitigate the cost and risk of rewriting applications by: Providing core data for application portfolio assessment, which helps organizations decide on a course of action. Application analysis and business rule discovery, which feed new design documents to minimize re-specification effort and to ensure functional equivalence.

Table 9 presents a representative selection of application analysis tool vendors, and lists the mainframe languages that they support.

Moving Mainframe Applications to Windows

15

Table 9. Application analysis tools

Vendor
ASG Software Solutions BluePhoenix Solutions Cast Erudine Evolveware EZ Legacy Freesoft IBM Corporation MetaWare Micro Focus Progeni Raincode Relativity Technologies SEEC Semantic Designs Software AG SoftwareMining Transoft (IRIS) Trinity Millenium Group

Product
ASG-Existing Systems Workbench IT Discovery Application Intelligence Platform Legacy Elimination Tool Legacy Rejuvenator EZ Source Portfolio Liberator WebSphere Studio Asset Analyzer Refine Enterprise View 4Sight Raincode Engine Modernization Workbench Application Manager DMS Natural Engineer BRE toolkit evolveIT TMGi-SAT, TMGi-BRH

Mainframe Languages
COBOL COBOL, JCL, PL/I, Natural, Easytrieve, ADSO, Mantis, Telon C, C++, COBOL, JCL (Not applicable) Assembler, COBOL, Natural COBOL, JCL, Natural, PL/1 COBOL, Natural, RPG Assembler, C, C++, COBOL, PL/I C, COBOL, FORTRAN, PL/I COBOL, JCL, PL/I Algol, COBOL, Natural, Mantis, Pacbase, XGEN Ada, APS, C, C++, COBOL, CA Ideal, PL/1 Assembler, C, C++, COBOL, JCL, Natural, PL/I, RPG COBOL, Natural, PL/I Ada, C, C++, COBOL, FORTRAN, JCL, Natural, Pascal Natural, COBOL, JCL COBOL COBOL Most mainframe languages

The most common approach to rewriting an existing application is to use application analysis tools to reverse-engineer the application to a good-enough model. Such a model may include record definitions, data flow analysis, business rules, process flows, and use cases. The model need not be as complete as that needed to build a new application, but it provides a starting point that is then refined from existing and new business requirements. A completed application model then provides the foundation for the development of the new application by using trusted development tools and processes. This approach differs from the early phases of a conversion project by allowing greater freedom to modify application architecture and behavior. In building the model by analysis, it is important to document those facets of the existing application that are to be preserved, and those that are not, providing a basis for selective inclusion. Application analysis tools do a good job of identifying data structures, data flows, and process diagrams from source code. Many of these tools also offer business rule mining and business process identification. These tasks require some level of heuristic analysis of source code patterns. Manual intervention is
Moving Mainframe Applications to Windows 16

needed to identify house coding patterns and to guide the discovery process. Even so, the results may be disappointing if the source code is not well structured. Appendix D includes profiles of two vendors that have contrasting approaches to discovering the model of an existing application. Relativity Technologies adopts the conventional (white-box) source code analysis approach, whereas Erudine offers a black-box approach to cloning a legacy application, by observing inputs and outputs of the operational system. The following case study is an example of collaboration between a service provider and a tool provider to build a model of a legacy application that was then used as the basis for new development.

Case study: The Schwan Food Company

The Schwan Food Company is a frozen food manufacturer based in Minnesota, with about 22,000 employees. The company sells its products to stores, restaurants, schools, cafeterias, and directly to households in the United States. In addition to running SAP on Windows Server, the company operated a 450 million instructions per second (MIPS) Hitachi mainframe running over 30 custom applications (which constituted about 7 million lines of code) built over a 25-year period. In 2003, when Schwan wanted to add new business models to its IT systems, the mainframe lacked the capacity needed for growth, and the current applications lacked flexibility. The IT team rejected a move to IBM System z mainframes on the grounds of cost increases, and chose to consolidate operations on Windows Server. To reduce the diversity of technologies in use and to avoid future skills issues, the company chose to rewrite the applications in C# with help from Cognizant and Relativity Technologies. In the first phase, the project team built an inventory of existing applications, and assessed them against key business and technical criteria to create a project roadmap. This led to a series of five phased releases; the first release provided common components and was followed by functionality based on groups of related applications. The existing applications were a mix of CICS COBOL and batch COBOL using DB2, and with some CSP and other tools from CA and Rocket Software. Modernization Workbench by Relativity Technologies was used to reverse engineer the existing applications into models from which the replacement applications were to be built. Existing screens were converted to HTML, preserving flow to minimize retraining, and DB2 data was moved to SQL Server. Maintenance changes to mainframe applications were synchronized manually during the development of their replacements. The first release was completed in six months, and the remaining four releases completed almost a year later. The team asserts that use of application understanding tools reduced the overall effort by 20 percent. The new .NET-based applications comprise about 1 million lines of C# source code running on 22 Windows Server-based machines. The Hitachi mainframe has been decommissioned and is now located in a museum in Minnesota.

Moving Mainframe Applications to Windows

17

Analysis of language migration options

This paper explores three approaches to the programming language issues that are involved when migrating mainframe applications to the Windows platform. In addition to conducting Web-based research on a large number of vendor solutions, we have interviewed representative vendors in each of the three categories of language migration, and gathered detailed product and feature information. This was supplemented by interviews with end users who have undertaken major projects using these approaches. The analysis that follows assumes that a decision has been taken to move mainframe applications to the Windows platform; for example, to consolidate applications on that platform. Other papers published on 16 the Microsoft mainframe Web site address the issue of platform choice. We look at the relative strengths of each of these approaches to provide a basis for selecting the right approach to suit varying business needs. We analyze their strengths in terms of five business issues that have an impact on an organizations use of IT: cost, risk, skills, agility, and innovation. Most observers agree that businesses benefit when IT costs and risks are minimized, and when IT can support business agility and innovation. However, the debate continues as to whether mainframe language skills are at risk through programmer retirement, and whether use of these languages represents a positive or negative value to the business: There have been numerous reports that mainframe skills are at risk because of the age profile of this community. Surveys reveal that the average age of a COBOL programmer is about 45, and predict a gradual decline over the next 15 to 20 years. This is not a crisis in global terms (though there may be localized shortfall), and it is likely that business needs will create demand and fuel the required training. There is also a perception that mainframe programming languages are not suited to modern application development. For the most part, this perception is founded on technical preferences that have little relevance to business issues. Standards for service-oriented architecture (SOA) and Web services have finally delivered a usable form of language and platform neutrality for the delivery of IT services. The issue can now be debated in the context of what IT choices make sense for the business. There are many other factors that CIOs must consider as well, as they structure their plans for future skills investment, such as outsourcing, packages, and hosted services.
17

In this paper we report on the skills impact of each approach; businesses must decide the relative importance of language choice according to their own priorities.

16 17

See www.microsoft.com/mainframe. Note that the solutions proposed in this paper do not depend on mainframe infrastructure skills (such as z/OS configuration and administration).

Moving Mainframe Applications to Windows

18

Windows compilers for mainframe languages

The observations in Table 10 relate to the use of COBOL, FORTRAN, PL/I, and RPG compilers for moving mainframe applications to Windows. These compilers offer a high degree of language compatibility, but do not directly address issues concerned with batch processing, transaction processing, or database environments. There are also vendors (see Table 7) that convert 4GL applications and mainframe Assembler programs to COBOL, which can then be moved to Windows using one of these compilers. Commercial compilers that generate MSIL code, or that generate x86, x64, and IA64 native code for Intel and AMD processors, incorporate sophisticated optimization techniques; application performance compares favorably with applications written in more contemporary languages. Compilers that are hosted as Visual Studio languages are fully integrated, and provide equivalent functionality to C# and Visual Basic .NET. However, vendors typically do not provide mainframe language examples to supplement the Visual Studio online Help files. Programmers are given guidance on language-specific naming conventions and data typing rules for accessing .NET Framework components.

Table 10. Business issues using compilers to rehost applications

+ Product licenses and maintenance fees are moderate. IT may require training on new platform, but little or no end-user training. Services costs are small, projects are typically < 10 work-years. Risk is minimized because there are no changes in application function. Application can be redeployed on the mainframe if necessary. Number of developers with mainframe language skills may decline. Legacy tools market may decline, resulting in support issues. May continue to use existing mainframe language skills. A new technology challenge motivates legacy developers. Existing developers know the business and the application. The introduction of new skills is delayed. Applications may be re-used as components in SOA. Mixed language development helps optimize resources. Agility may be hampered by mainframe application structure. New deployment platform may enable some integration/enhancement. Business value of the application is not increased.

Cost (low)

+ + +

Risks (low initially)

+ +

Skills (retain)

+ + +

Agility (low/moderate)

+ -

Innovation (low)

+ -

Moving Mainframe Applications to Windows

19

Language conversion tools

Language conversion tools are generally not sold as licensed productsthey are provided to the application migration team by a specialist vendor. The tools require a migration specialist to follow a strict migration process and to customize the conversion rules based on the specific needs of the project. When the conversion is complete, the conversion tool is no longer required, because the end user maintains the application using tools and compilers designed for the target language. Table 11 summarizes the business issues that arise when adopting a language conversion approach to moving applications to the Windows platform.

Table 11. Business issues using language converters

+ Cost (low) + + + Risks (moderate) + Skills (replace) + Agility (moderate/high) + + Innovation (low) + Product licenses and maintenance fees are moderate. IT may require training on new platform, but little end-user training. Automation keeps service costs down, projects typically < 10 work-years. Risk is minimized because there are few changes in application function. Application cannot be redeployed on the mainframe. Automation may be incomplete, resulting in unforeseen project work. New application code (such as procedural C#) may be difficult to maintain. Step change accelerates adoption of new skills. May be hard to retrain programming staff in new language. Must train new staff in business and application knowledge. Applications may be re-used as components in SOA. Development is more productive using Microsoft software and tools. Application models and structure better able to support agile development. New development platform may enable further integration/enhancement. Business value of the application is not increased.

Services and tools to rewrite mainframe applications

Rewriting a mainframe application to achieve functional improvements provides the opportunity to upgrade the underlying language and platform, and to build the replacement using a more agile architecture (such as SOA). Clearly, these are more ambitious projects (meaning higher cost and risk), but the rewards in terms of business agility and innovation may be greater. Rewriting mainframe applications simply to build like-for-like functionality may not be cost-effective unless it can be shown that ongoing costs are reduced. When considering a rewrite, it is always prudent to look first at the available packages that may be able to meet the business need more quickly and with lower risk. However, even where there are no packages that can satisfy the business need directly, a new application can take advantage of packaged functionality in the form of framework classes (.NET or the Java EE platform) or commercially available libraries or applications such as database reporting functions, Web-based collaboration software, process orchestration, and business rules engines. In the case of the Schwan Food Company, the 7 million lines of

Moving Mainframe Applications to Windows

20

COBOL code were replaced with 1 million lines of C# code, which represents a considerable simplification (and thus cost reduction) in ongoing development and maintenance. Table 12 shows the business issues that are involved when rewriting mainframe applications. In this analysis, it is assumed that functional changes will be allowed or encouraged to make use of the new platform, to provide a new user experience and to improve application architecture. This of course will expand the scope and the resulting cost of the project. This analysis does not take into account the additional cost of functional improvements, which vary case by case.

Table 12. Business issues rewriting mainframe applications

+ Cost (high) + Risks (high) + Skills (replace) Agility (high) + + + + Analysis tools reduce the cost of requirements gathering. Use of packaged functionality reduces ongoing maintenance costs. IT requires training on new platform; end users require application training. Extensive development and testing, projects typically > 10 work-years. Significant technology changes may give rise to unforeseen costs. New application and database reduce reliability (not yet productionhardened). Synchronization with ongoing legacy improvements is lost. Step change accelerates adoption of new skills. May be hard to retrain programming staff in new language. Must train new staff in business and application knowledge. Development is more productive using Microsoft software and tools. Application models and structure are better optimized for agility. Business value of the application is increased. Improves IT alignment; better anticipates new business requirements.

Innovation (high)

Table 13 shows a summary of the business impact of these three approaches to language migration.

Table 13. Business issues: summary

Compilers
Cost Risks Skills Agility Innovation Low Low initially Retain Low/Moderate Low

Converters
Low Moderate Replace Moderate/High Low

Re-write
High High Replace High High

Moving Mainframe Applications to Windows

21

Conclusions
Application modernization has emerged in the post dot-com era as a significant market. In 2003, Giga (now part of Forrester) estimated that there were more than 180 billion lines of COBOL code in production 18 use . If IT organizations spend an annual average of 10 cents per line of code to modernize mainframe systems, we can see that this is indeed a multi-billiondollar market. It is hardly surprising to find that this market is served by a large number of hardware, software, and services vendors across all geographies and industry sectors. A significant part of that market serves the needs of IT organizations that choose to consolidate operations on a new platform. Some organizations adopt a package solution; many choose one (or a combination) of the three migration options discussed in this paper: rehosting mainframe applications, converting them to a new language, or rewriting them. The technology that underpins these solutions is not new: technology for all three solutions has matured and stabilized over a period of 20 years or more, and all three solutions have notched up many hundreds of successful projects. In this context, you should not feel that these solutions present any greater technology risk than other application development tools and techniques. The risk that does arise is the risk that these projects are undertaken without fully analyzing the impact they may have on the business. These projects affect existing, stable, core systems that run the business; project failure often leads to significant negative business impact, such as revenue loss or customer dissatisfaction. Failure with new software development does not carry the same burden. The bottom-line inference from the analysis above is that none of these solutions provides both low cost and low risk and delivers high levels of agility and innovation. Each solution sits at a different point on the line of compromise between these extremes. Rehosting using compilers carries the lowest cost and lowest risk, and at the same time delivers the lowest incremental agility and innovation. Application rewrites deliver the gain, but not without the pain. To help you understand the difference in cost, expect to pay in the region of U.S.$2 per line of code to use conversion tools to turn a COBOL application into C#, and substantially less than that to simply keep the code in COBOL on the new platform. If you want to engage a services firm to rewrite the same application, 19 the cost could be as much as $10 per line of code . You should also take into account the additional cost to retrain users in new processes when application changes are more fundamental.

Looking forward
Using compiler technology to implement mainframe applications on Windows is a well-established technology practice. Improvements in the levels and scope of language and subsystem compatibility will, over time, make these projects easier and less costly. While this solution will be commoditized, rehosting mainframe applications will appeal less in the future as the skills issue looms. Though the service-based approach to application conversion fits the current needs of users who consider modernization to be a specialist activity, IT organizations will come to expect greater levels of automation in their desktop development tools. Many conversion specialists have introduced, or are about to introduce, sophisticated tools that are licensed directly to end users or service providers. This is likely to become a growth market.

18 19

Market Overview: Web-to-host ToolsA Crowded Market, but Compelling Technology. Giga Information Group, March 2002. Source: Legacy Directions Limited, 2008.

Moving Mainframe Applications to Windows

22

The high cost of rewriting mainframe applications will certainly add fuel to the conversion tool market. Services companies will be forced to adopt more and more automation into their practices to scale their delivery capability and remain competitive. This will strengthen relationships between service providers and vendors of automation tools in the near term. Over time, service providers will develop or acquire automation tools to hold down project costs. At the same time, as platform providers embed more high-level, reusable functionality into middleware and tools, as software vendors deliver more commercial packages and SOA components, and as software-as-a-service (SaaS) components come online, less custom code is needed to build business applications. This will reduce the barriers to rewriting mainframe applications, and increase the adoption of more contemporary solutions.

Moving Mainframe Applications to Windows

23

Appendix A: Compiler product profiles

ASNA Visual RPG Amalgamated Software of North America (ASNA) has been providing software for IBMs System i (and its predecessors, the iSeries and the AS/400) computers since 1982. The company, a founding member of the Midrange Alliance Program, was acquired by BluePhoenix Solutions in August 2007. ASNA products were developed to provide visual programming tools for RPG developers, and to integrate System i databases and applications with Windows clients, browsers, and mobile devices. Many customers have migrated applications to Windows and integrated them with the .NET Framework. The largest migrated application in production is about 2 million lines of code, with larger projects in progress. ASNA Monarch is a suite of products for migrating System i RPG programs to .NET. The target language is ASNA Visual RPG for .NET: a language plug-in for Microsoft Visual Studio that generates managed, verifiable code for MSIL and integrates with Visual Studio. Interactive RPG programs are converted to ASP.NET applications, and batch programs are converted to console applications. Monarch includes a Windows-based migration tool called the Cocoon, which provides cross-referenced migration information and visual graphing of program dependencies. Visual RPG uses an enhanced RPG syntax that supports the object-oriented capabilities of .NET. RPG applications can be further enhanced using C# or Microsoft Visual Basic .NET. Applications that are migrated using Monarch can connect to either the System i DB/400 database or Microsoft SQL Server through ASNA DataGate. DataGate supports server-side database security and provides RPG record-level file access to SQL Server tables without extensive modifications to the original RPG source. Fujitsu NetCOBOL for .NET The legacy modernization group at Fujitsu Computer Systems Corporation provides software products for developing and deploying mainframe applications on Windows. Fujitsu COBOL for Windows was first released in the United States in 1992. Fujitsus current products, which complement the companys Windows servers and storage products, are NetCOBOL for .NET, NeoKicks (a transaction processing monitor for CICS applications), NeoBatch (a batch processing system), and NeoSort (a mainframecompatible SORT program). Another tool helps convert embedded SQL for DB2 to SQL Server, and a plug-in for EZ Source (from tools vendor EZ Legacy) provides source code scanning for estimation and planning purposes. With these tools, Fujitsu targets the IBM mainframe COBOL customer base to transition applications to systems based on .NET technology and to further modernize them using Visual Studio. Fujitsu has drawn on its own experience with mainframe COBOL compilers to build NetCOBOL for .NET. The compiler, which generates managed, verifiable code for MSIL, handles most COBOL 85 and COBOL 89 addendum features directly, and also provides a good level of compatibility with IBM COBOL dialects. OO COBOL syntax based on the COBOL 2002 standard with extensions provides the means to use .NET Framework classes and to create new COBOL classes. The compiler can be operated as a standalone product or integrated with Visual Studio 2005 Standard Edition (which is shipped as an option). Although some customers prefer to undertake a migration project themselves, Fujitsu recommend a services partner to provide specialist migration and project management services. The legacy modernization group at Fujitsu works with a number of global and regional SIs, including its own Fujitsu Services and Fujitsu Consulting.

Moving Mainframe Applications to Windows

24

Micro Focus Net Express Micro Focus describes its products as Enterprise Application Modernization software. Its software products fall into three categories: Application Development, Application Portfolio Management, and Application Modernization software. Modernization solutions include hardware platform migration and software platform rationalization. Micro Focus Net Express includes options to compile COBOL to managed, verifiable code for MSIL or to unmanaged code for Windows. The compiler inherits a high degree of compatibility with IBM mainframe COBOL dialects from Micro Focus long tradition with mainframe development tools. OO COBOL syntax based on the COBOL 2002 standard with extensions provides the means to use .NET Framework classes and to create new COBOL classes. Net Express includes an IDE for application development and also integrates COBOL into Visual Studio 2005 Standard Edition, which is included. Although Micro Focus sells tools to run IBM CICS, IMS, and JCL applications on Windows without change, these currently operate only in the unmanaged Windows environment. To compile these as .NETbased applications, the code must first be converted to use equivalent features of the .NET Framework. Alnova Financial Solutions moved a banking application consisting of 11 million lines of CICS COBOL code to the .NET platform to provide a solution for small- to mediumsized banks. The core of this application, over 80 percent of the total code base, was compiled for the .NET platform without change. Micro Focus works with the major global integrators and a large number of regional SIs to help customers modernize applications and development practices. Micro Focus has also formed the Migration and Transformation Consortium (MTC), whose members provide specific platform, language, and database re-engineering solutions. Silverfrost FTN95: Fortran for Windows Silverfrost Limited provides a compiler called FTN95: Fortran for Windows. FTN95 was initially developed by Salford Software, one of the original VSIP partners that integrated FTN95 with the first release of Visual Studio .NET. Silverfrost FTN95 supersedes Salford FTN77, Salford FTN90, and Salford FTN95. The company offers academic and commercial licenses for FTN95 and a free version for non-commercial use. The product provides tools and API support to build console-based native Windows-based and .NETbased applications. The company Web site includes a case study for the University of Manchester School of Biological Sciences; there, Simfit, a package consisting of 1 million lines of FORTRAN code for simulation, curve fitting, statistical analysis and graph plotting, was migrated to FTN95 and uses a GUI package called Salford ClearWin+. FTN95 is a Fortran 95compliant compiler for Windows that generates managed and unmanaged code. Managed code is not verifiable, but run-time code correctness can be checked by using CHECKMATE. Unmanaged executables are built using a linker provided by Silverfrost (dbk_link). FTN95 also handles the Fortran 77 and Fortran 90 standards, and many vendor-specific legacy language features. It includes support for 32-bit, 64-bit, and 80-bit arithmetic. Plug-ins provide complete language integration with Visual Studio 2003, 2005, and very soon 2008. A lightweight IDE consisting of an editor and a debugger can be used as a standalone product.

Moving Mainframe Applications to Windows

25

Appendix B: Conversion tool profiles

Language conversion tools provide the basis for phased conversion from a 3GL legacy language to Java or C#. This appendix first lists the capabilities that may be provided by language conversion tools. Profiles of three vendors and their conversion tools are then presented. Language conversion tool capabilities Ability to identify and inventory source code assets, and build data models, data flow diagrams, process flows, and other reports Ability to help capture and document the original application structure by user survey, and to link this to source code already analyzed A language-neutral repository supported by parsers to acquire, combine, and abstract application knowledge from multiple source languages and surveys Guided discovery of a three-tier application architecture from 3GL applications to form the basis of an object model for regeneration Refactoring to remove dead code, consolidate redundant processing, and refine target object model Ability to populate Unified Modeling Language (UML) tools (for example, IBM Rational tools) with a target application model Customizable conversion rules to suit specific coding platforms, third-party application services, and the development standards that are used to build the source application Ability to refresh the converted application rapidly from source code that is undergoing parallel maintenance or enhancement Conversion of source code that was accessing flat files (such as VSAM) or legacy databases (such as IMS, IDMS, or Adabas) to code for relational or OO database access (such as JDBC or ODBC), and generation of database definition (DDL) statements. Conversion of green screens to Windows user interface screens or Web forms, and generation of code for the presentation tier (JSP or ASP.NET) Ability to generate C# or Java source code for running in three-tier Web, two-tier client-server, and traditional mainframe online transaction processing (OLTP) applications Model and documentation of the generated application to ease ongoing development and maintenance, and to provide a maintenance bridge between the legacy application and the new application

ATERAS DB Shuttle ATERAS, founded in 1983 as Sophisticated Business Systems (SBS), initially provided IDMS consulting services; it later developed expertise to convert IDMS applications to relational applications. These projects led to the development of the DB Shuttle technology, which was used to automate the conversion of IDMS ADSO applications to CICS/COBOL with DB2. Since then, the company has added new capabilities for moving applications to new databases and platforms, as well as to perform language conversions. DB Shuttle converts IDMS, IMS DB, Adabas, and VSAM databases to DB2, Oracle, and SQL Server, and includes parsers for ADSO, Assembler, COBOL, Focus, JCL, and Natural. ATERAS is currently investigating requirements for CA Ideal, CA Datacom, Eztrieve, PL/I, and RPG. After a database has been parsed, application analysis tools provide structure views, impact assessment, and a project workbook to guide the conversion. Templates define specific conversions, and can be customized using the proprietary scripting language PowerSkel. Database conversion tools generate DDL for database definition and JCL to extract, format, and clean the data, producing a form that is ready for loading.
Moving Mainframe Applications to Windows 26

DB Shuttle can generate COBOL, C#, Java, and JavaScript. The C# converter, reviewed and verified by Microsoft, uses the Windows Communication Foundation to separate presentation logic from business logic in a three-tier architecture. ATERAS is often called in to help with modernization projects by IBM Global Services, Accenture, and other regional systems integrators. To meet increasing demand, ATERAS plans to offer a DB Shuttle software-as-a-service (SaaS) model to trained partners. BluePhoenix LanguageMigrator BluePhoenix Solutions, a legacy modernization specialist formed 20 years ago, has recently expanded with the acquisition of ASNA, a provider of developer tools for IBM System i and AS/400 computers. Tools include source code analysis, business rule mining, automated language, database and platform migration technologies, remediation tools for pervasive code changes (such as Euro conversions), and a new capability called BluePhoenix Redevelopment to re-architect COBOL applications. About 70 percent of conversions are to Java, but a growing number of conversions are to C#. The largest conversions have been for mainframe applications in the range of 6 to 10 million lines of code, where complex integration of applications requires special attention using code analysis tools. BluePhoenix supports conversion to COBOL, Java, or C#. Automated conversion to C# using LanguageMigrator is supported for COOL:Gen and Natural. BluePhoenix enlists the help of partners for other conversions. The BluePhoenix Redevelopment solution is a combination of tools, methodology, and services to break down monolithic COBOL applications into service layers for user interface, business logic, and data access. 3270 screens are modernized to use graphical controls, and data can be refactored to use abstract data types instead of memory-based COBOL data. Refactoring is performed on the intermediate (abstracted) representation of the application, and facilitates conversion to a new architecture based on OO principles for Java and C#. BluePhoenixs product team develops the companys core automation tools, and contributes to the Object Management Group (OMG) Architecture Driven Modernization Task Force (ADMTF). (OMG is described in Appendix E.) Delivery teams totaling 400 staff are located in the USA, UK, Italy, Denmark, Romania, and Cyprus. Where BluePhoenix lacks a strong local presence, it partners with a local integrator. In some instances, BluePhoenix is subcontracted by a global SI for its tools and expertise in modernization. The Software Revolution Inc (TSRI) JANUS Established in 1995, The Software Revolution Inc (TSRI) offers legacy modernization services to customers in the government and defense industries. Its JANUS toolset is used to automate the modernization of existing applications, converting them from a variety of 3GL and 4GL languages to object-oriented C#, C++, or Java running in .NET or J2EE. TSRI has completed approximately 50 modernization projects, notably for mission-critical systems such as the Ballistic Missile Early Warning System at the U.S. Strategic Air Command, the U.S. government MILSTAR communications satellite, and the U.S. and European air traffic control systems. In one case study, the National Endowment for the Arts had failed in an attempt to rewrite 656,000 lines of Wang COBOL at a cost of U.S.$1.6 million. The application was converted to C++ and Microsoft SQL Server by TSRI in 24 months at a cost of $450,000. In a current project for Northrop Grumman, TSRI is converting over 1 million lines of Tandem COBOL into a combination of C++ and Java running in the Air Force Global Combat Support System (GCSS).

Moving Mainframe Applications to Windows

27

Application conversion is driven by transformation rules to refactor and Web-enable the application; rules developed iteratively refine the resulting OO design. Transformation rules operate on source, intermediate, and target Abstract Syntax Tree (AST) representations of the application. Generators based on source and target AST representations provide hyperlinked as-is and to-be HTML documentation. TSRI is a member of the Mainframe Migration Alliance, the OMG ADMTF, the Enterprise Re-Architecting Consortium, and the Natural Modernization Strategies Information Forum (NAMS-IF).

Moving Mainframe Applications to Windows

28

Appendix C: Service provider profiles

Accenture At U.S.$16.65 billion in revenues for FY06, Accenture is one of the worlds largest services companies. Accenture has 152,000 employees servicing 2,500 clients worldwide. It is organized into five broad vertical market categories (Commerce and High Technology, Financial Services, Government, Products, and Resources). Spanning these are three horizontal expertise overlays focusing on Management Consulting, Systems Integration & Technology, and Outsourcing. Accenture responds to client requests for application renewal (AR) services with a practice developed in its Systems Integration & Technology group. In 2004, Accenture pooled its dispersed experience and technology relating to application renewal to create the AR practice. The company reported about 300 projects in fiscal 2006, up 200 percent from the previous year. Projects are serviced by 3000 professionals with specialist skills in application renewal who work within, and are assisted by, Accentures global delivery network of 58,000 professionals. Accentures core project methodology is defined and maintained by a team of 70 experts; this team has been augmented by application renewal experts. At a high level, AR proceeds through four phases: I. Assess application and platform portfolio based on functional, financial, and technical measures. II. Determine a renewal approach: sustain, decommission, consolidate, replace, re-platform, enhance, or remediate. III. Prioritize projects to create release, roadmap, and implementation plans. IV. Design and implement tactical and strategic solutions and ongoing portfolio management. Accenture cites the health payer industry as an example of an industry sector facing significant application renewal challenges. The industry has experienced much consolidation through mergers and acquisitions activity, which results in cumbersome and overlapping application portfolios. New business needs, regulatory change (National Provider Identifier remediation), and Web enablement add to these problems. Infosys Technologies Limited Infosys Technologies Limited, with over 80,000 staff providing global consulting and IT services, is one of the largest Indian IT outsourcing companies. The companys technology offering, called Catalytic IT, seeks to fund IT transformation through a phased implementation that delivers incremental cost savings. In the first phase of an engagement, the Infosys team works with the client on a portfolio assessment to identify and plan a number of independent business-focused transformation initiatives. Legacy modernization is one of the initiatives to reduce costs by rationalizing IT services and platforms. The company has defined four approaches to legacy modernization: platform rehosting, application reengineering, application integration, and package implementation. Consolidation to a strategic platform may drive a rehosting, a re-engineering, or a package implementation project. Choice of target language is determined by the customers strategic development platform; COBOL, C#, and Java are the most common choices. This in turn guides the selection of either rehosting to preserve COBOL or reengineering to a new language. For re-engineering projects, a joint team determines architecture, platform, and process requirements through interviews, and captures these using Infosys Influx (a business process management tool). Process views are supplemented with existing data models and other views using legacy analysis tools such as those from Relativity Technologies, SEEC, or Micro Focus; Infosys has integrated Influx with Relativitys Modernization Workbench to provide traceability between existing and new functionality. The new application is built from these models using conventional coding techniques in C# or Java. Although Infosys supports all platforms, it has created a number of technology centers of excellence, one of which is the Microsoft Technology Centre, part of a joint IT initiative between Infosys and Microsoft.
Moving Mainframe Applications to Windows 29

Appendix D: Analysis tool profiles

Erudine Legacy Elimination Tool Erudine, a privately held ISV based in the UK, was formed in 2002 as Rippledown Solutions to develop rules-based software development tools. The first prototype toolkit was produced in 2003; version 1.0 of the Behaviour Engine was released in 2005. The company has worked closely with the European Aeronautic Defence and Space Company (EADS) and ATOS Origin on early projects to prove the technology and concept. Gartner evaluated Rippledown Solutions as a visionary in the Magic Quadrant for Business Rule Engines in 2005. Using direct knowledge capture, Erudine claims to shorten development times drastically. The company offers the Legacy Elimination Tool as a way to clone legacy system behavior more quickly than other methods do. No source code is required, because the tool compares its own inputs and outputs against those of the legacy system to help the user match the two using successive behavior refinements. The tool captures behavior as rules (conditional statements), each accompanied by the reason for the rule. The rules operate against data types and a data model that are defined as part of the applications basic framework. A rule is effectively a test case, and development proceeds by constructing as many test cases as required to describe the system in terms of its responses to different inputs. The rule development system identifies conflicts between test cases and presents the reasons previously captured to guide the definition of a refinement. The Legacy Elimination Tool can be used to create a model and rulesa module that acts as requirements for a new system constructed using conventional application development tools. Alternatively, the model and rules can be executed directly by the Erudine Behaviour Engine, which is a Java Virtual Machine (JVM)compliant application. This module constitutes the business logic in a threetier architecture that also requires the addition of user interface and data access layers. Relativity Modernization Workbench Relativity Technologies, a privately held software vendor based in Raleigh, North Carolina, offers tools for enterprise application modernization and application portfolio management. The company was founded in 1997, and has approximately 140 employees globally. Modernization Workbench contains a suite of tools that are underpinned by a knowledge base that centralizes technical and business information collected from source code, subject matter experts, and other tools. Relativity defines a modernization life cycle that starts with understanding technical and business information about applications. These insights help users to decide where to focus improvement initiatives and support subsequent modernization and maintenance activities. The company helps clients to construct application models and requirements from a variety of sources prior to manually writing a new application. Modernization Workbench includes application analysis, APM dashboards, restructuring, and refactoring tools, tools to identify business rules and candidate structures for re-use in an SOA environment, assisted UML modeling, and a module to convert application code to Java. IBM sells a version of the workbench called the IBM Rational Transformation Workbench. Relativity has also built the workbench into an Eclipse plug-in for Rational Developer for System z. Relativity is an active participant in the OMGs Architecture Driven Modernization Task Force (ADMTF), and has established relationships with a broad range of technology and service companies, including most of the leading system integrators.

Moving Mainframe Applications to Windows

30

Appendix E: The Object Management Group

The Object Management Group (OMG), a not-for-profit IT industry consortium, is best known for its 20 Unified Modeling Language (UML) and CORBA standards. In 2003, a group of vendors came together under the OMG umbrella and became the Architecture Driven Modernization Task Force (ADMTF). The mission statement of the ADMTF is to create specifications and promote industry consensus on modernization of existing applications. Historically, modernization software vendors have built unique and innovative capabilities, but users were unable to make use of the combined strengths of these tools by integrating them. The ADMTF is developing standards to support the creation and use of interoperable tools to improve the effectiveness of modernization projects. These standards address the need for a common view of what information can be extracted from existing applications, and how such information can be visualized and processed. The ADMTF has defined a roadmap of seven standards packages (specifications). These packages and their current status are summarized in Table 14.

Table 14. Business issues using language converters

Proposal
Request For Proposal 1 RFP 2 RFP 3 RFP 4 RFP 5 RFP 6 RFP 7

Package
Knowledge Discovery Meta-Model (KDM) Abstract Syntax Tree Meta-Model (ASTM) Analysis Package Software Metrics Meta-Model (SMM) Visualization Package Refactoring Package Transformation Package

Status
Adopted April 2006 (now working on next revision) Proposal under review (adoption planned March 2008) RFP issued December 2007 Proposal under review (adoption planned March 2008) To be addressed To be addressed To be addressed

The ADMTF consists of about 50 member organizations, including major industry players and a balance of modernization software vendors and service vendors. Four separate subgroups of the ADMTF are working on the first four proposals. It is producing a white paper on the subject of Levels of Abstraction, which may result in changes to the roadmap proposals on visualization, refactoring, and transformation. The KDM package provides an XML Metadata Interchange (XMI) schema that can be used to import and export application information between tools. This specification includes software artifacts such as systems, programs, screens, databases, and selected program-level representations, coupled with business domain knowledge. IBM, KDM Analytics, Relativity, and Unisys are among the vendors currently working toward implementing this specification in their application analysis tools. The ADMTF is also collaborating with the OMG Business Modeling and Integration Task Force to help link existing artifacts with new requirements.

20

Common Object Request Broker Architecture

Moving Mainframe Applications to Windows

31

The ASTM package will provide the statement-level information that is necessary for a detailed data analysis and flow analysis of existing code. ASTM will not define language conversion rules, but will provide the level of detail necessary to generate source code. One of the goals of the ADMTF is to build models from existing applications that are sufficient to forward-engineer new applications using modeldriven architecture (MDA) tools. The acronym reversal from ADM, a form of reverse-engineering, to MDA (which came first) is no accident!

Moving Mainframe Applications to Windows

32

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This research note is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2008 Microsoft Corporation. All rights reserved. Microsoft, SQL Server, Visual Basic, Visual C++, Visual Studio, Windows, and Windows Server are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.

Moving Mainframe Applications to Windows

33