ACMU   Présentation   Exemples   Convertissez votre JCL !   Feedback   Migration Mainframe   Extranet

• crée automatiquement les scripts Shell UNIX correspondant lorsque le JCL analysé est qualifié pour la conversion (estimation à 80% des chaînes)
   
• identifie les JCL non qualifiés pour la conversion (estimation à 20% des chaînes), avec les informations techniques nécessaires aux programmeurs MVS pour modifier le JCL, ou aux programmeurs UNIX pour adapter le shell correspondant.
   

• d'évaluer immédiatement la faisabilité du projet de migration
• d'estimer la charge de travail nécessaire au portage des chaines JCL sous UNIX
• 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 les concurrents interprêtent le JCL sous UNIX, ce qui oblige à conserver la maîtrise du JCL MVS)

Historique

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.

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

Un JOB MVS = Un script Shell
Un Step MVS = Un programme UNIX

• Il est divisé en « Steps »
• Il crée un seul journal des erreurs pour l'ensemble du sript.
• Il se termine avec un 'return code'  destiné à qui de droit.
• Il a un 'PATH' de base pour tous les programme (« JOBLIB »).
• Chaque Step accepte un 'PATH' supplémentaire (« STEPLIB »).
• Chaque Step complète le journal des erreurs et crée son propre journal (« SYSOUT »).
• Chaque Step produit un 'return code' exploitable par le Step suivant.

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.

Paramètres généraux de la conversion

Le fichier paramètre de l'Automate indique 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/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 ...)

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.

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.

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