ABIS Infor - 2012-10

Migration d'un environnement mainframe

Gie Indesteege (ABIS) - 30 août 2012

Abstrait

Vous pouvez considérer plusieurs raisons pour lesquelles des personnes ou des compagnies déménagent. ABIS a décidé de changer de mainframe, entre autre pour des motifs économiques. Pour plus de clarté: il s'agit d'une migration de mainframe vers mainframe! Mais qu'est-ce qui est vraiment impliqué afin de transférer un environnement mainframe?

Qu'est-ce que c'est un environnement mainframe?

Admettons, le terme mainframe sonne drôle; on utilise de plus en plus le terme 'serveur d'entreprise'. Mais cette expression montre plus claire que la grande quantité de serveurs individuels - serveurs d'applications, serveurs de base de données, serveurs de courriel, serveurs de sécurité, serveurs web - sont consolidés maintenant sur ce seul serveur d'entreprise.

Cela veut dire que dans une discussion d'un environnement mainframe il s'agit non seulement du hardware, mais aussi du réseau et de l'infrastructure de communication, et surtout du software, système d'exploitation, sous-systèmes et applications. Assurez-vous de ne pas oublier les données (de l'entreprise).

Comment commençons-nous la migration?

Le processus de choix d'un (autre) mainframe, basé sur les exigences de notre environnement, n'est pas adressé dans cet article. Mais c'est l'évidence même que ce processus ne se risque pas à la légère.

Il est indispensable de constituer d'abord un bon inventaire du mainframe actuel:

  • quelle configuration hardware: combien de capacité CPU (MIPS), mémoire réelle (MB), canaux d'I/O et stockage sur disque est utilisé?
  • quelle version de z/OS?
  • quelles (versions de) sous-systèmes DB2, CICS, IMS, ... ? quelles configurations et personnalisations ont été appliquées?
  • quelles (versions de) outils et utilitaires comme par exemple QMF, SAS, facilités d'impression, RDz, ... avec leurs configurations?
  • comment ont-ils préparé l'environnement de développement de TSO/ISPF et RDz?
  • quelles applications ont-été construites en COBOL, PL/1, REXX, CLIST, ... ? comment se fait le traitement en batch (JCL et planification)?
  • quelles (montants de) données ont été collectées dans des bases de données, SDS et PDS, VSAM, HFS, ou autres systèmes de fichiers?
  • et que dire de l'intégration du mainframe et les applications distribuées à travers de DDF, FTP, imprimerie, courriel, 3270, ...? et, par conséquent, la conception du réseau (internet, intranet, extranet)?
  • et, last but not least, comment peut-on assurer la sécurité en RACF et au niveau du réseau?

Assez de matériel pour la moitié d'une encyclopédie, parce que oui, la documentation est importante.

Ensuite on regarde évidemment le nouvel environnement avec ses (nouvelles) possibilités et divergences:

  • quelles sont les possibilités de DB2 V10? ou de z/OS V1.11?
  • comment peut-on améliorer ou changer la conception de sécurité en RACF?
  • est-ce qu'il est possible de garder les standards auprès de la dénomination existante?
  • qu'est-ce qu'il faudrait changer dans l'implémentation de, par exemple, la procédure de logon?
  • quelles sont les restrictions, pour lesquelles il faut chercher une autre solution, comme par exemple les imprimés?
  • quelles personnalisations et configurations à faire, ou est-ce qu'on peut les récupérer de l'environnement existant?

Tout cela est bien dur, parce que le nouvel environnement reste actuellement inconnue.

Et puis on entre dans la phase de planification et de réalisation.

La méthode d'ABIS

Depuis le nouvel environnement du mainframe est déjà installé et dispose d'un z/OS active, ainsi de sous-systèmes configurés comme CICS et DB2, on peut se concentrer sur le transfert des données et des applications. Bien sûr, la préparation de la communication ainsi que la sécurité est une préoccupation majeure.

Transfert de données:

Pour le transfert des fichiers physiques MVS, on utilise ADRDSSU afin de créer des fichiers dump, regroupés logiquement. Ensuite, ces fichiers dump sont préparés avec TSO XMIT pour un transfert de fichiers. FTP est fait à travers un PC local, à cause de la sécurité (réseau). Sur l'autre mainframe, les fichiers reçus sont convertis par TSO RECEIVE, et finalement restaurés sur disque par ADRDSSU.

Et oui, on entre en conflit avec des problèmes divers comme la sécurité, la taille maximale des fichiers, des time-outs de réseau, ...

Pour le transfert des données (logiques) DB2 on profite des utilitaires DB2 UNLOAD/LOAD au lieu de ADRDSSU, mais le reste de la procédure est parallèle. Evidemment, if faut d'abord établir une configuration de base de données en DB2 avec des objets nécessaires dans le catalogue de DB2. A cet effet, on génère le DDL nécessaire à partir du catalogue d'origine en utilisant les outils de base de données dans Rational Developer for System z (RDz). L'exécution de ce DDL auprès de la nouvelle base de données produit un environnement (presque) parfait, à l'exception des indices, triggers et stored procedures.

De nouveau, on est confronté avec des aspects de sécurité, objets manquants, et ... différences de version DB2 et de la configuration, comme par exemple les groupes de stockage.

Applications:

Comme le business de ABIS est basé principalement sur un environnement central de DB2 pour z/OS, toutes les applications COBOL sont recompilées et reliées. Nous fournissons une bonne séparation entre environnement de test et de production. Et en plus, les applications distribuées, basées sur Java, C, PHP et Perl, et la communication par DRDA sont ajustées.

L'environnement des cours avec des exemples et des applications de démonstration sont mises à jour au besoin.

Réseau:

Changer de mainframe impliquait également, pour ABIS, la conception d'un nouvel environnement de réseau, cette fois ci en interne. La configuration d'un firewall et des routeurs, le changement du fournisseur de réseau, la conception d'un DMZ, la modification des définitions d'internet, la conception du gateway pour DRDA, ... nous l'avons fait, comme on dit 'suant sang et eau'. Mais cela est sujet à un autre article.

Sécurité:

Le transfert de définitions RACF est réalisé partiellement avec un extrait de la base de données RACF (userids et groupes, profiles de fichiers). Mais ensuite, il faut considérer l'ajustement et la fermeture des trous ouverts. Ce qui est un processus à vérifier constamment.

Personnalisation

Et ainsi en rencontre encore quelques petites anguilles sous roche, vers le nouvel environnement. Notre nouveau mainframe se trouve dans un autre fuseau horaire, parle une autre langue (codepage), a une conception WLM différente, se comporte différemment en ce qui concerne SMS, et il y a des différences de versions dans les sous-systèmes. Ca demande un effort supplémentaire pour être mis au point.

Donc les configurations doivent être examinées de près; comme par exemple:

  • DSNZPARM pour DB2 et un propre sour-système
  • CSD pour CICS, et un propre sour-système, avec une connexion vers WebSphere MQ et DB2
  • proclibs et procédures pour l'environnement batch/JCL
  • des paramètres de compilation pour COBOL et PL/1
  • TSO logon et personnalisation d'ISPF
  • planification des procédures de backup et de réplication
  • configuration de SAS et une connexion vers DB2
  • les applications distribuées: DRDA (DDF), RDz, FTP, imprimerie à distance, services web

Conclusion

L'aventure de changement d'un environnement mainframe familier vers une nouvel infrastructure encore inconnue a été un processus d'apprentissage très riche. Tout les aspects ont été adressés ici, en sont résolus en grande partie grâce à la connaissance multidisciplinaire des instructeurs d'ABIS. Bien entendu, le support des équipes de système mainframe, à la fois ancien et nouveau, a été indispensable.

Mais ABIS est toujours prêt à offrir son mainframe (et sa connaissance de mainframe) à tout ceux qui n'ont pas encore amorti le mainframe.

Si vous rencontrez une aventure semblable, ABIS veut bien partager ses expériences avec des conseils et des formations appropriées.