ACMU   Introduction   Typical JCL   Shell output   COBOL prog.   Try your JCL !   Feedback   Mainframe Migration   Extranet

• automatically creates corresponding Unix Shell scripts when analyzed JCL is qualified for conversion (estimated to 80% of chains)
   
• identifies JCLs not suitable for conversion (estimated to 20% of chains), giving necessary technical informations for MVS programmers to modify the JCL, or for Unix programmers to make shell script adaptation.
   

• immediately evaluate the migration project faisability
• estimate necessary workload to port JCL chains to Unix
• 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)

Intro

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
  

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

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 hours 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 jobs 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 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

1 JOB MVS = 1 script Shell
1 Step MVS = 1 UNIX program

• it is composed of « Steps »
• it creates one error log for all steps of the script
• it ends with a 'return code' , that your scheduler will process
• it has a base 'PATH' for all called programs (« JOBLIB »).
• each step can take a supplementary 'PATH' (« STEPLIB »).
• each step writes to the error log, and its own journal (« SYSOUT »).
• each step produces a 'return code' taken in account by the next step

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

Conversion Main Parameters

ACMU parameter files includes :

• 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/MERG and RECORD lines
• classical utilities are explicitly described in ACMU's parameters, specificaly the 'DDNAME's when they are implicit (SORTIN, SYSIN, SYSUTn ...)

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.

  '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.

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 : un MVS datafile '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