Une seconde pour convertir un JCL MVS en Shell Script UNIX !

".../... 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

Présentation

ACMU est un utilitaire de conversion de JCL MVS en Shell UNIX/Linux qui analyse vos JCL et :
  • convertit automatiquement en scripts Shell UNIX/Linux parfaitement structurés et lisibles, sans erreur humaine, avec commentaires détaillés lorsque le JCL analysé est qualifié pour la conversion
  • produit instantanément les Cross-References JCL/Programmes/Procédures/Fichiers/Variables de JCL
  • produit les graphes de JCL, les mémos et warning de JCL nécessaires à l'intégration
  • identifie les JCL non qualifiés pour la conversion (*), avec les informations techniques nécessaires aux programmeurs MVS pour modifier le JCL, ou aux programmeurs UNIX pour adapter le shell correspondant.
(*) En général, pourcentage assez faible de JCL utilisant du spécifique IBM qui sera adapté en cible par des technologies ad hoc. C'est le cas par exemple des mises au plan OPC par EQQ, des macros ISPF, ou des écritures dans l'Internal Reader JES2

ACMU se positionne ainsi comme l'outil indispensable à tout projet de migration MVS / UNIX car il permet :
  • d'évaluer immédiatement la faisabilité du projet de migration
  • de migrer très rapidemment la partie Batch JCL
  • de concevoir le plan de migration et d'estimer les budgets et les délais de réalisation
  • d'abandonner définitivement le JCL (alors que des concurrents interprêtent le JCL sous UNIX, ce qui oblige à conserver la maîtrise du JCL MVS)

Méthodologie ACMU

1)
Le client envoie quelques JCL représentatifs

2)
Nous analysons la faisabilité de l'automatisation, la complexité, et identifions les JCL qui font appel à des utilitaires IBM ou des outils spécifiques : ces JCL seront traduits en Shell scripts par ACMU mais ils nécessiterons une adaptation technique/fonctionnelle sur cible.
Nous présentons une offre forfaitaire avec un périmètre, un coût, un délai.

3)
Go / No go ?

4)
Le client transmet la matière, en totalité, ou par lots. Typiquement, un premier lot pilote peut être réalisé rapidement et servir de PoC.
Nous passons les JCL à la conversion ACMU.
ACMU produit les Cross-References JCL / Programmes / Procs / Datasets / Variables de JCL, les documentations, graphes de JCL, mémos et warnings d'intégration.

Nous analysons les résultats de conversion ACMU : les JCLs Ok, en Warning, ou en Erreur et adaptons ACMU en conséquence
jusqu'à obtenir 100% de scripts JCL techniquement, sémantiquement Ok et opérationnels sur cible UNIX/Linux.

Les Shells scripts sont prêts et livrés au client
avec des ateliers de présentation, d'intégration

5)
puis nous accompagnons le client pour les recettes techniques, utilisateurs, la mise en production et la VSR.

Pour plus d'information, contactez-nous.

Sommaire ACMU

  1. Introduction
  2. Présentation générale
  3. Paramètres généraux de la conversion
  4. Le JCL
  5. Les programmes
  6. Le système cible
  7. Annexe A : Exemple de JCL MVS
  8. Annexe B : Diagramme du JCL MVSScript Shell généré
  9. Annexe C : Exemple de Script Shell généré
  10. Testez en ligne notre convertisseur !
    Une page de démonstration en ligne est disponible : vous pouvez y soumettre vos propres JCLs.
Estimez votre coût de conversion JCL/Shell
JCL à convertir
Nombre moyen de steps/JCL
Lignes de JCL (estimé)  
Lignes de Shell (estimé)  
Lignes de Shell écrites par jour
Coût de Conversion manuelle :
années/homme       ( jours/homme)
pour de bons programmeurs MVS connaissant très bien UNIX

Coût de Conversion A.C.M.U. :
minutes        (Intel P4 3Ghz)
     

début de page

Introduction

Une migration MVS/UNIX n'est jamais simple.
L'expérience aidant, HH&S a mis au point sa méthodologie autour des points suivants :

  1. Migration des Programmes CICS
  2. Migration des Programmes Batch avec les JCLs, les Cobols, les utilitaires
  3. Migration des datasets et bases des données
  4. Migration de l'exploitation

Pour chacun des points, il faut entre autres définir une stratégie (quel produit va-t-on utiliser, quelles sont ses contraintes sur le système cible ...),  verifier son adéquation, et se donner les moyens de la mettre en oeuvre.

En ce qui concerne le JCL et les programmes, la volumétrie est souvent telle qu'il est hors de question de faire la migration manuellement. C'est ce qui a amené HH&S depuis le milieu des années 90 à créer une suite d'outils de conversion, enrichis à chaque migration :

  • outils de portage des programmes COBOL,
  • outils de portage des datasets
  • outils de convertion des JCLs.
Le convertisseur de JCL "ACMU" est chargé de transformer le JCL MVS en Scripts SHELL UNIX.

Il n'est pas généralisé : il faut l'adapter au cas par cas.
Mais lorsque les conditions s'y prêtent, que le JCL est bien normalisé, qu'il respecte les standards propres au site, et qu'on a bien isolé les cas particuliers, l'automate peut, en quelques minutes, convertir des milliers de JCL MVS en shell UNIX.

L'expérience montre que pour 100 lignes de JCL, on obtient 400 lignes de shell (dont 60% de commentaires pour la documentation et l'exploitation) :
Pour un millier de Jobs d'une douzaine de steps chacun : 150000 lignes de JCL et 600000 lignes de shell.
Soit 3 ans de travail pour un trés bon spécialiste UNIX, connaissant parfaitement le Shell et les ressources de son Système UNIX d'une part, et maitrisant suffisamment le JCL MVS d'autre part.


début de page

Présentation Générale

L'Automate de conversion JCL MVS – UNIX a pour but de créer un script shell à partir d'un JCL MVS.

L'Automate fonctionne en 3 phases :

  1. A partir d'une liste de JOB, il transcrit le 'JCL' MVS en forme XML exportable,
  2. Il produit les Scripts Shell correspondants à partir des fichiers XML obtenus.
  3. Il produit la documentation de chaque script (Journal de conversion, Fiche d'opération)
JCL    XML
XML    Shell
XML    Documentation

La première phase peut être exécutée indifféremment sur le Système MVS ou le Système UNIX

Les phases 2 et 3 sont exécutées directement sur le Système UNIX.

ACMU adopte le principe suivant :

  • chaque Job MVS = 1 script Shell
  • chaque Step = 1 appel à un programme/une procédure UNIX
  • les scripts Shell produits sont 100% standalone : ils ne nécessitent aucun runtime spécifique

Chaque script crée est donc le reflet fidèle de la logique du JCL source :

  • Il est composé de la séquence originale de steps
  • Le Job est "restartable" au niveau du step
  • Il crée un journal pour tout le job ou un journal unitaire par step
  • It gère les exécution conditionnelles et les codes retour suivant la logique du JCL source, et se termine par un "MAX Condition Code" récupéré par votre ordonnanceur
  • Les noms de fichiers/répertoires pour les programmes et les données sont hautement configurables pour s'adapter à vos environnements cibles
  • Il gère les "dispositions" de fichiers (DISP=) "à la MVS" ainsi que le versioning de fichiers GDG
  • il appelle les programmes (Cobol ou autre) en passant les paramètres d'appel ainsi que les SYSIN statements
  • la plupart des utilitaires IBM (IDCAMS, IKJEFT01, ..) sont fournis en tant que procédures Shell/Perl
  • utilitaire de tri à syntaxe compatible DF/SORT

Pour la conversion de chaque JOB, l'Automate s'appuie sur 4 éléments :

  1. Les paramètres généraux de la conversion,
  2. Le JCL du JOB concerné,
  3. Les programmes sources COBOL s'ils sont accessibles,
  4. Les conditions d'exploitation sur la machine cible.

Ces 4 éléments sont résumés ci-aprés.

début de page

Paramètres généraux de la conversion

Les paramètres de l'Automate définissent notamment :

  • Nom du shell à utiliser (ksh, bash, ...)
  • Appellation des utiltaires de remplacement MVS – UNIX (catalogues, IDCAMS, IEBGENER...)
  • Appellation des dérouleurs de bandes ou lecteurs de cassettes si nécessaire
  • Nom des imprimantes SYSOUT et SYSLOG pour chaque classe d'impression
  • Noms des répertoires pour l'équivalent des 'LOADLIB' MVS
  • Noms des répertoires pour les fichiers et 'librairies' de données
  • Noms des répertoires pour les sources COBOL, à la conversion, ou à l'exécution
  • DDNAME's pour chaque programme  où ils n'apparaissent que dans les 'cartes' « DD »

début de page

Le JCL

La première phase de l'Automate est utilisée lorsque le JCL est bien normalisé et respecte les standards du site MVS à migrer.

Elle intègre un analyseur syntaxique de JCL, et un 'parser' XML permettant de transcrire le JCL en XML.

Cette premiere phase fonctionne indifféremment sur le système source MVS, ou n'importe quel autre système (UNIX, Windows) sur lequel on a déjà transféré les sources JCL, et éventuellement COBOL.

L'analyseur syntaxique de JCL suppose les pré-requis suivants:

  • La 1ere ligne de JCL est une 'carte JOB' .
  • Les fichiers classiques, (PDS, Sequential Data Set ..),  sont convertibles et exploitables en UNIX  (fixes ou variables, texte ou binaire)
  • Pas de procédures cataloguées significatives (substitution dans les cartes DD)
  • Paramètres de tri explicites : contiennent toujours les lignes SORT/MERG et RECORD
  • Les programmes utilitaires classiques sont explicitement décrits dans les paramètre de l'Automate, notamment pour leurs 'DDNAME' lorsqu'ils sont implicites (SORTIN, SYSIN, SYSUTn ...)

ACMU supporte les JCL avec:

  • ordre INCLUDE
  • execution conditionnelle IF / COND=
  • variables de JCL
  • variables OPC
  • concaténation de SYSIN
  • utilisation de GDG

début de page

Les programmes

Pour que le Script Shell fonctionne correctement sur le système cible, on suppose que les programmes satisfont aux conditions suivantes :

  • Ils sont tous portés, ou ont un équivalent, sur la machine cible.
  • Pas de chargement impliquant un « LINKEDIT » dynamique.
  • Ils résident dans le répertoire UNIX correspondant à leur LOADLIB MVS.
  • Les données résident dans les répertoires UNIX correspondant à leur contre-partie MVS
  • Les 'DDNAME' sont bien ceux répertoriés dans le Step MVS correspondant.
  • Les programmes produisent le même « Return Code » sous MVS et UNIX.


Cas des programmes COBOL :

Les clauses  'SELECT ddname ASSIGN  TO dsname ...' sont traités de la manière suivante :

Si le compilateur COBOL du système-cible UNIX prend en compte la variable d'environnement Shell correspondant au ddname, alors l'Automate génère directement un alias UNIX de la forme 'ddname ==> dsname', d'aprés le dsname du JCL.

Sinon, si le source COBOL du programme est accessible sous son nom au moment de la conversion, alors l'Automate génère 'en dur' directement l'alias UNIX  d'apres le 'dsname' du programme COBOL.

Sinon, l'automate gènère l'appel a une routine qui fera le même travail, de manière dynamique, à  l'exécution, sous réserve que le source COBOL (ou un extrait avec les clauses SELECT) soit accessible à ce moment-là, dans les mêmes conditions (nom du programme dans le step = nom du programme source, à l'extension prés).

Sinon, l'automate génère un alias par défaut, en supposant que le DSNAME du programme est égal au DDNAME.

Autres Programmes :

Les programmes sous contrôle IKJEFT01 (DB/2, Clist, procedures REXX) sont traités par leur nom, d'aprés le corps du 'SYSIN   DD  *'  du Step concerné (ex : 'SYSTEM(xxx)', 'RUN  PROGRAM(XXXXX) PLAN(YYYY)' ).

Dans ce cas, les CLIST, procédures REXX sont supposées être portées en scripts shell de même nom, et les programmes faisant appels à la base de données sont traités comme les autres programmes.

début de page

Le système cible

L'Automate considère comme acquises les conditions d'exploitation suivantes :

  • D'une manière générale, les librairies MVS sont représentées par un répertoire de même nom (ou un alias) sur le Système UNIX : on y trouve les mêmes fichiers sous le même nom.
  • Les 'LOADLIB' MVS ont un correspondant de même nom (ou un alias) sur le système cible: on y trouve les mêmes programmes exécutables, sous le même nom.
  • Mème remarque pour les données  : un membre de PDS MVS de la forme 'AAA.BBB.CCC(DDDD)' réside sous le nom 'DDDD' dans un arborescence UNIX de type AAA/BBB/CCC ou AAA.BBB.CCC
  • Le chemin de recherche STEPLIB==>JOBLIB, traduit en PATH UNIX, a un sens.
  • Pour chaque classe d'impression définie et utilisée dans les JOB MVS, il y a une imprimante, vraie ou simulée, accessible par la commande UNIX  'lpr', avec un nom prédeterminé dans les paramètres généraux de l'Automate..
  • De même pour la log MVS simulée (MSGCLASS).
  • Chaque utilitaire MVS possède sa contre-partie sous UNIX, avec le même nom, ou un alias de même nom, ou avec un nom cité en correspondance dans les paramètres généraux de l'Automate, et avec le même fichier paramètre s'il s'agit d'un SYSIN, SYSUT ... explicte (ex : SORT,   ....)
  • On suppose une version de DB2 et/ou REXX valide sur le système cible, pour tous les steps IKJEFT01 : une procédure UNIX de même nom reconnait, sous réserve d'un paramétrage correct, qu'elle doit lancer un programme DB2, ou une procédure REXX, ou un Script Shell.

Pour plus d'information, contactez-nous.