".../... 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 AIX, SUN Solaris, HP-UX), nous connaissons bien les enjeux et les difficultés d'un projet de migration Mainframe.

Seule une double compétence Mainframe/Unix peut conseiller, élaborer, 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/Java.

Avec, à notre actif, des migrations et des participations actives aux migrations dans les mondes suivants :
  • DOS/VS -> MVS/XA
  • VM/CMS -> MVS OS/390
  • VM/CMS -> Windows NT (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,
  • Inventaire du patrimoine applicatif et technique et Cross-References
  • 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 aux nouvelles technologies (cf. notre catalogue)
  • Accompagnement à la 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 et 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 expériences acquises sur les 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.

Methodologie appliquée au Batch

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.
Cet 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, et surtout, à identifier les points délicats. Pour cela nos outils produisent -- en un clic -- une Cross-Reference sur laquelle nous nous basons pour estimer avec précision la charge et les difficultés de migration.

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 (RFP). A l'issue du RFP, il peut alors déterminer son retour sur investissement (ROI) 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

Aujourd'hui, des outils permettent d'automatiser certaines tâches, de les fiabiliser, les accélérer, de réduire délais et coûts.
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 :
  • Cross-References
  • Paramétrage du Shell utilisé ( /bin/ksh, /bin/bash, ... )
  • Détection d'erreurs de JCL
  • Détection des éléments manquants (Fetch Member, Procedures, ...)
  • 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
  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.

Pour conclure :
  • Le succès d'une migration réside dans sa préparation. Après c'est trop tard, et la dérive de nombreux projets de migration l'illustre.
  • Ainsi, HH&S a toujours réalisé ses projets dans les délais, les budgets, et périmètre prévus.
: Contactez-nous!