moving mainframe applications to windows

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.

1 Moving Mainframe Applications to Windows 1

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


Introduction

According to a 2003 report by the Aberdeen Group1, 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

needs. In a September 2006 report2, 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 IBMs Legacy Application Antiques Road Show. Aberdeen Group. April 2003.

2 The Legacy Application Modernization Benchmark Report. Aberdeen Group. September 2006.


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 report3, 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.

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.


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 Windows-

based solutions for batch processing4 and mainframe-compatible transaction processing

5. 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 See Job Scheduling on Windows at www.microsoft.com/mainframe.

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


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

4GL mainframe programming languages

Ada ADS/Online (ADSO)

Algol Application Master

C, C++ APS

COBOL CA Ideal

FORTRAN COOL:Gen

LINC (Unisys) CSP

Pascal DYL-260/280

PL/I Easytrieve Plus

REXX FOCUS

RPG 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.


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.


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. How-

ever, these applications can communicate with .NET-based applications via a special interface. It is also

possible to create .NET-based assemblies6 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 Product Generated code

Acucorp (Micro Focus) ACUCOBOL-GT x867

Envyr Corporation ICOBOL8 x86

Fujitsu NetCOBOL for .NET

Universal x86, MSIL (verifiable)

IBM Corporation Rational Developer for

System z x86

INFINITE Software INFINITEzSeries C

LegacyJ PERCobol Java

Liant RM/COBOL Intermediate code

Micro Focus Net Express x86, MSIL (verifiable)

Veryant isCOBOL Java

6 These .NET Framework components would not be verifiable because the CLR could not ensure that they will comply with the current security settings.

7 This is shorthand for x86, x64 and IA64 native code for Intel and AMD processors.

8 Data General COBOL.


Table 3. FORTRAN compilers


Absoft Absoft Pro Fortran x86

Intel Visual Fortran Compiler x86

Lahey/Fujitsu Lahey/Fujitsu Fortran x86

Silverfrost FTN95 x86, MSIL

The Portland Group PGI Visual Fortran x86

Table 4. PL/I compilers


IBM Corporation Rational Developer for

System z x86

Liant Open PL/I Intermediate code

Table 5. RPG compilers


BluePhoenix Solutions ASNA Visual RPG MSIL (verifiable)

IBM Corporation VisualAge RPG x86

INFINITE Software INFINITEiSeries C

In addition to the compilers shown above, there are also open source projects such as COBOL for GCC9,

TinyCOBOL10

, OpenCOBOL11

, pl1gcc (PL/I for GCC)12

, and G95 (Fortran)13

.

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.

9 See cobolforgcc.sourceforge.net

10 See tiny-cobol.sourceforge.net

11 See www.opencobol.org

12 See pl1gcc.sourceforge.net

13 See www.g95.org


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.


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

From: 4GL easy easy

Proprietary COBOL easy hard

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.


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 Technology Mainframe Languages15

Anubex SLAM ADSO, COBOL, JCL, Natural

Asysco LION Unisys LINC, COBOL

ATERAS DB-Shuttle ADSO, Assembler, COBOL, Focus, JCL, Natural

BluePhoenix Solutions LanguageMigrator ADSO, Assembler, COBOL, COOL:Gen, CA

Ideal, Mantis, Natural, PL/I

Cornerstone G4-Technology Assembler, COBOL, Mantis, PL/I , RPG

EZ Legacy EZ Target COBOL, JCL, Natural

Forecross

Convert/ADSO,

Convert/CSP,

Redirect/COBOL

ADSO, CSP, COBOL

Freesoft Code Liberator COBOL, Natural, RPG

Idea Integration

Rules-Based

Transformation Engine,

LincXGEN filter

Unisys LINC, COBOL

Information Analysis ICONS CA Ideal

Infosol Phoenix Technology GCOS COBOL & JCL

Jazillian Jazillian C, C++, COBOL

Keous Solutions Keous toolbox Assembler, COBOL

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


Legacy Software

Downsizing PowerDrive Application Master, COBOL, SCL

Make TLM COBOL, JCL, Natural, PL/I, RPG

MetaWare Refine C, COBOL, FORTRAN, PL/I

move2open I2C CA Ideal, MetaCOBOL

Micro-Processor

Services Various Assembler, COBOL, PL/I

MigrationWare Various CSP, Easytrieve, CA Ideal, Natural, Mantis

Millenium Technics Various Algol, COBOL, LINC, RPG

MOST Technologies OnTarget Natural

MSS International migrate!COBOL,

migrate!LINC COBOL, LINC

PBSI .NETigration RPG, CL

PKS Migration Tools 400 EGL,

SmartEGL COBOL, Natural, RPG

Quipoz Transformation Engine COBOL, CSP, LINC, Mantis, Natural, PL/I, RPG

Relativity Technologies Transformation Assistant COBOL

Semantic Designs DMS Ada, C, C++, COBOL, FORTRAN, JCL, Natural,

Pascal

Software Migrations FermaT Assembler

SoftwareMining COBOL Translation

Toolkit COBOL

Sykora-ML ML-iMPACT RPG, CL

The Software Revolution JANUS2

Ada, Assembler, C, COBOL, FORTRAN, JCL,

Magna X, Natural, PL/I

Transoft (IRIS) Legacy Liberator COBOL

Trinity Millenium Group TMGi-SAT, TMGi-BRH Most mainframe languages

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


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.


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.


Table 8. Global service providers with modernization practices

Accenture HCL Technologies

Atos Origin HP Consulting

BT Global Services IBM Global Services

Capgemini Infosys

Cognizant LogicaCMG / Unilog

CSC Satyam Computer Services

Deloitte Sonata Software

DTS Latin America Technology Tata Consultancy Services

EDS (Electronic Data Systems) T-Systems

Fujitsu Services / Fujitsu Consulting Unisys

Getronics 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.


Table 9. Application analysis tools

Vendor Product Mainframe Languages

ASG Software Solutions ASG-Existing Systems

Workbench COBOL

BluePhoenix Solutions IT Discovery COBOL, JCL, PL/I, Natural, Easytrieve,

ADSO, Mantis, Telon

Cast Application Intelligence

Platform C, C++, COBOL, JCL

Erudine Legacy Elimination Tool (Not applicable)

Evolveware Legacy Rejuvenator Assembler, COBOL, Natural

EZ Legacy EZ Source COBOL, JCL, Natural, PL/1

Freesoft Portfolio Liberator COBOL, Natural, RPG

IBM Corporation WebSphere Studio Asset

Analyzer Assembler, C, C++, COBOL, PL/I

MetaWare Refine C, COBOL, FORTRAN, PL/I

Micro Focus Enterprise View COBOL, JCL, PL/I

Progeni 4Sight Algol, COBOL, Natural, Mantis, Pacbase,

XGEN

Raincode Raincode Engine Ada, APS, C, C++, COBOL, CA Ideal, PL/1

Relativity Technologies Modernization Workbench Assembler, C, C++, COBOL, JCL, Natural,

PL/I, RPG

SEEC Application Manager COBOL, Natural, PL/I

Semantic Designs DMS Ada, C, C++, COBOL, FORTRAN, JCL,

Natural, Pascal

Software AG Natural Engineer Natural, COBOL, JCL

SoftwareMining BRE toolkit COBOL

Transoft (IRIS) evolveIT COBOL

Trinity Millenium Group TMGi-SAT, TMGi-BRH 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


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.


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

the Microsoft mainframe Web site16

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 skills17

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.

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

See www.microsoft.com/mainframe.

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


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

Cost (low)

+ 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.

Risks (low initially)

+ 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.

Skills (retain)

+ 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.

Agility

(low/moderate)

+ Applications may be re-used as components in SOA.

+ Mixed language development helps optimize resources.

- Agility may be hampered by mainframe application structure.

Innovation (low) + New deployment platform may enable some integration/enhancement.

- Business value of the application is not increased.


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)

+ 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.

Risks (moderate)

+ 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.

Skills (replace)

+ 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.

Agility

(moderate/high)

+ 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.

Innovation (low) + 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


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)

+ 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.

Risks (high)

- Significant technology changes may give rise to unforeseen costs.

- New application and database reduce reliability (not yet production-

hardened).

- Synchronization with ongoing legacy improvements is lost.

Skills (replace)

+ 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.

Agility (high) + Development is more productive using Microsoft software and tools.

+ Application models and structure are better optimized for agility.

Innovation (high) + Business value of the application is increased.

+ Improves IT alignment; better anticipates new business requirements.

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

Table 13. Business issues: summary

Compilers Converters Re-write

Cost Low Low High

Risks Low initially Moderate High

Skills Retain Replace Replace

Agility Low/Moderate Moderate/High High

Innovation Low Low High


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

use18

. 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,

the cost could be as much as $10 per line of code19

. 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

Market Overview: Web-to-host ToolsA Crowded Market, but Compelling Technology. Giga Information Group, March 2002.

19 Source: Legacy Directions Limited, 2008.


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.


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 mainframe-

compatible 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.


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 .NET-

based 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 .NET-

based 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.


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 mainten-

ance, 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 pro-

jects 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.


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).


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, inter-

mediate, 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).


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 re-

engineering, 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 re-

engineering 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.


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 three-tier 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 d

moving mainframe applications to windows

Documents

mainframe languages

moving mainframe applications

mainframe modernization

legacy analysis tools

language conversion

case study

windows compilers

custom research note