HH&S

Ingénierie Mainframe / Open depuis 1992

English Extranet

Produit HH&S

ACMU Automate de Conversion Mainframe Unix

Analyser un patrimoine de JCL MVS et le convertir en scripts Shell.

Automatisation et fiabilité

ACMU est un utilitaire de conversion de JCL MVS en scripts Shell UNIX/Linux qui analyse vos JCL et :

  • 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 ;
  • produit les graphes de JCL, les mémos et warnings 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 code Shell autonome, exécutable sous UNIX/Linux sans runtime propriétaire.

(*) 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 vers UNIX/Linux car il permet :

  • d'évaluer immédiatement la faisabilité du projet de migration ;
  • de migrer très rapidement 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 et la complexité, et identifions les JCL qui font appel à des utilitaires IBM ou à des outils spécifiques : ces JCL seront traduits en scripts Shell par ACMU, mais pourront nécessiter une adaptation technique ou fonctionnelle sur la 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. 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 JCL OK, avec Warning ou en erreur, et adaptons ACMU en conséquence jusqu'à obtenir 100% de scripts JCL techniquement et sémantiquement OK, opérationnels sur la cible UNIX/Linux. Nous 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 scripts Shell sont prêts et livrés au client.

Nous organisons des ateliers de présentation et d'intégration.

5

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

Pour plus d'information, contactez-nous.

Introduction

Une migration MVS vers UNIX/Linux 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 JCL, les COBOL et les utilitaires ;
  3. migration des datasets et bases de 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…), vérifier son adéquation, et se donner les moyens de la mettre en œuvre.

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 conversion des JCL.

Le convertisseur de JCL "ACMU" est chargé de transformer le JCL MVS en scripts Shell UNIX/Linux. 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 scripts Shell UNIX/Linux.

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 maîtrisant suffisamment le JCL MVS d'autre part.

Présentation générale

L'Automate de conversion JCL MVS - UNIX/Linux 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 :

  1. À 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).

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éé 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 ;
  • il gère les exécutions 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 ;
  • un 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.

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 utilitaires 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 première 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 1re 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ètres de l'Automate, notamment pour leurs 'DDNAME' lorsqu'ils sont implicites (SORTIN, SYSIN, SYSUTn ...)

ACMU supporte les JCL avec :

  • ordre INCLUDE
  • exécution 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 contrepartie 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ées 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'après le 'dsname' du programme COBOL.

Sinon, l'automate génère l'appel à 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, procédures 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 appel à 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 une 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édéterminé 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 contrepartie 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 ... explicite (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 reconnaît, 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'informations, contactez-nous.