Outils NACA & Processeurs Zaap: transcoder son application Cobol vers Java en restant (plus économiquement) sur son mainframe IBM avec zOS!

UPDATE 01-2012: Le projet NACA a donné naissance à Eranea, société dédiée à la migration 100% automatisée de grandes applications métier vers Java et Linux. Voir  www.eranea.com ou email à contact@eranea.com pour plus d'informations
_______________________________________________________________________
Dans le projet NACA (abandon du mainframe pour Linux et transcodage 100% automatique de Cobol vers Java des 4 millions de lignes de notre application maison), pour atteindre les économies maximales nous permettant ensuite des investissements plus massifs sur nos projets stratégiques, nous avons pris une approche radicale pour libérer un maximum de moyens financiers:

• remplacer le système d'exploitation zOS par Linux (et Cobol par Java par transcodage automatique de notre application)
• ensuite, remplacer l'architecture zSeries du mainframe par de simples serveurs Intel très basiques quand des bancs de test nous ont prouvait que l'architecture Pentium finalement hyper-puissante grâce aux vertus de la loi de Moore.

Cette approche radicale nous a finalement apporté pleine satisfaction (réduction drastique des coûts, stabilité et performance du nouveau système, possibilité de disaster recovery interne, etc.)

Mais, dans nos multiples discussions avec diverses sociétés (sur 4 continents - Elles mènent leur propre projets sur base de nos outils) depuis la mise en Open Source des outils de NACA, nous avons développé une approche beaucoup douce et fluide pour les sociétés qui veulent avoir le beurre et l'argent du beurre en ménageant la chèvre et le chou:

• le "beurre logiciel": les outils de NACA sont utilisés pour transcoder l'application vers Java et ainsi bénéficier de tous les avantages d'un transcodage (voir les détails ici), i.e. (a) d'une mutation du code source de référence d'une application vers un environnement logiciel très sophistiqué mais en permanente amélioration, (b) de la profusion de packages logiciels ouverts et gratuits à intégrer à l'application transcodée pour la bonifier (c) d'une interface utilisateur native très moderne HTML+CSS+Javascript (=Ajax) sans avoir à retoucher les programmes anciens (d) de l'utilisation d'outils modernes (Eclipse à travers un plugin spécifique) permettant une augmentation de la productivité des programmeurs sans les perdre puisqu'ils retrouvent ligne-à-ligne leur programme Cobol initial
• le "beurre opérationnel": le monde Java est clairement plus vivant et dynamique que le monde Cobol. Par exemple, en basculant à Java, on peut faire progresser son application avec un effort très faible: nous avons observé une amélioration des performances de 30% (et c'est confirmé par Sun) en passant "simplement" (sans rien faire d'autre...) de Java 5 à Java 6. L'immense communauté de programmeurs Java chasse en permanence les bugs de la JVM pour en faire un environnement d'une stabilité redoutable et qui rivalise désormais en performances avec des langages aussi rustiques que C.
• l'argent du beurre en ménageant la chèvre et le chou: pour éviter à ses clients les décisions trop radicales que nous avons prises et les garder dans son giron, IBM commercialise désormais sur ses mainframes des processeurs spécialisés et dédiés au traitement de Java. Ils sont appelés Zaap pour "Zsystem Application Assist Processor". Sans aucune évolution majeure de la configuration globale du système et au cœurs même du mainframe en place, l'application transcodée peut fonctionner sur ces processeurs dédiés préservant ainsi un environnement établi et stable.

Ces processeurs Zaap ont un double avantage financier mis au point par le marketing IBM: ils sont facturés eux-mêmes à un prix très raisonnable et leur puissance ne vient pas s'additionner aux Mips des processeurs d'un mainframe. Ces Mips sont la base du système de location des logiciels zOS sur le mainframe: ils faut donc les minimiser! Les détails des processeurs Zaap sont donnés ci-dessous.

Il est donc possible d'utiliser nos outils de transcodage NACA 100% automatiques de Cobol vers Java tout en restant dans le "confort" de son mainframe: après le transcodage, l'application fonctionne dans Websphere "posé" dans une JVM propulsée par un Zaap sous le contrôle direct de zOS. Pour le cas du batch, c'est le même principe, mais sans Websphere: seulement la JVM sur le Zaap. Une telle architecture est parfois essentielle pour une société qui veut migrer son application transactionnelle de Cobol/3270 à Java/Navigateur Web sans faire le pas vers une sortie du mainframe.

Elle peut ainsi conserver toute l'intégration très étroite (qui représente parfois des décennies d'investissement!) de son activité transactionnelle avec les autres sous-systèmes de son mainframe (batches, infocentre, etc.) puisque qu'elle reste sur le mainframe mais tourne désormais sur le(s) processeur(s) Zaap(s) plutôt que sur les processeurs classiques du mainframe. Tout reste donc "dans la même boîte" alors que les utilisateurs bénéficient très vite des fonctionnalités de la nouvelle application plus modene.

Au passage, cette architecture peut même faire baisser la facture mainframe puisque les Mips du moniteur transactionnel (CICS) en Cobol sont libérés (voir slides IBM ci-dessous) au bénéfice du transfert de cette activité sur le Zaap en Java.

Le triple résultat:

• une application transactionnelle modernisée: 100% Java et Web
• une évolution douce, préparatoire de l'avenir et sans risque: le mainframe reste l'unique vecteur des activités dans un contexte déjà maîtrisé par les équipes opérationnelles
• des économies par le transfert de puissance utilisé: des processeurs classiques du mainframe pour CICS et Cobol vers les processeurs Zaap pour la JVM avec Websphere (ou Tomcat) et Java.

Ce qui précède est démonstration claire qu'il existe également des chemins graduels pour profiter massivement, économiquement et rapidement des avantages des nouvelles technologies (Java)en continuant à capitaliser sur les connaissances métier accumulées dans une application parfois de plusieurs décennies, à fonctionner dans un environnement parfaitement stable et maîtrisé donc sans demander de bonds quantiques vers l'avant aux équipes en place.

==== Les processeurs Zaap d'IBM

Source des graphiques de cet article : présentations IBM 2009 de Kathy Walsh

Ces processeurs Zaap sont une étape dans l'investissement continu réalisé par IBM pour maintenir sa plate-forme mainframe (hardware zSerie et système zOS) compétitive face entre autre à l'Open Source (Linux) malgré le désavantage financier intrinsèque à cette architecture sophistiquée donc coûteuse.

Pour ce faire, IBM introduit successivement des processeurs dédiés à certains types de tâches dans son architecture mainframe multi-processeurs:

Nous avons, chez Publicitas commencé le projet sur une base de processeur IFL (Integrated Facility for Linux) intégré à notre ultime mainframe pour faire tourner un autre système d'exploitation que zOS: Linux (distribution de Linux pour le mainframe). Des bancs de tests ultérieurs nous ont poussé à franchir le Rubicon et à en sortir définitivement

Depuis, IBM a encore poussé plus loin le concept de processeur dédié: il a en rendu l'intégration plus facile en le faisant tourner sous le contrôle de zOS plutôt qu'en nécéssitant un second système d'exploitation Linux. Le slide ci-dessous démontre la volonté technologique et marketing d'IBM autour de ce processeur (voir l'encart en jaune en bas):

Par une certaine forme "d'alchimie marketing", il s'agit de transférer les Mips Java vers un processeur dédié dont la nouveauté lui permet d'être moins cher et de ne pas affecter les coûts logiciels zOS existants (voir de les réduire, cf. plus haut) sans générer de questions autour d'un schéma tarifaire accepté par la communauté des grandes sociétés utilisatrices. Son avantage majeur est même de permettre une réduction des coûts du mainframe puisque que le Zaap peut permettre d'alléger les Mips "classiques", base de facturation des logiciels zOS.

Source: blog Media & Tech (par didier durand)