It takes 1 second to convert a MVS JCL into a UNIX Shell Script!

".../... 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 [USENIX '04 Technical Program] Migrating an MVS Mainframe Application to a PC

Introduction

ACMU is an MVS JCL to Unix Shell conversion utility that analyzes your JCLs and:
  • automatically converts MVS JCL into structured, easy-to-read, human error free, detailed commented Unix Shell scripts when analyzed JCL is qualified for conversion
  • builds Cross-References JCL/Programs/Procs/Files/JCL Variables
  • builds JCL graphs, integration memos and warnings
  • identifies JCLs not suitable for conversion (*), giving necessary technical informations for MVS programmers to modify the JCL, or for Unix programmers to make shell script adaptation.
(*) Usualy, a low percentage of JCL, using IBM specific utilities that will be adapted to target using ad hoc technologies. This is for instance the case for OPC Plan update using EQQ, ISPF macros, or writing to JES2 Internal Reader.

ACMU stands thus as the essential tool to any MVS to UNIX migration project, as it makes it possible to:
  • immediately evaluate the migration project faisability
  • migrate in a very fast way your JCL chains
  • build migration plan and evaluate the budgets and plannings of migration.
  • quit JCL for good (as some challengers simply interpret JCL on UNIX, which implies to keep your JCL skills)

ACMU Methodology

1)
Client sends some reprensentative JCLs

2)
We analyze the feasibility of automation, complexity, and we identify JCLs that use IBM legacy utilities or specific tools: These JCLs will be translated into Shell scripts by ACMU but they might require some technical / functional adaptation on target.
We present a business offer with a scope, fixed price, and conversion & test planning.

3)
Go / No go ?

4)
Client sends material, in whole or parts. Typically, a first part can be realized as a Poc.
We process JCLs with ACMU.
ACMU produces Cross-References: JCL / Programs / Procs / Datasets / JCL Variables, as well as documentations, JCL graphs, memos and warnings for integration.

We analyze ACMU convertion results: JCL Ok, with Warning, or with Errors and we adapt ACMU consequently
until having 100% of JCLs scripts technicaly, semanticaly Ok and ready for target UNIX/Linux. We then run dry-tests on all generated scripts, simulating data and programs.

Shells scripts are ready and delivered to client
along with workshop for integration, tests, scheduling.

5)
then we support client during technical and User Acceptance tests, Go Live, and initial maintenance.

For further information, please contact us.

ACMU Summary

  1. Introduction
  2. General Concept
  3. Convertion Main Parameters
  4. The JCL
  5. The Programs
  6. The Target System
  7. Annexe A : sample MVS JCL
  8. Annexe B : sample MVS JCL diagram
  9. Annexe C : sample Shell Script output
  10. Try online to convert your JCL!
    A JCL submition page is available where you can submit your own JCLs for Shell convertion
Estimate your JCL to Shell rewriting Cost
JCL to convert
Average Steps/JCL
JCL lines (estimated)  
Shell lines (estimated)  
Shell lines written per day
Manual Convertion cost :
years/man       ( days/man)
with good MVS programers having strong Unix skills

A.C.M.U convertion cost :
minutes        (Intel P4 3Ghz)
    

début de page

Introduction

Migration from MVS to UNIX has never been an easy job.

Thanks to its experience, HH&S has set up its migration methodology on following points :

  • Migration of CICS applications
  • Migration of Batch applications, including JCLs, Cobols, utilities
  • Migration of datasets and databases
  • Migration of production

For each of these points, you need to define a strategy (which product shall we use, what are the constraints on target system, ...), validate that the strategy fits, and find the necessary tools.

When it comes to the JCL and programs, the volume is often so huge that it is hopeless to think about doing the job manually, and you know it. This is why HH&S has built since mid 90's a set of migration tools, that is getting richer during each migration :

  • tools for porting COBOL programs
  • tools for porting datafiles
  • tools for converting JCLs
Our JCL converter, named "ACMU" for "Automate de Convertion MVS/UNIX" in french, is in charge of converting MVS JCL into UNIX Shell Scripts.

It is not a 100% generalized tool ; it needs to take in consideration particular clients situation.
But under certain conditions, when JCL is normalized, when it respects major "standards", when the very particular pieces have been identified and isolated, ACMU can convert within a few minutes thousands of MVS JCL to UNIX Shells.

Experience show that 100 lines de JCL generate 400 lines of shell (including 60% of comments for documentation and production) :
For 1000 JCLS having a dozen steps each : 150000 lines of JCL and 600000 lines of shell.
Which is, let's say, 3 years of work for a pretty good UNIX specialist, having a deep knowledge of Shell and UNIX system ressources on one side, and having quite a good understanding of MVS JCL on the other side.

début de page

General Concept

ACMU converter's purpose is to create a UNIX Shell script from a MVS JCL.

ACMU operates in 3 phases :

  1. from a JOB list, it analyses the JCL and exports it into XML object
  2. it converts XML objects into Shell scripts
  3. it produces associated documentation (conversion journal , operation sheet)
JCL    XML
XML    Shell
XML    Documentation

Phase 1 can operate either on MVS or UNIX host

Phases 2 and 3 operate directly on target UNIX host

ACMU is based on following concept :

  • each MVS JCL = 1 Shell script
  • each Step = a call to a UNIX program/utility
  • resulting Shell script is 100% standalone : does not require any runtime

Each output shell script reflects exactly the original JCL logic:

  • 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

For each JOB's convertion, ACMU depends on 4 elements :

  1. general convertion parameters
  2. JCL of the JOB
  3. source COBOL programs (if accessibles)
  4. production conditions on target UNIX hosts

Let's detail the 4 elements :

début de page

Conversion main parameters

ACMU settings will define :

  • Base shell to use (ksh, bash, ...)
  • UNIX naming of replacement utilities (catalogs, IDCAMS, IEBGENER...)
  • UNIX naming of sequential acces devices (tapes) if necessary
  • UNIX naming of SYSOUT and SYSLOG printer for each print class
  • names of UNIX directories equivalents to MVS 'LOADLIB'
  • names of UNIX directories for datafiles and data 'libraries'
  • names of UNIX directories for COBOL sources, during convertion, or during normal processing
  • DDNAME's for each program when only mentioned in « DD » cards

début de page

The JCL

ACMU's phase 1 is used with normalized JCL, that respects MVS hosts's standarts.

It includes a JCL syntax analyser and a XML parser that transforms JCL into XML object

This phase can operate either on original MVS hosts, or any kind of UNIX (or windows...) hosts after transfering JCLs and optionaly, COBOL sources.

JCL Syntax Analyzer assumes that :

  • line #1 of JCL is a 'JOB' card
  • "classical" datafiles (PDS, Sequential Data Set ..),  are portable to UNIX  (fixe or variable record length, text or binary)
  • no significant cataloged procedures (substitution within DD cards)
  • explicit sort parameters : always include the SORT/MERG and RECORD lines
  • classical utilities are explicitly described in ACMU's parameters, specificaly the 'DDNAME's when they are implicit (SORTIN, SYSIN, SYSUTn ...)
ACMU handles JCL including:
  • INCLUDE statements
  • conditionnal statements IF / COND=
  • JCL variables
  • OPC variables
  • Concatenated SYSIN
  • GDG

début de page

The programs

For the Shell script to run correctly on target UNIX hosts, we assume programs satisfy following rules :

  • they have all been ported or have an equivalent on target UNIX
  • no loading with dynamic « LINKEDIT »
  • they are located on the UNIX directory corresponding to their MVS LOADLIB.
  • datas are located on the UNIX directories correcponding to their MVS locations
  • 'DDNAME's are those mentioned in correspondinf MVS step
  • programs exit using same « Return Code » on MVS and UNIX.


COBOL programs :

  'SELECT ddname ASSIGN  TO dsname ...' clauses are processed as described :

If target UNIX's COBOL compiler takes in account shell environment varaible correcponding to ddname, then ACMY generates a UNIX alias in the form : 'ddname ==> dsname', from JCL's dsname .

Otherwise, if COBOL program source is available at the time of convertion, ACMU generates a 'hard' UNIX alias from the 'dsname'.

Otherwise, ACMU generates a 'call' to a routine that will do the job dynamicaly during execution, if COBOL source (or subset including SELECT clauses) si available at this time under same conditions (program name in the step = program source name).

Otherwise, ACMU generates a default alias, assuming program's DSNAME equals DDNAME.

Other Programs :

Programs under control of IKJEFT01 (DB/2, Clist, REXX procedures) are processed using their names, as from the body of 'SYSIN   DD  *'  concerned step (ex : 'SYSTEM(xxx)', 'RUN  PROGRAM(XXXXX) PLAN(YYYY)' ).

In the case, CLISTs and REXX procedures are supposed to have been ported in Shell scripts using same names. Programs calling databases are considered like other programs.

début de page

The target system

ACMU takes for granted following rules :

  • in a general manner, MVS libraries have to be a UNIX directory (or alias) using same name : that's where datafiles are located, using same names
  • MVS 'LOADLIB's have a corresponding UNIX directory (or alias) using same name : that's where programs and utilities are located, using same name
  • same idea for datafiles : an MVS PDS member 'AAA.BBB.CCC(DDDD)' is to be a DDDD file located on AAA.BBB.CCC/ directory (or AAA/BBB/CCC/ directory)
  • search path STEPLIB==>JOBLIB, turned into UNIX PATH , makes sense
  • for each print class defined and used in MVS JOBs, there should be a printer, (true or simulated), available to UNIX lpr command, with a name mentioned in ACMU's general parameters
  • same thing to MVS log (MSGCLASS)
  • each utility used in MVS JOBs has to have its equivalent under UNIX, using same name (or aliased), with same parameter file if it is an explicit SYSIN, SYSUT (ex : SORT,   ....)
  • We assume target UNIX hosts has a valid DB2 and/or REXX version, for all the IKJEFT01 steps : a UNIX procedure with same name, recognizes (if parameters are correct) it has to start a DB2 program, or a Shell/Rexx script

For further information, please contact us.