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

Les quatres éléments indispensables à une société de service en migrations :

  1. L'Expérience
  2. La Méthodologie
  3. Les Outils
  4. La Technicité

L'Expérience

De culture initiale Mainframe IBM (DOS/VS, MVS, VM/CMS), et maîtrisant parfaitement les systèmes ouverts et propriétaires UNIX (Linux, IBM, Sun, HP), nous connaissons bien les enjeux et les difficultés d'un projet de migration Mainframe.
Seule une double compétence Mainframe/Unix peut élaborer, conseiller, superviser, et mener à bien une migration Mainframe ; en effet, deux spécialistes, l'un Mainframe, l'autre Unix, parlant entre eux ne se comprendront pas : leurs deux mondes étant fondamentalement différents.
L'expérience montre que la collaboration d'une équipe mainframe avec une équipe Unix ne peut être efficace que si ces équipes sont supervisées par une double compétence, qui leur aura présenté, expliqué, détaillé les pièges techniques à éviter.
Ainsi, s'il est envisageable de migrer relativement facilement des programmes exécutables COBOL et des bases DB/2, qu'en est-il
  • du JCL ?
  • des structures de données (DSN, VSAM) ?
  • des références à ces données (cartes DD) ?
  • des fichiers binaires EBCDIC ?
pour ne citer que quelques évidences ...

Des pièges plus bloquants, issus d'une méconnaissance des mondes mainframe et UNIX, attendent les équipes si on les a mal préparées et sélectionnées, en compétence et en nombre.

Ici, seules l'expérience et une très forte technicité comptent pour bien préparer et réaliser une migration, et non pas la taille de la société et son nombre de programmeurs UNIX/COBOL.

Avec, à notre actif, des migrations et des participations actives aux migrations dans les domaines suivants :

  • DOS/VS -> MVS/XA
  • VM/CMS -> MVS OS/390
  • VM/CMS -> Windows NT.4 (via notre émulateur EVMPR)
  • VM/CMS -> AIX
  • MVS -> AIX,
  • VM/MVS -> z/VM / z/Linux,
  • z/OS -> Linux,
  • Désenclavement (carve-out) de Lpars z/OS
  • Fusion (merge) de Lpars z/OS
Avec notre maîtrise du portage et de la migration :
  • des programmes COBOL, PL/1, FORTRAN, Assembleur IBM 360, APL
  • des procedures JCL, CLIST, REXX
  • des fichiers VSAM
  • des bases DB2, DATACOM-DB, IMS, DL1,
nous sommes en mesure de proposer notre expertise et notre savoir-faire, à tout niveau du projet :
  • Conseil, Expertise, Pilotage,
  • Organisation et Supervision,
  • Conception des Request For Information et Request For Proposal
  • Recherche d'architecture logicielle cible,
  • Etude de faisabilité avec Proof of Concepts,
  • Aide aux spécifications techniques
  • Réalisation
  • Formations (cf. notre catalogue)
  • Mise en place de l'exploitation sur systèmes cibles.

Consulter nos articles sur les migrations Linux vers z/Linux S/390 et NT vers Linux

La Méthodologie

Si chaque contexte de migration MVS est unique, de par son environnement applicatif, ses traitements, son réseau, son organisation, notre méthodologie prend en compte tous ces éléments pour proposer des solutions qui répondent aux attentes stratégiques et économiques du client.

Son modèle a été éprouvé.

  • Il est corrigé, enrichi, au fur et à mesure des différents projets de migration.
  • Il prend en compte la globalité de l'architecture et des ressources existantes en phase pré-migration, en phase transitoire, et en phase finale mise en production et post-migration.
  • Il distingue les différentes tâches, leur répartition en compétences spécifiques, leur synchronisation, leur supervision.
  • Il comprend l'analyse des architectures, des traitements, des données, des interfaces, et leurs adhérences.
  • Il spécifie les solutions techniques et outils à employer pour chaque tâche.
  • Il permet d'estimer le temps, les ressources humaines, logicielles, matérielles necessaires, et le coût de l'opération.
Méthodologie
Phase pré-migration Phase transitoire Phase post-migration
Production
Mainframe		    
Production
Mainframe
Qualification
UNIX		 Production
UNIX

Inventaire du patrimoine MVS

Il s'agit d'une phase préalable à toute opération de migration.
Elle consiste à réaliser un inventaire exhaustif des traitements Batch / TP, des sous-systèmes mis en oeuvre, des données (séquentiels, VSAM, IMS, DB2, SPITAB, ...) et des relations Traitements <> Données : il s'agit des Références Croisées (ou 'CrossRef').
Cette inventaire sert à identifier les traitements et données à migrer --- en général, des objets sont obsolètes mais toujours présents sur le mainframe --- et à quantifier ces élements à migrer.

RFP, ROI

A ce stade, le client possède les éléments précis pour élaborer son Cahier des Charges et procéder éventuellement à une consultation ouverte ('Request For Proposal'). A l'issue du RFP, il peut alors déterminer son retour sur investissement ('Return On Investment') et décider de lancer l'opération.

Proof Of Concept

Après une brève étude de l'existant, nous sommes capables de proposer une phase de Proof of Concept Batch.
Cette phase consiste à identifier un traitement représentatif et ses composants (JCL, COBOL, Datasets, tables DB2) et à migrer ce traitement sur Système Ouvert et à prouver qu'il est opérationnel et iso-fonctionnel.

A titre d'exemple, lors d'une récente opération, nous avons réalisé le P.o.C. batch z/OS - UNIX
  • opérationnel sur 2 systèmes UNIX (AIX et Linux), avec 4 compilateurs (2 compilateurs COBOL, 2 compilateurs Java), 3 bases de données (DB/2 UDB, PostGres, MySQL)
  • soit un panel de 24 combinaisons techniques de plateformes cibles proposées au client
  • ... en moins de 3 semaines (*).
(*) Ce traitement ne comportait pas de SPITAB, VSAM, NATURAL, Assembleur, PL1, IMS ; le JCL a été converti automatiquement en Shell script par ACMU ; les SORT ont été implémentés sous UNIX/Linux par XSM.

La phase suivante est le Proof of Concept TP. Cette phase consiste à évaluer parmi les solutions du marché une ou plusieurs solutions de migration du CICS, et la mettre en oeuvre sur un périmètre restreint et représentatif.

Cette démarche méthodologique permet au client --- avec un faible investissement en temps et en coûts ---
  • de s'assurer de la faisabilité technique de la migration,
  • d'exprimer des préferences techniques (système cible, langages, compilateurs, SGBDR) concordant avec le socle technique de son Système d'Informations,
  • d'obtenir des informations fiables concernant charges, budget, planning,
  • de vérifier qu'une petite structure d'experts indépendante de tout éditeur, constructeur, fournisseur de service, est la solution la plus efficace pour piloter un projet de migration et tous les acteurs y participant.

Pilotage

Toutes ces opérations nécessitent une profonde expertise dans le domaine.
Leur pilotage doit être confié à une personne maîtrisant parfaitement le mainframe IBM, les Systèmes Ouverts et connaissant les acteurs et solutions du marché.
Pour des opérations de grande envergure, HH&S propose son assistance au pilotage du projet.
Contactez-nous pour discuter de vos projets de migration.


Les Outils

L'analyse d'une migration permet de proposer certains outils ayant pour objectifs d'automatiser une tâche, de la fiabiliser, de l'accélérer, de réduire ses coûts.
Pour certaines tâches, le recours à des utilitaires ou "moulinettes" sera conseillé, une fois argumenté que le temps passé à chercher ou réaliser ces utilitaires permettra une économie effective de temps et de coût.

Nous abordons ici une partie essentielle de la migration MVS vers UNIX : La conversion du JCL MVS en Shell UNIX

Considérant qu'il y avait un manque réel d'utilitaires dans ce domaine, après avoir rencontré et évalué des utilitaires existants, estimé leur performance, leur efficacité, et leurs coûts, nous sommes retournés à notre coeur de métier "Programmeurs Système" et avons réalisé un utilitaire de conversion de JCL MVS en Shell UNIX, dont voici les caractéristiques :

  • 3 phases indépendantes :
    JCL    XML
    XML    Shell
    XML    Documentation
  • Chaque phase peut tourner soit sur mainframe, soir sur UNIX, soit les deux,
    ce qui constitue un gain de temps important dans le projet
  • Paramétrage du Shell utilisé ( /bin/ksh, /bin/bash, ... )
  • En respectant quelques contraintes, 99% du Shell généré s'execute immédiatement sans correction des programmeurs
  • les données en format XML peuvent servir à générer des scripts dans d'autres langages sur d'autres plateformes (Rexx, Perl, Php, Windows ...)
  • On estime, suivant les CPUs et les charges des machines, la vitesse de migration suivante :

    1 JCL de 10 steps (300 lignes de JCL) génère 600 lignes de Shell en 2 secondes


Mainframe Migration Toolkit
ObjectifSolution
  Convertir du JCL en Shell UNIX ?
ACMU
  Convertir du JCL en .bat Windows ?
ACMU
  Trouver un SORT UNIX/Windows puissant et compatible IBM DF/SORT ?
XSM
  Traiter du Spool Offload JES2 sur UNIX/Windows ?
HSPO
  Exécuter des procédures VM/CMS REXX sous UNIX/Windows ?
EVMPR
  Dans vos programmes COBOL MVS, remplacer Datacom/DB par DB2 ?
DBENTRY
  Dans vos programmes COBOL MVS, remplacer DB2 MVS par une database UNIX ?
GDG



La Technicité

Une forte technicité est nécessaire à la fois sur Mainframe IBM et sur les système ouverts.

Vous avez peut-être besoin de conseil ou d'assistance sur un sujet spécifique, tel par exemple que :
  • Comment installer un précompilateur Cobol (Oracle Pro*Cobol / DB2 / PostGres / ...) pour MicroFocus ou Fujitsu sous UNIX/Linux ?
  • Comment convertir un dataset contenant des champs mixtes binaires/texte ?
  • Comment migrer un SPITAB sous UNIX/Linux ?
ou plus simplement :
  • Comment avoir un avis externe et objectif sur le bien fondé d'une offre de migration proposée par un prestataire ?
: Contactez-nous!