IBM Mainframe to Server Enterprise Edition™ · Micro Focus Practice ... application migration...
Transcript of IBM Mainframe to Server Enterprise Edition™ · Micro Focus Practice ... application migration...
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
• 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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
All development products are removed and application is built for system testing using target deployment infrastructure on a different server (logical or physical).
14
IBM Mainframe Migrat ion Guide
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
IBM Mainframe Migrat ion Guide
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)