HH&S - Migration Mainframe vers Open

Migration

Les 4 points clés pour réussir un projet

L'expérience
La méthodologie
Les outils
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 DB2, 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.

Migrations et participations actives

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 LPAR z/OS
Fusion (merge) de LPAR z/OS

Portage et migration

programmes COBOL, PL/1, FORTRAN, Assembleur IBM 360, APL
procédures JCL, CLIST, REXX
fichiers VSAM
bases DB2, DATACOM-DB, IMS, DL1

Niveaux d'intervention

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
Étude de faisabilité avec Proof of Concepts
Aide aux spécifications techniques
Réalisation
Formations aux nouvelles technologies
Accompagnement à la mise en place de l'exploitation sur systèmes cibles

Consulter notre article sur la migration Linux vers z/Linux S/390.

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 nécessaires, et le coût de l'opération.

Méthodologie appliquée au batch — Méthodologie 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 œuvre, 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, à quantifier ces éléments, 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

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

À 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 (DB2 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 œuvre 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éférences 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.

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 cœur de métier "Programmeurs Système" et avons réalisé un utilitaire de conversion de JCL MVS en Shell UNIX.

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

Plus de détails sur notre utilitaire de conversion de JCL MVS en Shell UNIX. Vous pouvez aussi le tester en ligne.

Mainframe Migration Toolkit

Objectif	Solution
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èmes ouverts.