HH&S

Mainframe / Open engineering since 1992

FrançaisExtranet

IBM Mainframe Migration

To UNIX, Linux and Open Systems.

Migration

Four keys to a successful project

Experience

With roots in IBM mainframe environments (DOS/VS, MVS and VM/CMS) and extensive expertise in both Open Systems and proprietary UNIX platforms (Linux, IBM AIX, Sun Solaris and HP-UX), we understand the challenges and risks involved in a mainframe migration project.

Only professionals with dual Mainframe/UNIX expertise can effectively advise on, design, supervise and deliver a mainframe migration. Two specialists—one from the Mainframe world and one from the UNIX world—may struggle to understand each other because their environments are fundamentally different.

Experience shows that collaboration between Mainframe and UNIX teams is effective only when supervised by people who understand both environments and can identify, explain and address the technical pitfalls.

COBOL executables and DB2 databases may be relatively straightforward to migrate, but what about:

  • JCL?
  • data structures (DSN, VSAM)?
  • references to that data (DD statements)?
  • EBCDIC binary files?

These are only some of the most obvious issues.

Teams that have not been properly prepared and staffed—in both skills and numbers—will face more serious obstacles arising from unfamiliarity with the Mainframe and UNIX worlds.

Successful preparation and delivery depend on experience and deep technical expertise, not on the size of the service provider or the number of UNIX, COBOL or Java programmers it employs.

Migrations and active project involvement

  • DOS/VS -> MVS/XA
  • VM/CMS -> MVS OS/390
  • VM/CMS -> Windows NT, using our EVMPR emulator
  • VM/CMS -> AIX
  • MVS -> AIX
  • VM/MVS -> z/VM / z/Linux
  • z/OS -> Linux
  • z/OS LPAR carve-outs
  • z/OS LPAR consolidation

Replatforming and migration

  • COBOL, PL/I, FORTRAN, IBM 360 Assembly and APL programs
  • JCL, CLIST and REXX procedures
  • VSAM files
  • DB2, DATACOM-DB, IMS and DL/I databases

Levels of involvement

  • Consulting, expertise and project leadership
  • Organisation and supervision
  • Application and technical asset inventory and cross-references
  • Preparation of Requests for Information and Requests for Proposal
  • Target software architecture research
  • Feasibility studies and proofs of concept
  • Assistance with technical specifications
  • Implementation
  • Training in new technologies
  • Support for production operations on target systems

See our article on migration from Linux to z/Linux S/390.

Methodology

Every MVS migration has its own application environment, workloads, network and organisation. Our methodology considers all these factors to deliver solutions aligned with the client’s strategic and financial objectives.

It is a proven model:

  • It is reviewed and enhanced as experience is gained from migration projects.
  • It covers the complete architecture and all existing resources before migration, during transition, at production cutover and after migration.
  • It distinguishes the individual tasks, the specialist skills assigned to them, their synchronisation and their supervision.
  • It analyses architectures, workloads, data, interfaces and dependencies.
  • It specifies the technical solutions and tools required for each task.
  • It supports estimates of schedule, staffing, software and hardware resources, and total project cost.
Methodology applied to batch workloads
Methodology applied to batch workloads

MVS asset inventory

This preliminary phase is essential to every migration. It provides a comprehensive inventory of batch and transaction-processing workloads, deployed subsystems, data (sequential files, VSAM, IMS, DB2, SPITAB, etc.) and workload-to-data relationships.

The inventory identifies and quantifies the workloads and data to be migrated, while highlighting the most difficult areas. Our tools generate—at the click of a button—the cross-reference information we use to estimate migration effort and complexity accurately.

RFP and ROI

At this stage, the client has the detailed information needed to prepare specifications and, if appropriate, issue an open Request for Proposal (RFP). Once the RFP process is complete, the client can determine the expected return on investment (ROI) and decide whether to proceed.

Proof of Concept

After a brief assessment of the existing environment, we can propose a batch Proof of Concept.

This involves selecting a representative workload and its components (JCL, COBOL, datasets and DB2 tables), migrating it to an Open System, and demonstrating that it operates correctly with equivalent functionality.

In one recent project, we delivered a z/OS-to-UNIX batch PoC that was:

  • operational on two UNIX systems (AIX and Linux), using four compilers (two COBOL and two Java compilers) and three databases (DB2 UDB, PostgreSQL and MySQL);
  • available in a choice of 24 technical target-platform combinations;
  • completed in under three weeks (*).

(*) This workload did not include SPITAB, VSAM, NATURAL, Assembly, PL/I or IMS. Its JCL was converted automatically into shell scripts by ACMU, while its SORT operations were implemented on UNIX/Linux using XSM.

The next phase is the transaction-processing Proof of Concept. This assesses one or more commercially available CICS migration solutions and implements them within a limited but representative scope.

With a modest investment of time and money, this methodology enables clients to:

  • confirm the technical feasibility of the migration;
  • state technical preferences—target system, languages, compilers and RDBMS—that align with their information system’s technology base;
  • obtain reliable workload, budget and schedule estimates;
  • verify that a compact team of experts, independent of software vendors, hardware manufacturers and service providers, offers the most effective way to lead a migration project and coordinate all participants.

Project leadership

All these activities require deep specialist expertise. They must be led by someone with a thorough understanding of IBM Mainframes and Open Systems, as well as knowledge of the vendors and solutions available in the market.

For large-scale migrations, HH&S provides project leadership assistance.

Discuss your migration project

Tools

ACMUToday’s tools can automate selected tasks, improve reliability, accelerate delivery and reduce both timescales and costs.

One essential part of migrating from MVS to UNIX is converting MVS JCL into UNIX shell scripts.

After identifying a genuine shortage of utilities in this area, assessing the performance, effectiveness and cost of existing products, we returned to our core systems-programming expertise and developed a utility that converts MVS JCL into UNIX shell scripts.

  • Cross-references
  • Choice of target shell (/bin/ksh, /bin/bash, etc.)
  • JCL error detection
  • Detection of missing items (members, procedures, etc.)
  • A 10-step, 300-line JCL job generates 600 lines of shell script in two seconds

Find out more about our MVS JCL-to-UNIX shell conversion utility, or try it online.

Mainframe Migration Toolkit

Mainframe Migration Toolkit
ObjectiveSolution
Convert JCL into UNIX shell scripts?ACMU
Need a high-performance UNIX/Windows SORT compatible with IBM DFSORT?XSM
Process JES2 spool offload data on UNIX/Windows?HSPO
Run VM/CMS REXX procedures on UNIX/Windows?EVMPR
Replace Datacom/DB with DB2 in MVS COBOL programs?DBENTRY
Replace MVS DB2 with a UNIX database in MVS COBOL programs?GDG

Technical expertise

Deep technical expertise is required in both IBM Mainframe and Open Systems environments.