IBM Mainframe to Server Enterprise Edition™ · Micro Focus Practice ... application migration from the IBM mainframe to Server Enterprise Edition (including Mainframe Transaction

Mainframe Migration Guide

IBM Mainframe to Server Enterprise Edition™

White Paper April 2011

2

IBM Mainframe Migrat ion Guide

Table of Contents

About this Document ............................................................................ 3

Transvive & Micro Focus ........................................................................ 4

Micro Focus Practice ...................................................................................... 4

Migration and Transformation Consortium ........................................................ 4

Migration Tools & Methodology ............................................................... 5

Migration Overview ............................................................................... 6

The Ten Steps ...................................................................................... 7

Step 1: Move System Inventory from Mainframe into Migration Toolkit using MFEEE ......................................................................................................... 7

Step 2: Perform Detailed Migration Assessment using MWB ................................ 7

Step 3: Build EBCDIC Application Reference Project on Windows within MFEEE ..... 9

Step 4: Build MFEEE ANSI Application Migration Project on Windows within MFEEE 9

Step 5: Remove Proprietary Language Dependencies ...................................... 11

Step 6: Replace JCL and Scheduler ................................................................ 11

Step 7: Replace Mainframe Database with Target Database .............................. 11

Step 8: Publish from Migration Toolkit to End User Development Environment (NXP) ........................................................................................................ 12

Step 9: Publish from Net Express to Server Express on UNIX (if required) .......... 12

Step 10: System Test on Target Production Server Environment ....................... 12

Conclusion .......................................................................................... 14

Appendix A: Migration Toolkit for Use by IBM Migration ............................ 15

3


About this Document

This document outlines Transvive’s proven, best-practices ten-step approach to application migration from the IBM mainframe to Server Enterprise Edition (including Mainframe Transaction Option) at a high level. It is not intended to

address subsequent phases of migration. Although this guide offers some guidance with respect to software licensing costs, it does not provide cost estimations for effort and personnel.

This document provides a practical example of Transvive’s work within its Micro

Focus Practice and demonstrates the ways Transvive typically partners with Micro Focus for migration projects.

4


Transvive & Micro Focus

Micro Focus Practice

Transvive's Micro Focus Practice offers assessment, development, testing and deployment through the implementation and utilization of leading-edge Micro

Focus products and tools. We work closely with Micro Focus to help organizations of all sizes to evolve, manage and modernize their enterprise application infrastructure for significant cost savings and increased agility.

Transvive focuses on three core areas of business in partnership with Micro

Focus:

Environment Assessments: Transvive’s environment assessment includes an in-depth examination and complete evaluation of your organization’s current system to give you the insight needed to build

viable, long-term strategies for major IT initiatives. Where application or infrastructure migration is an option, a detailed migration proposal is included as part of the initial assessment.

Language Modernization: Transvive’s language modernization solutions

help organizations overcome the challenges associated with costly and risky rewrites by cleanly converting code in a manner that maintains data integrity and virtually eliminates data errors. The result is a lean,

efficiently performing system that is significantly less costly to support yet maintains superior functionality.

Platform Modernization: In many organizations, customized systems, that are still appropriate for business use today, reside on outdated

platforms. Transvive’s platform modernization solutions help organizations remove these older, costly platforms and replace them with more cost-efficient and powerful platforms, such as Windows, UNIX or Linux. These

critical systems can then be reused in the new environment.

Migration and Transformation Consortium

Transvive is a member of the Micro Focus Migration and

Transformation Consortium (MTC), a global coalition of companies that specialize in helping organizations maximize the value of their existing systems through migration and

transformation using a combination of specialist technology and recognized expertise.

www.microfocus.com

5


Migration Tools & Methodology

This guide highlights how Transvive uses Micro Focus migration tools to help perform migrations effectively via an incremental approach using Mainframe Express® Enterprise Edition (MFEEE) to move code and data off the mainframe

where it can be reviewed and assessed using Modernization Workbench® (MWB). MFEEE is then used a staging environment for migration activities until it is time to publish the migrated application to the target

development and deployment architectures based around Net Express®, Server Express and Server Enterprise Edition™ as shown in Appendix A.

6


Migration Overview

Transvive uses the following tools and performs the following ten steps in the migration of the IBM mainframe to Server Enterprise Edition:

Step 1: Move System Inventory from Mainframe into Migration Toolkit using MFEEE

Step 2: Perform Detailed Migration Assessment using MWB

Step 3: Build EBCDIC Application Reference Project on Windows within MFEEE

Step 4: Build MFEEE ANSI Application Migration Project on Windows within MFEEE

Step 5: Remove Proprietary Language Dependencies

Step 6: Replace JCL and Scheduler

Step 7: Migrate Data Resources to Target Environment(s)

Step 8: Publish from Migration Toolkit to End User Development

Environment (NXP)

Step 9: Unit Test Migrated Application on Target Development Environment

Step 10: System Test on Target Production Server Environment

It is important to note that steps 5 through 7 are the core of the application

migration and these may be completed in any order depending on the specific interim milestones agreed by Transvive and the customer; the migration may be done in ‘chunks’ of functionality based on Transvive-/customer-defined migration

milestones (i.e. move a pilot level of functionality or a database or business function one at a time).

Work on these steps will also typically run in parallel, rather than sequentially. Migration of the database may often be the step that takes the most effort and so will often start first to ensure the migration can be completed in the shortest

amount of time possible. It should be noted that these steps can be executed in different orders for batch applications and online application elements.

By remaining within the MFEEE IDE for the majority of the migration work, testing and comparison with the reference EBCDIC project within the MFEEE environment is easier. This enables issues to be identified during each step and

addressed before the step is ‘completed.’ This approach allows ample opportunity for the project team to demonstrate progress to the customer throughout the project. The customer can see applications up and running on the

new target platform much sooner. Where performance on the new platform is a major concern, work can be started as soon as step 3 is complete to ensure the application will meet the customer’s throughput requirements.

7


The Ten Steps

Step 1: Move System Inventory from Mainframe into Migration Toolkit using MFEEE

Utilize mainframe connectivity facilities of Mainframe Express Enterprise Edition (MFEEE) to get all of the mainframe application artifacts off the mainframe and into MFEEE. This enables Transvive’s project team to work more productively off

the mainframe and avoid impacting current mainframe CPU utilization. This step in the process involves identifying the required code and populating a

MFEEE project with that content. Within this step, sub-tasks will include installing MFM, establishing the download process, identifying the required sources and populating the MFEEE project. Modernization Workbench (MWB) simplifies

identifying the required sources via its Automatic Component Location (ACL) functionality. This will allow the team to identify starting points, such as JCLs, specific programs, programs from RDO information, etc., and use MWB ACL to

quickly and automatically identify all dependent code. Additionally, code that is no longer relevant but remains in production libraries, will be automatically

identified by MWB allowing migration efforts to be focused on relevant modules. MWB provides the environment to complete the inventory, but also identifying

what is missing and allowing that missing code to be added and the results updated. Once the environment is as complete as possible in MWB, a POP file can be generated describing the content of the MWB project, which can be used

to automatically populate the MFEEE environment. Consideration should be given to the fact that system artifacts will continue to be

modified during all phases of the migration project and even after the migration has been completed. The new system is tested or run in parallel to the mainframe system during cut-over phase.

It should be noted that

• Very effective synchronization technology has been installed at many MFEEE customer sites to ensure mainframe and LAN projects are kept synchronized as required; this capability can be utilized once

synchronization requirements are established.

• The MWB product enables analysis steps to be built into tools so the

analysis process can be automated. The process may be repeated as many times as required during different phases of the migration or as needed when synchronization requirements are understood.

This synchronization capability does not take significant effort to set up, works with most mainframe SCM systems and is very efficient in operation. In most

cases, it is prudent to set this capability up at the start of the project.

Step 2: Perform Detailed Migration Assessment using MWB

8


Use MWB to do detailed assessment of effort. Tools in MWB are ideal for

identifying scope of migration effort, migration issue points of interest and subsequent bottom up and top down migration cost estimates based on categorizing the points of interest and inserting effort estimates related to

addressing the different categories of migration issues. For example, once the code has been loaded into MWB, a set of standard MWB

tools can be run to identify known migration issues in the code. This ranges from identifying missing sources, modules that are no longer executed and dead code within live modules, to identifying CICS API clauses that will not be supported on

the new platform. From the issue identification scripting that MWB can do, project effort can be estimated based on known types and quantities of changes required.

Key outputs from the MWB analysis includes

• Accurate information related to the size of every source module (in lines of code)

• Details of the number of lines of code in each that will need to be modified and what the category of issue is with each line (i.e.

mainframe-specific CICS API that will need to be replaced, EXEC SQL code that will not be supported in target RDBMS, etc).

• Reports on cost of migration either from a high-level perspective – the number of source programs, screens, databases etc. – or from a bottom up perspective – detailed analysis of every line of source code.

Another key output of this step is the identification of application elements that

• Can be “lifted and shifted” (i.e. moved with zero or very minimum changes) i.e. COBOL components

• Can be migrated, but will typically need updating first i.e. ‘C’ application components

• Will have to be translated before they can be migrated i.e. Mainframe Assembler application components

Other key outputs at this stage will be the identification of

• Additional third-party technology required to enable the application to

function on the new platform i.e. a new Job Scheduler available on Windows and UNIX

• The number of files and databases to be lifted and shifted and the size of each i.e. DB2 tables

9


• The number of databases to be migrated to a new database architecture and size of each i.e. IMS segments

Step 3: Build EBCDIC Application Reference Project on Windows within MFEEE

Get application up and running under Micro Focus COBOL (MFCOBOL) in EBCDIC mode within the MFEEE environment. This provides a reference environment for comparing test results as changes are made to application. The customer’s

applications running on the mainframe and the mainframe application source remains untouched.

It is critical that the application environment recreated under MFEEE is first validated - and signed off – by comparison with the reference environment (initially the mainframe). The EBCDIC MFEEE environment then becomes the

reference point against which all subsequent testing is conducted. At this stage, the customer’s source code management system is utilized –

ideally, it continues to be the system the customer will use once they take ownership of application again – with development and maintenance for migrated applications now taking place on a Windows platform.

MFEEE by default supports COBOL, CICS, DB2, IMS, JCL and Assembler on the workstation and PL/I and IDMS can be supported with additional options which

include third-party technology. It should be noted that, while the CICS option within MFEEE supports the vast

majority of the CICS API, there are a few situations where changes to code may be required because

• The CICS API supports mainframe specific functions i.e. API to interface with mainframe RACF facility

• The CICS API is very obscure, seldom used and unsupported

If an obscure CICS API is being used and implementing support is not practical, customer code would be altered to work around it.

If ‘C’ routines are called, they would be remotely executed on the mainframe (not ideal) or updated to compile on Windows ‘C’ compiler to provide the same functionality under Windows. This process usually involves manual effort to

reconcile differences in ‘C’ dialects between platforms. If there are other third-party utilities or custom services for which source code is

not available, they must be executed remotely on the mainframe or, if possible, replaced/eliminated.

Step 4: Build MFEEE ANSI Application Migration Project on

Windows within MFEEE

10


Using the project information from the MFEEE EBCDIC project, create an equivalent MFEEE ANSI project which will be the Application Migration project

(i.e. the EBCDIC reference environment will stay intact and only used as a local “mainframe” reference environment).

Changes to the application necessary for migration will only be made as the components are moved to or updated within the ANSI migration project. Source code would already have been changed from EBCDIC to ANSI (for display

purposes) within step 3, but the application code would work in EBCDIC mode with data still held in EBCDIC within MFEEE.

With MFEEE, certain aspects can operate in either EBCDIC or ANSI. Making these aspects operational in the MFEEE ANSI project requires data conversion and the independence of applications that process data from EBCDIC literals or collating

sequences. The elements that can work in ANSI mode are

• COBOL • CICS

• COBOL file handling • DB2

The elements that do not work in ANSI mode are

• Assembler • PL/I • JCL

• IMS-DB • IMS-DC • IDMS

Transvive has various data conversion tools and utilities to assist in the conversion of data from EBCDIC to ANSI and JCL to batch or shell scripts. We

also have options/tools that can help automate the

• Conversion of Assembler to COBOL or C

• Conversion of PL/I to COBOL • Migration of IMS-DB or IDBMS to RDBMS • Migration of IMS-DC to CICS

Once any one area of the application is operational within the MFEEE ANSI migration project, it should be tested against the MFEEE EBCDIC reference

environment. Testing in this way isolates any errors introduced and links them to a particular step in the process. For example, a batch COBOL program running against COBOL data files which does not rely on sophisticated job scheduling

could be brought up in the MFEEE ANSI project very quickly, tested and compared to the results from the same test in the MFEEE EBCDIC environment. Similarly, a BMS/CICS/COBOL online system running against DB2 that does not

11


call ‘C’, PL/I or assembler could be brought up in ANSI and tested against the reference environment.

Step 5: Remove Proprietary Language Dependencies

Remove any dependencies on languages that are not supported in Windows and UNIX.

Typically these are 370 mainframe assembler routines and these can be

converted to

• COBOL if they are performing business functions or

• ‘C’ if they are performing system routines Less typically, PL/I applications or called routines are encountered. These can be

converted to COBOL as they are usually performing business functions. Finally, Natural is sometimes encountered. It can be converted to COBOL if

desired, although Natural is still available on Windows and UNIX. All such conversions would be performed for the customer by Transvive.

Step 6: Replace JCL and Scheduler

Remove any dependencies on mainframe JCL and any mainframe job scheduler that is not available on Windows or UNIX and utilize batch /scripts files or job

control files available with the cross platform job scheduler the customer will use in production.

The batch element of a mainframe application can (and for operational reasons may need to be) moved before the online element. For example, the batch element may provide the data transfer technology required above (export/import

functions). This conversion would be another core part of the work performed by Transvive. The Transvive migration team has created a tool that currently

converts JCL to Windows batch files and can be extended to covert to UNIX shell scripts

An important point to consider here is whether simple scripts, along with Windows and UNIX operating system capabilities, will provide the level of sophistication the mainframe application currently relies on. A third-party job

scheduler that is available on Windows and UNIX or even one that is transactional in nature may be required. If this were the case, the mainframe JCL would need to be converted to the control language supported by the

selected Job Scheduler product.

Step 7: Replace Mainframe Database with Target Database

Use the target database in production. Typically, this will be IBM UDB, Oracle 8

or Microsoft SQL Server. As IMS is not supported in production across Windows and UNIX, it would be replaced with a RDBMS.

12


Any database migration is a major effort, but because IMS is a network

database, its migration is even more complex involving the conversion of a hierarchical database architecture to a relational database architecture. Again the design, conversion and migration of data are significant parts of what

Transvive would be able to offer. Switching over from XDB to the target RDBMS typically involves unloading data

from XDB and loading it into RDBMS using tools from DB vendor. Any proprietary DB2 SQL statements must be replaced with ANSI SQL or equivalent SQL supported by the target DB SQL pre-processor. Transvive project team would

perform the unload/load process, make the changes to SQL code and manage the plan for the actual migration of the data.

Data migration (even if the DB structure doesn’t change much) is often the most complex part of any migration especially because data may need to be kept in step between the source and target platform for a period of time and because,

for huge databases, the conversion may need to take place in steps as the data cannot be converted quickly enough for the process to complete before the system must be operational again.

Much of the effort invested in step 2 can be leveraged here. MWB worksheets

can be developed and refined to identify tables, columns, fields, records, etc. that need to be migrated, and map these to the corresponding source. Create, read, update and delete mapping can be the drivers for implementing the change

in the application code. Specific Enterprise Edition analysis tools that identify what code must change (focused by to/from platform) can be devised to make the process much faster and more accurate resulting in overall cost reduction.

Step 8: Publish from Migration Toolkit to End User Development Environment (NXP)

Move the project to Net Express to recompile and test the migrated application on the target development environment. This move will also introduce Server Enterprise Edition, the CICS deployment engine (part of Net Express). Testing

will now start on the COBOL/CICS run time environment that will be used when deploying the application.

At this point, if necessary, Transvive will transition to the SCM system to be used by the customer. The target RDBMS and the job scheduler will be in place. The Transvive team can then complete testing on the target infrastructure.

Step 9: Publish from Net Express to Server Express on UNIX (if required)

If migrating to UNIX, Transvive will utilize the “Publish to UNIX” capability with NXP/MTO to get project artifacts to UNIX/Linux and invoke Server Express to compile and build application for integration testing on UNIX.

Step 10: System Test on Target Production Server Environment

13


All development products are removed and application is built for system testing using target deployment infrastructure on a different server (logical or physical).

14


Conclusion

As stated previously, the ten-step process covers only the core parts of the migration. There are many more tasks and steps outside of this process including

• Performing capacity testing

• Replicating or creating security profiles/processes/validation/ administration in the new environment

• Crafting testing processes to ensure data integrity/backup/fail over

recovery and support etc.

• Organizing parallel running with the mainframe for a significant period

of time

• Mirroring production to assess data and functional integrity

Transvive is equipped to perform these steps; however, a description of them is outside of the scope of this document.

Transvive’s use of Micro Focus leading-edge tools and best-practices methodologies ensures that our clients experience the easiest, most efficient and cost-effective migrations possible. While all modernization and migration projects

require regulatory procedures to some degree, Transvive’s approach remains agile enough to accommodate client differences in technologies and business logic.

If you would like to know more about Transvive’s migration and modernization solutions, contact us.

Transvive Inc 26 Soho Street, Suite 201

Toronto, ON M5T 1Z7 416-599-2900 [email protected]

www.transvive.com

About Transvive

For more than 10 years, Transvive’s professional services team has been providing

mainframe solutions that significantly reduce operating costs and risks and increase

efficiency and speed to market. Transvive has successfully led projects from simple

GUI modernizations to large-scale system overhauls.

15


Appendix A: Migration Toolkit for Use by IBM

Migration

IBM Mainframe Environment

Mainframe Application Source

Mainframe Database and VSAM files Mainframe JCL Mainframe Development Tools Mainframe SCM etc

Windows LAN Environment

IMP Team Windows Workstation #1 to #n

Micro Focus Migration Toolkit • Modernization Workbench • Mainframe Express Enterprise

Edition • Net Express (inc MTO) • Server Express (inc MTO)

• Server Enterprise Edition (inc MTO)

Windows Developer Workstation

Win

dow

s/U

NIX

SCM

Serv

er

Windows Test Server #1

NX or SX

ES

RDBMS

XP Scheduler Other

third-party

Migration Toolkit

• Get artifacts to workstation • Analysis

• Migration staging (i) EBCDIC/ANSI (ii) COBOL to MF COBOL

(iii) DB2/RDBMS (iv) CICS to Server Enterprise

Edition

(v) Switch scheduler (vi) Publish to Client

Environment

IMP = IBM Migration Partner

NX = Net Express (inc. Mainframe Transaction Option) SX = Server Express (inc. MTO) ES = Server Enterprise Edition (inc. MTO)

Documents

IBM Mainframe to Server Enterprise Edition™ · Micro Focus Practice ... application migration from the IBM mainframe to Server Enterprise Edition (including Mainframe Transaction