English1 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
Automatisation et Fiabilité
- les 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 (cf. screenshots)
- 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.
- produit du pure code Shell, qui tourne sur tout UNIX / Linux sans aucun runtime propriétaire.
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
Le client envoie quelques JCL représentatifs
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 pourront nécessiter une adaptation technique/fonctionnelle sur cible.
Nous présentons une offre forfaitaire avec un périmètre, un coût, un délai.
Go / No go ?
Le client transmet la matière, en totalité, ou par lots.
Un premier lot pilote peut être réalisé rapidement et servir de PoC.
Nous mettons les JCL dans ACMU et pressons le bouton :
ACMU produit les Cross-References JCL / Programmes / Procs / Datasets / Variables de JCL,
les documentations, graphes de JCL, mémos et warnings d'intégration.
(cf. screenshots)
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.
We vérifions que nous avons les wrappers Shell UNIX pour tous les programmes listés dans la Cross-Ref.
Nous passons alors un test "dry-run" sur tous les scripts, en simulant les données et programmes client.
Les Shells scripts sont prêts et livrés au client
avec des ateliers de présentation, d'intégration.
puis nous accompagnons le client pour les recettes techniques, utilisateurs,
la mise en production et la VSR.
Pour plus d'information, contactez-nous.
Présentation technique ACMU
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 :
- Migration des Programmes CICS
- Migration des Programmes Batch avec les JCLs, les Cobols, les utilitaires
- Migration des datasets et bases des données
- 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 : cela prendrait des années, avec un risque élevé d'erreurs humaines. C'est ce qui a amené HH&S depuis le milieu des années 90 à créer une suite d'outils de conversion, enrichis, rendus plus fiables à chaque migration :
- outils de portage des programmes COBOL,
- outils de portage des datasets
- outils de convertion des JCLs.
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.
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 est conçu comme un compilateur, et fonctionne en 3 phases :
- A partir d'une liste de JOB, il transcrit le 'JCL' MVS en forme XML exportable,
- Il produit les Scripts Shell correspondants à partir des fichiers XML obtenus.
- Il produit la documentation de chaque script (Journal de conversion, Fiche d'opération)
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
- Les paramètres généraux de la conversion,
- Le JCL du JOB concerné,
- Les programmes sources COBOL s'ils sont accessibles,
- Les conditions d'exploitation sur la machine cible.
Ces 4 éléments sont résumés ci-aprés.
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 »
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/MERGE 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
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.
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.
