• Home
• Services
• Products
• References
• About us
• Contact

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

Automation and Reliability

ACMU Methodology

For further information, please contact us.

ACMU Technical Summary

Introduction General Concept Convertion Main Parameters The JCL The Programs The Target System Sample JCL graph generated by ACMU

Estimate your JCL to Shell rewriting Cost JCL to convert 1000 3000 6000 12000 Average Steps/JCL 5 10 20 50 JCL lines (estimated)   Shell lines (estimated)   Shell lines written per day 50 (ugh, you're not in hurry) 100 (good MVS/UNIX programers) 300 (lucky you, they can copy/paste!) Manual Convertion cost: years/man       ( days/man) with good MVS programers having strong Unix skills A.C.M.U convertion cost: minutes        (Linux/x86)

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: That would take years and with high risk of human errors, and you know it. This is why HH&S has built since mid 90's a set of migration tools, that is getting richer and more reliable at 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.

General Concept

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

ACMU is designed as a compiler, and 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)

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:

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

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/MERGE 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

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.

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.