of 34 /34
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.

Mainframe Languages

  • Upload

  • View

  • Download

Embed Size (px)

Citation preview

Page 1: Mainframe Languages

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.

Page 2: Mainframe Languages

1 Moving Mainframe Applications to Windows 1


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

Page 3: Mainframe Languages

2 Moving Mainframe Applications to Windows 2


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


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 80–100 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 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


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 ―IBM‘s Legacy Application ‗Antiques Road Show‘.‖ Aberdeen Group. April 2003.

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

Page 4: Mainframe Languages

3 Moving Mainframe Applications to Windows 3

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


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.

Page 5: Mainframe Languages

4 Moving Mainframe Applications to Windows 4

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.

Page 6: Mainframe Languages

5 Moving Mainframe Applications to Windows 5

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



LINC (Unisys) CSP

Pascal DYL-260/280

PL/I Easytrieve Plus


RPG Mantis



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.

Page 7: Mainframe Languages

6 Moving Mainframe Applications to Windows 6

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 vendor‘s 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.

Page 8: Mainframe Languages

7 Moving Mainframe Applications to Windows 7

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


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.

Page 9: Mainframe Languages

8 Moving Mainframe Applications to Windows 8

Table 3. FORTRAN compilers

Vendor Product Generated code

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

Vendor Product Generated code

IBM Corporation Rational Developer for

System z x86

Liant Open PL/I Intermediate code

Table 5. RPG compilers

Vendor Product Generated code

BluePhoenix Solutions ASNA Visual RPG MSIL (verifiable)

IBM Corporation VisualAge RPG x86


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


, 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

Page 10: Mainframe Languages

9 Moving Mainframe Applications to Windows 9

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. IBM‘s 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 Fujitsu‘s 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


Page 11: Mainframe Languages

10 Moving Mainframe Applications to Windows 10

Language conversion tools

Automatically converting a legacy application to an application that exploits the latest language and

platform is likened by many to the alchemist‘s 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



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 compiler—a

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.


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.

Page 12: Mainframe Languages

11 Moving Mainframe Applications to Windows 11

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






Freesoft Code Liberator COBOL, Natural, RPG

Idea Integration


Transformation Engine,

LincXGEN filter


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.

Page 13: Mainframe Languages

12 Moving Mainframe Applications to Windows 12

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


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,


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,


Software Migrations FermaT Assembler

SoftwareMining COBOL Translation

Toolkit COBOL


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 AG‘s 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 AG‘s 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

Page 14: Mainframe Languages

13 Moving Mainframe Applications to Windows 13

GDC‘s 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.

Page 15: Mainframe Languages

14 Moving Mainframe Applications to Windows 14

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


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


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 client‘s 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.

Page 16: Mainframe Languages

15 Moving Mainframe Applications to Windows 15

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 providers—too many to list in this paper—that 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.

Page 17: Mainframe Languages

16 Moving Mainframe Applications to Windows 16

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,


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

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


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

Page 18: Mainframe Languages

17 Moving Mainframe Applications to Windows 17

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.

Page 19: Mainframe Languages

18 Moving Mainframe Applications to Windows 18

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 organization‘s 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.


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

Page 20: Mainframe Languages

19 Moving Mainframe Applications to Windows 19

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


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.



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

Page 21: Mainframe Languages

20 Moving Mainframe Applications to Windows 20

Language conversion tools

Language conversion tools are generally not sold as licensed products—they 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.



+ 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

Page 22: Mainframe Languages

21 Moving Mainframe Applications to Windows 21

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-


- 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

Page 23: Mainframe Languages

22 Moving Mainframe Applications to Windows 22


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


. 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-billion–dollar 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.


―Market Overview: Web-to-host Tools—A Crowded Market, but Compelling Technology.‖ Giga Information Group, March 2002.

19 Source: Legacy Directions Limited, 2008.

Page 24: Mainframe Languages

23 Moving Mainframe Applications to Windows 23

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.

Page 25: Mainframe Languages

24 Moving Mainframe Applications to Windows 24

Appendix A: Compiler product profiles


Amalgamated Software of North America (ASNA) has been providing software for IBM‘s 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. Fujitsu‘s current products, which complement the company‘s

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.

Page 26: Mainframe Languages

25 Moving Mainframe Applications to Windows 25

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 medium–sized 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 95–compliant 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.

Page 27: Mainframe Languages

26 Moving Mainframe Applications to Windows 26

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

Page 28: Mainframe Languages

27 Moving Mainframe Applications to Windows 27

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

BluePhoenix‘s product team develops the company‘s 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).

Page 29: Mainframe Languages

28 Moving Mainframe Applications to Windows 28

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

Page 30: Mainframe Languages

29 Moving Mainframe Applications to Windows 29

Appendix C: Service provider profiles


At U.S.$16.65 billion in revenues for FY06, Accenture is one of the world‘s 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, Accenture‘s global delivery network of 58,000 professionals.

Accenture‘s 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 company‘s 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 customer‘s 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

Relativity‘s 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.

Page 31: Mainframe Languages

30 Moving Mainframe Applications to Windows 30

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 application‘s

―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 rules—a 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 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


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 OMG‘s 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.

Page 32: Mainframe Languages

31 Moving Mainframe Applications to Windows 31

Appendix E: The Object Management Group

The Object Management Group (OMG), a not-for-profit IT industry consortium, is best known for its

Unified Modeling Language (UML) and CORBA20

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 Package Status

Request For

Proposal 1

Knowledge Discovery Meta-Model


Adopted April 2006

(now working on next revision)

RFP 2 Abstract Syntax Tree Meta-Model


Proposal under review

(adoption planned March 2008)

RFP 3 Analysis Package RFP issued December 2007

RFP 4 Software Metrics Meta-Model


Proposal under review

(adoption planned March 2008)

RFP 5 Visualization Package To be addressed

RFP 6 Refactoring Package To be addressed

RFP 7 Transformation Package 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

Page 33: Mainframe Languages

32 Moving Mainframe Applications to Windows 32

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

driven architecture (MDA) tools. The acronym reversal from ADM, a form of reverse-engineering, to MDA

(which came first) is no accident!

Page 34: Mainframe Languages

33 Moving Mainframe Applications to Windows 33

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


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.