Vancouver Utility JCL Converter - Advantages

We believe that UV Software has the most complete mainframe JCL conversion available for the following reasons:

1. Complete JCL conversion

UV Software's JCL Converter provides a comprehensive solution for migrating mainframe JCL to Korn or Bash shell scripts. It provides much more than just converting the JCL statements to equivalent shell script statements.

The JCL converter handles over 40 IBM and 3rd party utilities, such as: DFSORT,SYNCSORT,ADRDSSU,FTP,IDCAMS,IEFBR14,IEBCOPY,IEBGENER,ICEGENER,ICETOOL, IKJEFT01,DSNTIAUL,DSNUTILB,DFSRRC00,ADUUMAIN,AMUUMAIN,EZTPA00,QUIKJOB,etc. See 12 samples of JCL/script conversions begining at

2. Native Shell Scripts

Mainframe JCL is converted to native Unix/Linux Korn or Bash shell scripts, which is much more powerful solution than the JCL emulations provided by some other vendors.

You can immediatley add calls to Unix/Linux equivalents of non-IBM mainframe utilities that you may be using on the mainframe. JCL emulations (offered by some other vendors) restrict you to the mainframe utility replacements they provide (SORT,IDCAMS,IEBGENER,etc).

JCL emulations are very restrictive, you would have to write a COBOL program to call a shell script or 3rd party utility. UV Software JCL conversion to scripts gives you complete freedom to call any Unix/Linux software you might require.

3. 'uvsort'

UV Software provides uvsort which provides mainframe sorting capability on Linux/Unix/Windows systems. The JCL converter automatically converts mainframe SORT/DFSORT/SYNCSORT steps to uvsort steps.

Note that the 'unix system sort' is totally unsatisfactory for mainframe file types because: it can not handle fixed length record files without LineFeeds, cannot sort on packed decimal fields, does not have the select/delete/reformat capabilities of the mainframe SORT (& uvsort).

uvsort allows for hundreds of INCLUDEs, OMITs,& INREC/OUTREC FIELD reformats. uvsort also allows up to 20 input files, 60 output files. Actually the number of input files is unlimited using the option to input all files in a directory (or all files matching a pattern using '*' wildcard). See uvsort documentation at

Goto:   Begin this document End this document UVSI Home-Page

4. GDG (Generation) file handling

Unix, Linux,& Windows have no native Generation file handling. UV Software has a better solution than the mainframe for GDG file handling. Our GDG files are identified by a trailing underscore in the JCL/scripts. The physical files have a 6 digit number appended, which is more elegant than the mainframe '.G1234V00' (4 digit number plus "V00" which is almost never used).

Our GDG solution does not commit new generations until the script terminates normally, which means you can often simply rerun the script. Or you can rerun the script from any step since the JCL converter has rerun from any step built in to the conversion (no script changes required).

Note that the AIX 'gdgmgr' commits immediately, making it difficult to rerun scripts that terminate abnormally; you need to research & back out the GDG files that were committed up to the point of failure. See documentation for Vancouver Utility GDG file handling at

5. Profiles, Environment,& Directory Design

UV Software provides much more than conversion tools; we provide the profiles that give you a very powerful & flexible environment for conversion, development,& production.

The profiles provided include 2 critical variables RUNLIBS & RUNDATA that define the super directories housing the libraries & data-files for the logged-in user (programmer, production operator, or production scheduler).

Production & Development would usually be on different machines, but the RUNLIBS/RUNDATA variables can allow production & development on the same machine. A more useful advantage of RUNDATA might be to allow you to process separate sets of data-files (for unrelated companies/divisions) on the same machine, using the same set of libraries (JCL/scripts & COBOL programs).

The RUNDATA variable can also be used to provide different programmers different sets of test data. See more discussion of the profiles at

6. Minimizing post-conversion manual changes

We make the JCL conversion as complete as possible to minimize time consuming manual changes when testing the converted JCL/scripts. As noted above we providing conversions for over 40 IBM & 3rd party utilities.

One problem in JCL conversion is missing record sizes for input files to SORTs, IDCAMS, IEBGENER, etc - because the mainframe had this information available in the VTOC, but Unix/Linux/Windows does not provide this.

Our solution is to create a control-file prior to JCL conversion by extracting record-sizes for all files that are defined as output anywhere in the JCL. Note that record-sizes are declared in the JCL for mainframe output files, but not for input files.

There may still be some missing record-sizes for files that occur in the JCL only as input files & never as output files. We can automatically get them from the COBOL programs/copybooks or from the mainframe LISTCAT reports, and add them to the control-file before JCL re-conversion.

Goto:   Begin this document End this document UVSI Home-Page

7. converted JCL/scripts easy to read

The converted JCL/scripts will be familiar to mainframe personnel who may need to maintain them after the migration. The steps are clearly demarcated and numbered similarly to mainframe JCL. Some of the critical mainframe statements are carried forward as #comments to help understand the conversions (EXEC's & SORT parameters). For example, please see the multi-step JCL/script (JGL230.jcl & jgl230.ksh), at & 2F2.

8. Restart at any step built-in

The converted JCL/scripts allow "restart at any step" without having any code added for that purpose. For example, to restart at step 5, the command would be 'jobname step=S0050'. Note that steps are numbered by 10 to allow inserts. You could also stop at after any step. For example, to start at step 5 & stop at step 6 'jobname step=S0050 stop=S0060'

9. Return Code status checking

Mainframe JCL executions would automatically terminate on serious errors, but in Unix/Linux scripts, we must explicitly check the return code of every step to ensure success. See examples of return code checking in the demo JCL/scripts listed at

After COBOL steps are executed, the return code $? is saved in variable SCC and then checked by the 'testcc' function. Bad return codes will cause Abnormal Termination & any new generations of GDG files will not be committed. COBOL return codes less than 4 are not considered errors (as on the mainframe).

Return codes 1-4 are not just warnings for Unix utilities (uvsort,cp,rm,etc), so they are promoted to 91-94 before checking for serious errors.

10. Normal/Abnormal Termination messages & statistics

The converted JCL/scripts have 2 standard end points to report Normal or Abnormal Termination. These end points also report the steps executed and the termination code, which is returned as the job status.

See Normal terminations at the end of any demo JCL/script such as jar100.ksh at Abnormal terminations are detected by the 'testcc' function (at the end of each step) which would then call the 'jobabend51' function to terminate the job without committing any new generations of GDG files.

Goto:   Begin this document End this document UVSI Home-Page

11. Job Logging & Console Logging

'Job Logging' is most useful for programmer testing and operator run jobs. The job logs are captured in $RUNDATA/joblog/..., which could be the programmer's testdata directory or the operator's production directory.

'Console Logging' can be turned on by uncommenting a few lines provided at the end of the suggested user profile. Console logging would capture all console I/O from user login to logout - including any replies to JCL/script or program prompts (not captured by job logging).

The converted JCL/scripts report critical progress & error messages ,using the 'logmsg2' function, which ensures these critical messages get into the joblogs or console logs. Note that the logmsgs are preceded with a date/time/jobname stamp. See the joblog example at

12. replacing hard-coded values with $VARIABLEs

The JCL converter can optionally replace hard-coded values such as IP#s with $VARIABLEs in the converted JCL/scripts. This is a big advantage, because the IP#s may be different for the Unix system, and this also allows the IP#s to be different for testing vs production.

Programmer profiles would export IP#s appropriate for testing, but production profiles would export IP#s appropriate for production. See the notes at

13. Free JCL Sample Conversions

UV Software will perform free sample JCL conversions. Send 5-10 JCL's with any referenced PROCs & Parms (control card modules). We will return the converted equivalent Korn shell scripts for your inspection within a day or two.

14. DATA Conversions

UV Software can also convert your DATA files from EBCDIC to ASCII, preserving packed/binary fields that would be destroyed by FTP (ASCII translate mode). Files with packed/binary fields must be FTP'd in BINARY mode & then converted by uvcopy conversion jobs that are generated automatically from the COBOL opybooks. Please see examples at

15. COBOL Conversions

UV Software can also convert your mainframe COBOL to Micro Focus COBOL, COBOL-IT, or open-source GNU COBOL. See details at, or more recent concise COBOL conversion at

16. Conversion to JAVA (vs COBOL)

Several recent conversion clients have chosen to convert COBOL to JAVA, and the JCL converter has an option to convert the COBOL steps to call JAVA vs COBOL. Clients would supply their desired java call syntax & UV Software will modify the JCL converter accordingly.

Goto:   Begin this document End this document UVSI Home-Page

Visitor Counters for ThisYear and LastYear