HCLT Whitepaper: Virtual Mainframe

April 2011

Virtual Mainframe – Legacy Application Rehosting

Santosh KumarVishnu Prasad

Virtual Mainframe - Legacy Application Rehosting | April 2011�

© 2011, HCL Technologies. Reproduction Prohibited. This document is protected under Copyright by the Author, all rights reserved.

Contents

InTRoduCTIon 2

MAInfRAMe MIgRATIon oPTIons 3

APPLICATIon ReHosTIng 4

APPLICATIon ReHosTIng PRoCess 9

end noTes 11

APPendIx – A 12

RefeRenCes 13

AbouT THe AuTHoRs 13

AbouT HCL 14

Introduction

Back‑ground

From the mid 1950’s, Mainframes have been the main stay for organizations enabling them to integrate all their data processing requirements and applications into a single, robust management information system. Around the same time COBOL was developed with the aim of making it easy to write business applications. This early beginning and widespread adoption of Mainframe hardware with COBOL applications running on them has led to the current scenario where almost all organizations have at least a part of their business IT requirements being addressed by ‘Legacy Systems’. Significantly, these ‘Legacy Systems’ handle core business functionalities and are characterized by large application sizes and high complexity.

Rise of the Alternatives

Starting with the 1970’s and 80’s, the world of computing saw the conception and rise of alternate computing platforms like UNIX, Linux and Windows where the emphasis was on flexibility, interoperability, application portability and standards compatibility. This also sparked the evolution and rise of various languages, programming paradigms, application architectures and communication protocols. The advent of these more modern application languages and powerful, flexible computing platforms has provided organizations with cheaper and comparably powerful



alternatives to run their business applications. They now had different options to choose from for their IT infrastructure beyond Mainframes.

Inertia

The availability of options doesn’t automatically result in the use and adoption of the same. Factors like business criticality, existing technical complexity of the ‘Legacy Applications’, the innate risk averseness of organizations and, in certain instances, the outright superiority of the mainframes have resulted in their persistence as the pre-dominant IT platform in spite of growth in the number of replacement options. As a consequence of this inertia against new platforms, the Mainframe has evolved into a niche but monopolistically controlled platform with unrealistic licensing costs and methods.

The Need for Migration

At present, in a post recessionary world, organizational IT is driven as much by the need to improve Total Cost of Ownership (TCO) and Return on Investment (ROI) as it is by technical and performance characteristics. Now, organizations are keen to explore avenues which enable them to decrease costs while retaining functionality, meeting SLAs and mitigating risk. The main approach for realizing this, by migrating their existing legacy applications and functionality to alternate server environments which offer greater economies of scale and increased business flexibility, has increasingly gained credibility among organizations as this enables them to reduce overall expenditures while allowing them to leverage their existing systems in new ways to open up opportunities for increased IT value.

Mainframe Migration Options

Migrating out of mainframes can be accomplished in multiple ways, the main ones being:

Application Re‑engineering

This approach involves partial or complete redesign of the application architecture and re-writing the application to fit into this new architecture. It results in an efficient and optimized solution for the platform it is being targeted at but is heavily dependent on the functionality of the current application being completely understood and exactly replicated. This approach usually involves taking advantage of modern programming languages, tools and methodologies to transform and recode the existing functionality.

Application Replacement

This approach involves replacing the existing application and its functionality with a ready-made solution package, also referred to as ‘Commercial-off-the-Shelf’ solution (COTS). ‘Replacement’ is a viable option when the ‘COTS’ already has all of the functionality being delivered by the existing application and is available for the target platform being considered. In practice, however, no COTS



product will be able to provide an exact functionality match and would thus require varying degrees of customization and testing before it can be rolled-out for general use.

Application Rehosting

This approach involves changing hosts or platforms on which the application runs. However, unlike the other methods, the software application being rehosted doesn’t undergo major change in how the end users use it. This ability to enable an existing application to be run ‘As-Is’, on the target platform ensures that Rehosting removes the risk associated with adopting a new platform for existing application functionality and at the same time brings the benefits of moving to a new platform in terms of flexibility and cost.

Migration Option Comparison

When compared based on parameters like Migration Cost, Migration Time, Time for realizing ROI, Skills required to work on the Migrated platform, Migration Risks, Innovation in the process and Ability to Extend the application on the target platform, the various migration options stack up as follows:

Re‑engineer Replace Rehost

Cost High High Moderate to Low

Time High High to Moderate Low

RoI Moderate slow fast

skills Re-train Re-train Retain

Risks Moderate Moderate Low

Innovation High Moderate Low

extensibility High High to Moderate Moderate

Table A - Migration Option Comparison

If organizations need a quick turnaround on their mainframe migration activity, a lower TCO and faster ROI in the migrated solution, it is clear that Rehosting is the way to go.

Application Rehosting

What it Entails

Application Rehosting involves moving the application portfolio – everything that makes up the application’s eco-system like application code and logic, data, scripts, screens etc. – from the mainframe to the new platform with minimal or no changes. It preserves current business rules, procedures and functionalities and causes minimal disruption to how the end-user interfaces with the application.



Hardware Platforms Wintel, x86, sPARC, Itanium

Operating Systems Windows, unIx, Linux

Emulation Layers .neT, JVM

Table B: Target platform options for rehosting

Types of Rehosting

The major components that make up any legacy application are the programs, batch scripts, UI components, files and tables. Apart from these the eco system also consists of components like control cards and configuration files. On the basis of how these source components are handled during rehosting to a target platform, there are two main ways via which application rehosting can be achieved.

Retaining the Technology StackThis method makes sure that the change required in the existing technology stack of the application during rehosting is minimum, thereby eliminating risk to a high degree and greatly reducing the time taken for the migration. To achieve all this, it necessitates the presence of an Application Execution Environment (usually in the form of a software emulation layer) that provides behavior and technology support similar to the source mainframe. However, this method uses the target platform environment merely as a foundation for the emulation layer and doesn’t immediately exploit the features of the environment for the application. Usually, in this method of rehosting, the task of altering the technology stack is taken up as a follow-up/ phase-2 activity.

Altering the Technology StackThis method ensures that the way the end-users interact with the application and application functionality remains unchanged but changes a few components in the technology stack to take advantage of the target platform environment. For example, JCLs are converted to Shell Scripts; BMS Maps are converted to .NET screens etc. However, the technology conversion makes this method inherently more risky and would require more effort and time spent on risk mitigation efforts when compared to the previous method.

Proven emulation platforms, tools and techniques by multiple vendors are available for rehosting of either type.

(Refer to Appendix-A for a comparison between some of the main players in this space).

When to choose Rehosting

All Legacy Applications are not automatically suited for rehosting. The choice of migration strategy depends on various factors like

Target Platforms

The availability of multiple computing platforms in the market has meant that there are many target platform options to choose from based on organization specific business needs and strategy. The choice of computing platforms includes:



the size, complexity and criticality of the applications and systems in consideration.

For e.g., SMEs (Small and Medium Enterprises), could very well apply Rehosting as a Mainframe Replacement strategy, because all of their applications might fit cleanly into a non-mainframe platform. On the other hand, in case of Large Mainframe shops, rehosting of non-critical work off the mainframe can free up the MIPS for more critical data processing needs and also help defer their mainframe upgrade plans thereby benefitting from a hybrid Mainframe + Rehosting solution.

They main factors that need to be considered are:

Technology Factors Business Factors

The availability of an execution en-vironment for the technology stack on the preferred target platform

organization’s technology roadmap and business plans that the Legacy Application must cater to

The proportion of the technology stack that is not readily Rehostable and requires some change

business criticality of the Legacy Application

The availability of options to port or replicate the existing eco-system on the preferred target platform

Current TCo of the mainframe and the potential reduction in cost (TCo) which can be achieved

size of the mainframe, in MIPs, that is being targeted for migration

The time period in which cost reduction can be achieved (RoI)

Table C: Factors influencing migration options

As a thumb rule, ‘Rehosting’ can be a viable solution where

• Legacy Application has a fairly standard mainframe technology stack (COBOL, PL/1, CICS, JCL, VSAM, GDG, DB2, IMS, BMS)

• The mainframe MIPS consumption costs are disproportionately higher compared to associated business value which is derived from the mainframe

• Quick turn-around is required for the migration

Rehosting Benefits

The benefits that Application Rehosting brings to the table can be categorized as below:

ContinuityIt allows organizations to continue using the stable applications that they have relied upon for long, since it involves using the same application and technology stack but on a different platform. Extensive retraining of valuable personnel is eliminated and current skill sets can be reused. This minimizes disruptions to existing teams and workflows.

Low RiskSince the amount of change required in the application is comparatively minimal or non-existent (as against COTS or Re-engineering), this exercise is ‘low risk’ by definition.



Low CostThe costs involved in procuring, operating and upgrading the target platform, in terms of hardware as well as software, are substantially lower when compared to the costs incurred for the equivalent components on the Mainframe. This results in huge cost savings for the organization post-Rehosting, with typical ROI within 18 to 24 months. It also significantly reduces cost of operations, freeing up the IT budget for full modernization and innovation.

Less Effortince most of the application technology stack is retained, existing development and maintenance resources can be reused with minimal retraining. It also ensures that end-users are not faced with any radically new way of interacting with the application, thereby reducing end-user re-training efforts.

ScalabilityRehosting to a modern target platform provides the organization with the ability to scale the system up or down based on their load and growth. But more importantly, it opens the possibility of horizontally scaling out their application servers into a ‘cluster’.

FlexibilityBecause the applications are now running on modern platforms, they can often be easily wrapped in a powerful GUI as opposed to the traditional character-based UI. This also makes it easier and cheaper to extend the existing applications with a Web Services front-end than when they were running on the mainframe.

Rehosting vs. Other types of Migration

Rehosting is inherently different from other types of Migration because:

• It involves moving the existing application to the target platform with minimal or no changes to the way it currently exists and behaves whereas other migration options involve changing the entire application architecture, technology stack and usability

• It requires the availability of compilation and run-time support for mainframe application source and data on the target platform whereas other option involve using the native environments available on the target platform

• It mainly addresses the high costs and inherent inflexibility of running Legacy Applications while reducing risks involved in moving to a cheaper platform whereas other migration options usually address the challenges related to application code quality and architecture also

• It is largely tool driven and achieves the porting and execution of Legacy Applications on the new platform with a high degree of automation whereas other options are comparatively more manual-work intensive and time consuming



Rehosting – Reference Architecture

Figure 1 - Generic Rehosting Reference Architecture

3270Others

BMSIMS Screens

UI Layer

Batch Layer (JES)

Data Layer

Application Layer

Transaction Layer

z/OS, OS390, Bull etc.

JCL/ PROC/ other CL Job Scheduler (CA-7/-11 etc.)

Third party Utilities (Sync SORT etc.)

IBM Utilities (IEBCOPY, IEBGENER etc.)

Indexed Files

GDGDB2/ IMS DB etc.

Flat Files

X Gen Pac Base

CA Ideal Other

Business Logic in COBOL

Business Logic in

PL/1

CICS TS IMS DC Other

4GL 3GLS

ecur

ity

Laye

r

RA

CF

, CA

To

p S

ecre

t, A

CF

2 et

c.

Assembler, REXX, DYL280, SAS etc.

3270 IMS Screens BMS

JSP HTML .NET Web Services

JCL/ PROC/ shell Scripts/ Perl ....

Job Scheduler (Autosys, BMC Control...)

Equivalent 3rd party utilities

Indexed Files

GDGRDBMS

Oracle, DB2 SQL Server etc.

Flat Files

Converted to equivalent in supported 3GL

Emulated CICS/ IMS DC/ OLTP environments

Converted to supported 3GL

Business Logic in COBOL

Business Logic in

PL/1

4GL 3GL

UI Layer

Batch Layer (Emulated JES/ OS Layer etc.)

Data Layer

Application Layer

Transaction Layer

Windows, UNIX, Linux

Act

ive

Dir

ecto

ry, O

pen

LDA

P, O

ther

LD

AP

bas

ed p

rod

ucts

Sec

urity

Lay

er



Application Rehosting Process

Legacy applications usually exist within an ecosystem of interfaces, tools and utilities on the mainframe which they actively interact with. Legacy applications, in general, also do not exist on the mainframe in isolation and as such share certain application assets and the mainframe resources with other applications. The presence of such interactions and dependencies makes it imperative that any rehosting exercise focuses on not just the application inventory but also on providing a similar eco-system on the target platform for the application to run in.

In order to achieve that, the process of Rehosting should usually be as indicated:

general Assessment

Inventory Assessment

Rehosting strategy

Platform setup

Pilot Rehosting

Complete Rehosting

Testing

uAT

go-Live

Figure 2 – Rehosting Process

General Assessment

This is the beginning of the process where the existing application on the mainframe is assessed to understand the following:

Technology stackThis includes identifying programming languages, scripting languages, transaction processing environments, batch and online technologies, files types, data types, database types and utilities.

Application EnvironmentThis includes identifying processes for backups, archiving and DR, identifying application interfaces, character sets, compiler options, identifying batch scheduling, security and access management requirements and identifying utilities and third party tools being used.

Usage and PerformanceThis includes identifying application usage patterns, application load characteristics, application response times and base lining the performance of the application in its current state.

Virtual Mainframe - Legacy Application Rehosting | April 201110


Non-Performance ParametersThis includes identifying the requirements – existing as well as future – for application availability, scalability, modification and extensibility.

Inventory Assessment

The general assessment is followed by a detailed inventory assessment. This is required in order to obtain:

Size of applicationIn terms of number of components and complexity of components.

Technology GroupingGrouping of the components in terms of their technology to understand the size and proportion of each technology in the over-all technology stack.

Rehosting Strategy

The results of the assessment enables the formation of the rehosting strategy which consists of:

• Choice of rehosting environment vendor

• Strategy to handle un-supported technologies

• Environment mapping

• Target Architecture, Sizing and Workflow

Rehosting Environment Setup

This is where the target platform is built for the first time and configured as per the decided architecture.

Pilot Rehosting

As the saying goes, “The proof is in the pudding”. Having done the assessment and developed a strategy for the rehosting based on that definitely makes the exercise proceed smoothly and quickly but doesn’t provide a 100% guarantee that the strategy will succeed completely in meeting all the requirements. In order to save time, effort and costs, it is advisable to put the rehosting strategy to test by means of a Test run or Pilot done on a small, representative subset of the application. This will help identify any shortfalls in the overall rehosting strategy which can then be rectified accordingly.

Rehost the complete application

Once the strategy has been tested and perfected via the Pilot, the entire application – programs, scripts, screens, data, tools and utilities – can then be rehosted to the target platform in a smooth and efficient manner.

Post‑Rehosting Testing

By definition, rehosting provides the same functionality of the legacy application on the target platform. Hence the focus of the

Virtual Mainframe - Legacy Application Rehosting | April 201111


testing effort in a typical rehosting exercise would be around the non-functional aspects like performance, stability and availability. Functional regression testing will also be carried out.

UAT/ Parallel Run/ Field Testing

In this phase, the target platform will be configured in the same way as it would eventually be as a live system and will be run alongside the mainframe. As much as possible, the same data will be used on both the platforms and end-users would be invited to use the rehosted platform. Using the new platform in a production like environment helps identify any final wrinkles in the rehosting strategy and eliminate them.

Go‑live

The final phase, where the new target platform takes the place of the mainframe as the application platform.

Training

As a parallel activity which can be taken up along with any of the testing phases, training activities have to be started for the various teams that would be using the new platform. This includes:

Application teamThey have to be trained in working with new IDEs which will be used for ongoing application development and maintenance activities.

Administration teamThey have to be trained in the administration of the various components that make up the new application ecosystem.

Decommissioning & Modernization

Once the new platform is in place, plans for decommissioning the application from the mainframe as well as for modernizing and extending the rehosted application can be worked on.

End Notes

One size doesn’t fit all in the context of legacy modernization. There is no single, pre-packaged solution that is right for everyone seeking to modernize their existing mainframe applications.

While the traditional legacy modernization and migration methods have their place, “Legacy Rehosting” makes a strong case for itself as a viable modernization solution because of the benefits it provides in terms of reduced migration risk, short implementation time frame, faster ROI and greatly reduced TCO. “Legacy Rehosting” works for enterprises irrespective of their mainframe footprint. It can be leveraged either to completely replace their mainframes or for partial workload offloading from the mainframe. In either case the end result is a sizable reduction in their overall mainframe costs.



Appendix – A

Platform

TP & BP engines & Runtime environ‑ment

Appli‑cation handling

Data Support

Other tools (Monitor‑ing, Secu‑rity etc.)

Microfo‑cus

Windows unIx Linux

server enterprise edition (for TPe & bPe)

MfCoboL Runtime

Minimal to no change

IsAM

gdg

Any RdbMs

Via 3rd Party

Clerity Windows unIx Linux

uniKix TPe

uniKix bPe

vCoboL Runtime


IsAM

oracle, db2 udb

Provides Monitoring, security and Access mgmt. All others via 3rd Party

Oracle Tuxedo

unIx Linux

Tuxedo as TPe

os shell as bPe

MfCoboL or net-CoboL

JCL converted to shell scripts

bMs converted to JsP/HTML

IsAM

oracle, db2 udb

Via 3rd Party

Fujitsu Alchemy

Windows neoKicks and .neT

neobatch

netCoboL Runtime

bMs converted to AsP.neT

Convert indexed file to tables

Any RdbMs

Via 3rd Party

COBOL‑IT HTWC

Windows unIx Linux

xCICs

xebe

CoboL-IT or net-CoboL


VsAM emulation

Any RdbMs

Provides schedul-ing. All others via 3rd Party

TMax‑Soft

unIx Linux

open-fRAMe (for TPe and bPe)

own CoboL Runtime


VsAM emulation

Any RdbMs

Via 3rd Party

IBM TX‑Series

Windows unIx Linux

Tx-series (CICs) as TPe

no JCL support

MfCoboL or net-CoboL


VsAM emulation

Any RdbMs

Via 3rd Party

***Click on the vendor name for the website



References

1. Wikipedia

http://en.wikipedia.org/wiki/History_of_IBM_mainframe_operating_systems

2. The History of Computing Project

http://www.thocp.net/hardware/mainframe.htm

3. IBM

http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_intro.html

4. University of Maryland, Baltimore County

http://www.cs.umbc.edu/courses/graduate/631/Fall2002/COBOL.pdf

5. Microsoft

h t tp ://www.microsof t . com/downloads/en/deta i l s .aspx?FamilyID=1637d24d-fb67-4d6e-adc7-e101981c728b&displaylang=en

About the Authors

Santosh Kumar is a Mainframe migration/modernization architect with the HCL Mainframe Solutions Centre of Excellence. He has around 10 years of Mainframe development and solutions experience and has been involved in architecting multiple large scale legacy modernization programs.

Vishnu Prasad is a Senior Project Manager handling Legacy Application Rehosting with the HCL Mainframe Solutions Centre of Excellence. He has around 10 years of Mainframe development and modernization solutions design experience.



About HCL Enterprise

HCL is a $5.5 billion leading global technology and IT enterprise comprising two companies listed in India - HCL Technologies and HCL Infosystems. Founded in 1976, HCL is one of India’s original IT garage start-ups. A pioneer of modern computing, HCL is a global transformational enterprise today. Its range of offerings includes product engineering, custom & package applications, BPO, IT infrastructure services, IT hardware, systems integration, and distribution of information and communications technology (ICT) products across a wide range of focused industry verticals. The HCL team consists of over 79,000 professionals of diverse nationalities, who operate from 31 countries including over 500 points of presence in India. HCL has partnerships with several leading Global 1000 firms, including leading IT and technology firms. For more information, please visit www.hcl.com.

About HCL

HCL Technologies

HCL Technologies is a leading global IT services company, working with clients in the areas that impact and redefine the core of their businesses. Since its inception into the global landscape after its IPO in 1999, HCL focuses on ‘transformational outsourcing’, underlined by innovation and value creation, and offers integrated portfolio of services including software-led IT solutions, remote infrastructure management, engineering and R&D services and BPO. HCL leverages its extensive global offshore infrastructure and network of offices in 26 countries to provide holistic, multi-service delivery in key industry verticals including Financial Services, Manufacturing, Consumer Services, Public Services and Healthcare. HCL takes pride in its philosophy of ‘Employee First’ which empowers our 72,267 transformers to create a real value for the customers. HCL Technologies, along with its subsidiaries, had consolidated revenues of US$ 3.1 billion (Rs. 14,101 crores), as on 31st December 2010 (on LTMbasis).

HCLT Whitepaper: Virtual Mainframe

Business

Transcript of HCLT Whitepaper: Virtual Mainframe