ACMU Automated Conversion from Mainframe to UNIX

Quote

".../... However, once on the PC, the software can be incrementally rewritten. In this way, significant savings can be realized early with small upfront costs. There have been a few efforts along this direction, most notably the works by Henault [12], Rossen [17] and Townsends [18]. .../..."

USENIX '04 Paper, Migrating an MVS Mainframe Application to a PC

ACMU Methodology

1

The client sends a representative sample of JCLs.

2

We analyse automation feasibility and complexity, and identify JCLs that use IBM legacy utilities or site-specific tools. ACMU converts these JCLs, although some target-side technical or functional adaptation may be required.

We submit a fixed-price proposal defining scope, cost and schedule.

3

Go / No go?

4

The client supplies all the material or delivers it in batches. A first batch can quickly serve as a proof of concept.

We run ACMU. It produces cross-references for JCL, programs, procedures, datasets and JCL variables, together with documentation, JCL graphs, and integration notes and warnings.

We review successful conversions, warnings and errors, then adapt ACMU until every script in the agreed scope is technically and semantically correct and operational on the target UNIX/Linux system. We also verify that a UNIX shell wrapper is available for every program listed in the cross-reference.

We dry-run every script using simulated client data and application programs.

The shell scripts and utility wrappers are ready for delivery.

We organise presentation and integration workshops.

5

We support technical and user acceptance tests, go-live and initial production support.

For further information, please contact us.

Introduction

Migrating from MVS to UNIX/Linux has never been straightforward.

Drawing on its experience, HH&S has developed a migration methodology covering the following areas:

• migration of CICS applications;
• migration of batch applications, including JCL, COBOL programs and utilities;
• migration of datasets and databases;
• migration of production operations.
  

For JCL and programs, volumes are often so large that manual migration is not realistic: it would take years and involve a high risk of human error. This led HH&S, from the mid-1990s onwards, to build a suite of conversion tools that has been extended and made more reliable with each migration:

• tools for porting COBOL programs
• tools for porting data files
• tools for converting JCL

It is not a completely generic tool: it must be adapted to each client's environment.
However, when the JCL is standardised, complies with the site's standards and particular cases have been identified and isolated, ACMU can convert thousands of MVS JCL jobs into UNIX/Linux shell scripts within a few minutes.

Experience shows that 100 lines of JCL generate approximately 400 lines of shell script, including 60% comments for documentation and production operations:
for 1,000 jobs with approximately twelve steps each, this represents 150,000 lines of JCL and 600,000 lines of shell script.
That is around three years of work for a highly skilled UNIX specialist with an expert knowledge of the shell and UNIX system resources, as well as a sound understanding of MVS JCL.

General concept

1. from a job list, it analyses the MVS JCL and exports it in a portable XML form;
2. it produces the corresponding shell scripts from the XML files;
3. it produces documentation for each script: a conversion log and an operations sheet.

• each MVS job = one shell script;
• each step = one call to a UNIX program or procedure;
• the resulting shell scripts are 100% standalone and require no specific runtime.

• target script is composed of the original sequence of steps
• Job is restartable at the step level
• it creates one log file for the whole job or one log file per step
• it handles conditions and return codes in the same logic as the original JCL and ends with a MAX Condition Code that your scheduler will process
• Path/file names for programs and data are highly customizable to fit your target environments
• it handles file disposition (DISP=) "à la MVS" as well as GDG files versioning
• invokes programs (Cobol or whatever) passing parameters as well as SYSIN statements
• featuring most common IBM utilities (IDCAMS, IKJEFT01, ..) as shell/Perl procedures
• DF/SORT syntax compatible sort utility

The conversion of each job is based on four elements:

1. general conversion parameters;
2. the JCL for the job concerned;
3. COBOL source programs, if accessible;
4. operating conditions on the target system.

Main conversion parameters

ACMU settings define:

• the shell to use (ksh, bash, ...);
• the names of UNIX replacements for MVS utilities (catalogues, IDCAMS, IEBGENER...);
• the names of tape drives or cartridge readers, if required;
• the SYSOUT and SYSLOG printer names for each output class;
• the directories corresponding to MVS LOADLIBs;
• the directories for data files and data libraries;
• the directories for COBOL source files during conversion or execution;
• the DDNAMEs for programs where they appear only in DD statements.

The JCL

ACMU's first phase is used when the JCL is standardised and complies with the standards of the MVS site being migrated.

It includes a JCL syntax analyser and an XML parser that converts the JCL into XML.

This phase can run on the source MVS system or on any UNIX or Windows system to which the JCL and, optionally, COBOL source files have been transferred.

The JCL syntax analyser assumes that:

• the first JCL statement is a JOB statement;
• standard files—PDS and sequential datasets—can be converted for use on UNIX, whether fixed or variable, text or binary;
• there are no significant catalogued procedures requiring substitution in DD statements;
• sort parameters are explicit and always include SORT/MERGE and RECORD statements;
• standard utilities are explicitly described in the ACMU parameters, particularly their DDNAMEs when these are implicit, such as SORTIN, SYSIN and SYSUTn.

• INCLUDE statements
• conditional execution using IF or COND=
• JCL variables
• OPC variables
• concatenated SYSIN statements
• GDGs

The programs

For the shell script to run correctly on the target system, the programs are assumed to meet the following conditions:

• they have all been ported or have an equivalent on the target system;
• they do not require dynamic LINKEDIT loading;
• they are located in the UNIX directory corresponding to their MVS LOADLIB;
• data is located in the UNIX directories corresponding to its MVS locations;
• DDNAMEs are those listed in the corresponding MVS step;
• programs return the same return code on MVS and UNIX.

COBOL programs:

SELECT ddname ASSIGN TO dsname ... clauses are processed as follows:

If the target UNIX COBOL compiler recognises the shell environment variable corresponding to ddname, ACMU generates a UNIX alias of the form 'ddname ==> dsname' from the JCL dsname.

Otherwise, if the COBOL source for the program is available during conversion, ACMU generates a fixed UNIX alias from the dsname.

Otherwise, ACMU generates a call to a routine that performs the same operation dynamically at run time, provided that the COBOL source—or an extract containing the SELECT clauses—is accessible under the same naming conditions.

Otherwise, ACMU generates a default alias, assuming that the program's DSNAME is the same as its DDNAME.

Other programs:

Programs run under IKJEFT01—DB2 programs, CLISTs and REXX procedures—are identified by name from the body of the step's SYSIN DD *, for example SYSTEM(xxx) or RUN PROGRAM(XXXXX) PLAN(YYYY).

In this case, CLISTs and REXX procedures are assumed to have been ported to shell scripts with the same names. Programs that access databases are handled like other programs.

The target system

ACMU assumes the following operating conditions:

• MVS libraries are generally represented by a UNIX directory of the same name, or an alias, containing files with the same names;
• MVS LOADLIBs have a corresponding UNIX directory of the same name, or an alias, containing programs and utilities with the same names;
• similarly, an MVS PDS member such as AAA.BBB.CCC(DDDD) is stored as a file named DDDD in a directory such as AAA.BBB.CCC or AAA/BBB/CCC;
• the STEPLIB-to-JOBLIB search path remains meaningful when translated into the UNIX PATH;
• for each output class used by the MVS jobs, a real or simulated printer is available through the UNIX lpr command, under a name defined in the ACMU parameters;
• the same principle applies to the simulated MVS log represented by MSGCLASS;
• each MVS utility has a UNIX equivalent with the same name, an alias, or a corresponding name defined in the ACMU parameters, and accepts the same parameter file for explicit SYSIN or SYSUT input;
• a valid DB2 and/or REXX environment is available on the target system for IKJEFT01 steps; a correctly configured UNIX procedure with the same name determines whether to run a DB2 program, REXX procedure or shell script.

For further information, please contact us.