Mainframe Languages
Transcript of 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.
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
2 Moving Mainframe Applications to Windows 2
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 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.
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 ―IBM‘s Legacy Application ‗Antiques Road Show‘.‖ Aberdeen Group. April 2003.
2 ―The Legacy Application Modernization Benchmark Report.‖ Aberdeen Group. September 2006.
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
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.
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.
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
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.
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.
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
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.
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
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
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
applications.
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
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 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.
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.
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
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.
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
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 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
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.
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
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 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.
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.
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,
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
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.
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.
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).
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
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.
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.
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
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-
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
22 Moving Mainframe Applications to Windows 22
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-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.
18
―Market Overview: Web-to-host Tools—A Crowded Market, but Compelling Technology.‖ Giga Information Group, March 2002.
19 Source: Legacy Directions Limited, 2008.
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.
24 Moving Mainframe Applications to Windows 24
Appendix A: Compiler product profiles
ASNA Visual RPG
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.
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.
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 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.
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).
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).
29 Moving Mainframe Applications to Windows 29
Appendix C: Service provider profiles
Accenture
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.
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
application.
Modernization Workbench includes application analysis, APM dashboards, restructuring, and refactoring
tools, tools to identify business rules and candidate structures for re-use in an SOA environment, assisted
UML modeling, and a module to convert application code to Java. IBM sells a version of the workbench
called the IBM Rational Transformation Workbench. Relativity has also built the workbench into an Eclipse
plug-in for Rational Developer for System z.
Relativity is an active participant in the 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.
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
(KDM)
Adopted April 2006
(now working on next revision)
RFP 2 Abstract Syntax Tree Meta-Model
(ASTM)
Proposal under review
(adoption planned March 2008)
RFP 3 Analysis Package RFP issued December 2007
RFP 4 Software Metrics Meta-Model
(SMM)
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
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!
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
INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be
reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording,
or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved.
Microsoft, SQL Server, Visual Basic, Visual C++, Visual Studio, Windows, and Windows Server are trademarks of the Microsoft group of companies. All
other trademarks are property of their respective owners.