• replace IBM operating system zOS by Linux and Cobol by Java (through our automatic transcoder now open-.sourced)
• replace the zSeries architecture of the mainframe by very simple Intel servers as soon as our benchmarks demonstrated that it was feasible at no risk for our level of activity (750′000 CICS transactions per day). Thanks to Moore’s Law, the Intel Pentium proved itself to be highly powerful to handle high transactional workloads.

This very radical approach made us eventually very satisfied: immense cost reductions, availability and performances of new system, rollout of an internal disaster recovery mirror system, etc.

But, since the open sourcing of our NACA transcoding tools, we had the opportunity to discuss with many companies evaluating our technologies or already running transcoding projects with them on 4 continents (only Africa missing as of now!…).

Those discussions led us to develop a smoother and more “fluid” approach for corporations wanting simultaneously to leverage their mainframe assets and their strengths and to rejuvenate their legacy application:

• Rejuvenate the application functionally: via the NACA tools, the Cobol application is automatically transcoded to Java source code and enjoys then following benefits: (a) as new “official” source code is Java, ability to leverage the very sophisticated environment of Java Virtual Machine still evolving very quickly (b) availability of many (open source) Java packages to integrate with the newly transcoded application to augment its capabilities (c) use of a state-of-the art user interface fully web-based (HTML-CSS-AJAX) as transcoded from the original 3270 BMS maps with no human intervention.(d) use of very modern development IDE (Eclipse through a specific plug-in) that strongly increases their productivity of legacy programmers as they continue seeing their initial and familiar Cobol code to maintain it.
• Rejuvenate the application technically: the Java world is still highly dynamic and improving on a recurring basis. When on JRE, an application can progress just by “being here” and not doing much: we saw a 30% improvement in performances just by upgrading from Java 5 JRE to Java 6 JRE. This is in line with official Sun benchmarks. The Java community improves the JVM day after day to make Java now a clear rival of very efficient languages like C/C++.
• Leverage mainframe assets and strengths: IBM wants its current clients to avoid such radical decisions as ours to keep them in the mainframe community. Consequently, IBM has launched some specialized processors dedicated to handling Java workload on the mainframe. They are called Zaap pour “zSystem Applicat ion Assist Processor”. By using them and without any major evolution of the mainframe configuration in place, the naca-transcoded application now runs on those dedicated processors and consequently preserves a very stable and deeply known zOS environment.

Those Zaap processors have a double financial advantage as created by the IBM marketing:

• they are themselves much cheaper than a regular mainframe processor (GCP)
• their mips don’t add themselves on top of the mips of the regular processors: they don’t as such have a negative influence on the monthly software bill of the mainframe for zOS essentially based on mainframe performance. As a matter of fact, they even tend to reduce this bill as the workload run on Zaaps means less mips needed in the regular processors. See details of Zaaps below

Consequently, it is possible to use our NACA transcoding tools to transcode 100% automatically to Java and to simultaneously stay in the “comfort” of the established mainframe environment after transcoding. The application will then run under Websphere (or even in the transactional monitor CICS or IMS but in Java) in a JVM powered by Zaap under direct control of zOS. For batch programs, same architecture but simpler: only the JVM is needed.

Such a mainframe-hosted Java architecture is needed by corporations who want to leverage all the benefits of a transcoded application to Java and web-based UI (see above) but who want to keep it on the mainframe. The company can this way maintain all the integration of the transactional activity with other mainframe subsystems (batch, archiving, printing, etc) sometimes developed over many decades.

Everything stays “in the same box” but the end users can benefit right away from additional functionnalities of their application brought to state-of-the-art.

As additional benefit, this architecture can reduce the mainframe total cost of ownership at double level: (1) the Mips of the transactional workload have now migrated from the costly regular processors to the cheap Zaaps (2) the “regular” (Cobol/CICS) mainframe workload has become smaller, replaced by functionally equivalent Java workload, and the monthly software bill can be reduced as less mips are consumed (see IBM below)

The resulting effects are triple:

• The legacy application has become state-of-the art, from both a user and a developer standpoint: 100% Java and Web
• A smooth and fluid evolution: a potential mainframe-less future is prepared at no risk as current machine, very well mastered by teams in place, remains the unique vector of activities.
• Savings generated by optimized configuration: all possible workload is transferred to the cheapest possible Java environment and the requirements of expensive GCP mips is highly reduced through maximum use of Zaaps wherever possible through the CICS workload migrated to Websphere or Tomcat.

This is the clear proof that gradual paths exist to massively leverage the financial and functional advantages of new technologies (Java) for legacy applications. The existing runtime system is not jeopardized: the operational competencies accumulated on the mainframe for decades can further be leveraged and at the same time the business competencies accumulated by in-house are also preserved as they continue maintaining familiar structures of source code. No leap jump is required when such is a the wish!

============== IBM Zaap processors

Source for schemes of this article: IBM presentations of Kathy Walsh.

Zaap processors are a significant step in the continuous investment by IBM to maintain the competitiveness of its mainframe zOS platform in the market, when facing fierce rivalry from Open Source (Linux) highly due to the intrinsic expensiveness of zSeries.

To achieve this goal, IBM consistently introduces new processors dedicated to some specific workloads. Those workloads transferred on cheaperinternal processors reduce the TCO of the global machine.

By Publicitas, we did start the NACA project on this path of dedicated processors: we initially started on an IFL processor (IFL = Integrated Facility for Linux) integrated in our ultimate mainframe in order to run another operating system than zOS: zLinux (linux distribution for the mainframe). We decided to move to linux on Intel servers only when internal benchmarks demonstrated that there was almost no risk and significant additional financial advantage to do so.

Since then, IBM has strengthened the concept of dedicated processors beyond the IFL original concept: the Zaap doesn’t require another operating (zLinux) to offload activities but runs directly under the control of zOS. The slide below demonstrates the technical and marketing goals of IBM in this technology ( the yellow rectangle at bottom is to be read in details):

Through a marketing “secret sauce”, it is all about migrating “central” mips to Java mips on a dedicated processor. The emergence of this new technology brings the opportunity of selling it on a different price scale and also the opportunity of eliminating it of the mips total used to bill the zOS software. So, the current software renting by the mips total remains unquestioned by the community of corporation running their core activities on mainframe. At the same time, the Zaap can be presented as the “white knight” reducing the total of mips hence the price.

As a result, the competitiveness of zOS is clearly improve din its current fight against the linux adoption for critical applications.

• 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 malgré, (b) de la profusion de packages logiciels ouverts et gratuits à intégrer à l’application bonifiée pour la transcoder (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épatoire 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. 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.

As Jazoon is a major Java conference in Europe, we could go into very specific technical details in front of the most competent audience.

Pierre described the architecture of our “transcoding compiler” and exposed all of its advantages. Read the ending slides of this ppt very carefully if you want to get all details (… or get in touch with us !):

• many levels of cache to maximize performances of the new Java version of the old application. Through them, our Java-transcoded transactions and batches have better performances than their Cobol ancestors used to have on mainframe.
• pre-allocation of all program variable structures (COMMAREA of COBOL) to further improve performances but also to minimize garbage collection that freezes the system while running.
• strongly object-oriented architecture of resulting Java objects in order to maximize the effect of all controls done by compiler. As example, each old COBOL program becomes a Java class whose existence is checked at compile-time rather than at runtime. Very useful when your application is 4 millions lines of code like ours and when you want to track down every typing mistake in a continuous integration architecture like ours
• strong integration with Eclipse IDE for highest productivity for developpers: we even developed a plug-in to facilitate debugging and edition of old COBOL programs from Eclipse
• line-by-line equivalence between old COBOL programs and newly transcoded Java classes. The home developers don’t get lost: they receive afterwards a Java application with the exact same structure as the original COBOL version
• support of IBM JVM as well as Sun JVM in order to also allow for the transcoding of stored procedures
• support of distinct character sets and encoding schemes (EBCDIC) between mainframe & Linux. Support of all resulting possibilities for data sorting.
• full management of multi-level COBOL data structures in Java independently of the UTF encoding (2 bytes per char) used by Java
• transparency of wrapping framework (raw JVM, Apache Tomcat, etc…) for the application
• etc…

We gave the URL of our open source (GPL licence) transcoding tools for participants. Please, give a chance to our tools if you enter such a migration project.

On my side, I emphasized the key aspects of such a project:

• economic motivation as core driver: move from a multi-million (CHF or euros) mainframe environment to an incredibly cheap and nimble farm of Linux Intel-based servers. The massive savings (3 millions euros / year in our case) allow for a quick auto-financing of the project far before its end. The main virtue of Open Source for a company like us remains clearly its very very low price.
• migrate people with technology: we believe that we succeeded in our project because we clearly demonstrated very early on to the people in place that they would find a new interesting job in the final constellation. That generated their full commitment to the project!
• iso-functionality as a must: migrating in such a manner prevents months of discussion about the final target. But, mostly, it allows for 100% automatic migration, a key factor for quality in the transcoding.
• no big-bang but numerous reversible steps: such a total migration with (tens of) thousands of new steps can never successfully reach the ends if you try big steps. Permanent incremental progress toward the goal is a much better approach. The nice consequences: small steps generate smaller local trouble when problems arise. Your users remain much more patient this way! Our experience was so…

Für den neuen Online-Auftritt auf www.gcp.ch konnten wir eine Publischerconnect Firmenwhitelabel Lösung (FirmenWL) einrichten. Die Verwaltung und Veröffentlichung der Offenen Stellenangebote erfolgen dabei durch Publisherconnect.

Die Verwaltung der Inserate durch den Kunden erfolgt dabei in MYP analog Dispositionen in herkömmliche Jobplattformen. In MYP wird pro Kunde und gewünschter, eigener Site ein eigenes Medium eingerichtet, welches mit der Publisherconnect-Instanz “Firmenwhitelabel” verbunden ist.

Der Kunde erhält dann von Publisherconnect einen RSSFeed, der es ihm erlaubt das Joblisting in seiner Site dynamisch einzubinden. Für die Details einer Position wird die Detailansicht von Publisherconnect angezeigt, womit der Kunde von den Publisherconnect Funktionalitäten profitiert (z.b. Tell-a-friend, Bewerbungsbutton etc). Hier der RSSFeed für Gfeller Consulting mit allen offenen Stellenangeboten.

Für Gfeller Consulting wurde pro Hauptkategorie ein RSSFeed erstellt. Die Kategorieauswahl konnte somit auch dynamisch implementiert werden (Kategorie wird nur angezeigt wenn Stellen vorhanden; Anzeige Anzahl Inserate). Die Integration wurde durch den Kunden resp. eine externe Agentur vorgenommen. Sie können diese hier anschauen http://195.162.152.163/infoglueDeliverLive_gcp/Home/KARRIEREANGEBOTE

Das Joblisting auf dem Publicitas Internetauftritt erfolgt ebenfalls mit FirmenWL: http://www.publicitas.ch/de/unternehmen/stellenboerse/

Inserate duplizieren
Dem Inserent steht neu bei jedem Inserat (aktiv/inaktiv) immer die Funktion “Neu Inserieren” zur Verfügung. Dabei wird der Inhalt des bestehenden Inserates komplett für eine neue Insertion übernommen. Bei Bedarf kann dieser natürlich entsprechend angepasst werden.

Buchen auf andere Plattformen
Neu wird es möglich sein, auf den Publisherconnect Marktplätzen auch Angebote mit externen Plattformen anzubieten. Der Content wird dabei durch den Publicitas Any2Any-Hub an die Plattformen ausgeliefert. Dazu wurde die Schnittstelle WLC2CMS entwickelt. über Ihren Marktplatz auch Angebote von Drittplattformen aufzunehmen.

Media-RSSFeed für PicLens
Für jedes Publisherconnect-Ad wird neu auch ein Media-RSSFeed generiert:
http://www.nzzdomizil.ch/nzzdomizil/feed/adDetailMediaFeed.htm?adId=NNNNNN.
Dies erlaubt es User die Bilder auch mit dem Browser-Plugin von www.piclens.com anzuschauen.

RSS-Feed mit Inseraten eines bestimmten Angebots
Neu wird die OfferId in den Fulltext-Index eines Inserates geschrieben. Dies erlaubt es RSSFeeds mit Inseraten eines bestimmten Angebotes zu machen.

Publicitas publishes under Open Source license (GPL/LGPL) the source code of the tools developped to execute the project called NACA now successfully completed. Its aim was to migrate a homegrown Cobol application (named PUB 2000 - 4 millions lines of Cobol) running on an IBM/zOS mainframe toward its 100% iso-functional Java equivalent running on Intel-propelled Linux-based servers.

For those in hurry to get the package, the complete zip file is here:NACA-Package 1.0 (Runtime, transcoder, Tests + docs) (4204)

This version is clearly v1.0, i.e a first delivery: it will get improved over time through the feedback and contributions returned by external testers running the tools on their own infrastructure. New versions of runtime libraries (JLib and NacaRT) can also be expected because they are still heavily used in our own environment on a daily basis for the transcoded version of Pub2000.

Why this choice of licenses? Because we want to avoid that professional service consultancies takes this code back to the proprietary zone for their own single benefit. For those players, GPL brings a set of constraints that maximizes the return of their improvements to the community by preventing them from locking the source code of their changes. For end-user companies, the freedom brought by GPL is totally appropriate.

From another perspective, the LGPL + GPL combination allows application software editors to migrate their applications through our tools (NacaTrans), link them to our runtime libraries (NacaRT and Jlib), distribute the source code of those libraries but not the source code of their own application so that they can remain competitive in the industrial sector of their application.

The tools that we deliver today (v1.0) in the zip package:

• Doc: a set of documents explaining in details the tools and libraries. Your feedback around this documentation, its missing points, etc. is essential in order to improve it.
• NacaTrans (license GPL - approx. 83′00 lines of code code & 690 Java classes): our transcoder that allowed us to convert 100% automatically the 4 millions lines of our PUB 2000 application in COBOL to Java. It is very much based on compiler technologies. It analyzes the structure of the initial COBOL programs (supposed 100% valid) to bring them in an intermediate xml structure before generating the final Java code that extensively calls functions and uses classes of the runtime library NacaRT, itself depending on JLib. This new Java source code was very carefully designed: each line of Cobol generates very intentionally a single corresponding line of Java. The aim is to look like as much as possible like the original COBOL code in order to ease the maintenance by the original developers / maintainers who master the structure of their original Java programs. The completeness of the accepted syntax for all variants of Cobol is of course not guaranteed. But our own 4 millions of lines of code as well as additional tests on other external application tend to prove that the current coverage of Cobol by NacaTrans is already very high. We want to improve this coverage through your feedback for valid constructs that we don’t support yet.
• · NacaRT & Jlib (license LGPL - approx 153′000 lines of code & 890 Java classes): those are the 2 runtime librairie who provide all the runtime transactional services for the application. They emulate all teh functions of a classical transactional monitor like CICS from IBM. At the same time, they also support all the COBOL constructs (for example, COMMARÈA structure with multiple data representation masks, management of specific data format like COMP-X, etc.)
• NacaRTTest (license GPL): this is a test suite allowing us to test the correct output of the transcoder on a set of reference COBOL constructs. It’s the way to validate part of our transcoding algorithms. For a new user of NACA, this is definitely the place to start: when this runs on oyur infrastructure, you can feel pretty confident about your installation of the package.

All those components are also delivered with Eclipse project description files in order to facilitate their setup in a standard Java environment.

Now, the answer to your last question already on your lips: why does Publicitas undertake this delivery?

• Because Publicitas has received quite a lot from the OSS community for our NACA project. We had to give back as much as we can: with this contribution, we want to return our highest possible contribution to the dynamics of Open Source.
• Because we believe that this set of tools heavily tested in our environment can be an excellent starting point for other similar projects by other companies also wishing to leverage Open Source software as we did (see our various articles on this topic)
• Because we still want to improve our tools and libraries as they remain used on a productive basis to handle our 750′000 transactions / day . We are interested in improving both the runtime libraries since Pub2000 runs on them but also the transcoder NacaRT itself . We still use NacaRT on a very regular basis for the transcoding of some programs that our developers decided (for valid reasons) to maintain from their COBOL source code. We even developed an Eclipse plugin to make this task simpler and more efficient.
• Finally, because Consultas, our internal IT entity, mostly aimed at serving other group entities, developed through this project a set of very specific competences that they would love to reuse in other similar contexts. Consultas’ engineers love this kind of challenges! If you plan your own NACA, they may want to be part of it.

Now, it’s you turn: take the package NACA-Package 1.0 (Runtime, transcoder, Tests + docs) (4204), install it, run it and let us know: we’d love your feedback in the comments of this post.

PS: for more specific contacts around your particular case, you can email us at naca-contact@publicitas.com

[Lien direct vers le package v1.0 source + docs à télécharger: NACA-Package 1.0 (Runtime, transcoder, Tests + docs) (4204)]

Publicitas publie sous licence Open Source (GPL/LGPL) le code source des outils développés dans le cadre du projet NACA (migration de son mainframe IBM/zOS sous Cobol vers des serveurs Intel/Linux sous Java) vers la communauté de l’Open Source. Cette publication a été récemment annoncée aux RMLL2008 de Mont-De-Marsan.

Pour ceux qui veulent commencer par télécharger les fichiers. Le fichier zip complet est ici: NACA-Package 1.0 (Runtime, transcoder, Tests + docs) (4204)

Cette version est clairement une première livraison (v1.0) : elle sera améliorée par les contributions (tierces) et documentée au fil du feedback donné par les testeurs externes qui feront fonctionner ces programmes Java sur leur propre infrastructure. De nouvelles versions sont également à prévoir autour des librairies JLib et NacaRT qui continuent par leur fonction même à être utilisées productivement par Publicitas et étendues au fil des évolutions de nos systèmes

La licence retenue est la licence GPL du GNU pour l’outil principal de transcodage et sa petite sœur LGPL pour les librairies associées.

Pourquoi ce choix ? Parce que nous souhaitons éviter le détournement de notre travail par des prestataires de services à but lucratif souhaitant utiliser ces programmes .pour leur seul bénéfice en le ramenant vers une zone propriétaire.

La GPL place, pour ces prestataires, sur les outils NACA un bon nombre de contraintes qui imposent le retour vers la communauté Open Source d’un maximum des améliorations faites par des tiers sur le transcodeur et ses librairies associées. Elle offre, par contre, une grande liberté aux sociétés utilisatrices finales.

La LGPL permet par ailleurs à des éditeurs de logiciels applicatifs de convertir leurs applications via nos outils (NacaTrans), de livrer nos bibliothèques runtime (NacaRT et JLib) en mode source mais de garder les bibliothèques de leur propre application en mode binaire afin de garder leur valeur compétitive dans le secteur industriel de leur application.

Les outils que nous publions aujourd’hui (v1.0) dans le fichier zip

• ·Doc: un ensemble de documents explicatifs autour de ces outils. Votre feedback sur leur contenu, leurs déficits nous permettra de les améliorer.
• NacaTrans (licence GPL - approx. 83′00 lignes de code code & 690 classes Java): notre transcodeur qui nous a permis de transcoder les 4 millions de ligne de Cobol de notre application PUB 2000. C’est en quelque sorte un compilateur qui analyse d’abord la structure des programmes Cobol initiaux (supposés 100% opérationnels) pour les amener dans une structure xml intermédiaire avant de générer un code Java faisant massivement appel aux classes et fonctions de la librairie de runtime NacaRT. Ce code Java généré a la particularité intentionnelle de ressembler au maximum au code source Cobol initial afin de favoriser la poursuite de la maintenance par les développeurs initiaux. L’exhaustivité de ce compilateur par rapport aux multiples standards du langage Cobol n’est clairement pas garantie: NacaTrans compile correctement nos 4 millions de ligne de COBOL. C’est la seule garantie. Cependant des tests complémentaires avec du code COBOL applicatif en provenance d’autres sociétés nous laisse croire que le taux de couverture du langage est excellent. Nous l’améliorerons encore avec le feedback de la communauté.
• NacaRT et Jlib (licence LGPL - approx 153′000 lignes de code & 890 classes Java): ce sont les bibliothèques de runtime qui réalisent toutes les fonctions de gestion / fonctionnement d’un système transactionnel classique. Elles émulent tous les verbes d’un moniteur transactionnel comme CICS (voir docs) et réalisent aussi entre autres l’émulation du langage Cobol (par exemple, structure COMMAREA à masques multiples, formats de données COMP-X spécifique à COBOL, etc…)
• · NacaRTTest (licence GPL): une suite de tests nous permettant de valider le fonctionnement correct de nos algorithmes de compilation. Pour toute personne qui installe la suite NACA dans son environnement, c’est la partie à faire fonctionner en priorité car elle tend à garantir une bonne installation de l’ensemble des composants

Tous ces composants sont livrés avec les fichiers de description de projet au format Eclipse afin de faciliter leur prise en main via des outils standards du monde Java.

Maintenant, la question que vous vous posez sûrement: pourquoi cette démarche?

• Parce que Publicitas, ayant beaucoup reçu de la communauté Open Source pour le projet NACA, souhaite rendre autant que possible. Avec cette publication, nous pensons livrer une contribution à forte valeur ajoutée et très pointue contribuant activement à notre tour à la dynamique Open Source
• Parce que nous pensons que nos outils éprouvés à l’aune de notre propre projet de migration puis à celle d’une année complète de fonctionnement opérationnel peuvent être une excellente base pour des projets similaires dans d’autres entreprises souhaitant elles-aussi bénéficier de tous les bénéfices de l’Open Source abondamment évoqués dans notre série d’articles sur le sujet.
• Parce que nous souhaitons encore améliorer nos outils qui restent encore abondamment utilisés chez nous: ils gèrent toujours nos 750′000 transactions quotidiennes. Bien sûr , nous souhaitons travailler encore les librairies runtime (Jlib + NacaRT) puisque la version Java de PUB 2000 s’appuie abondamment dessus mais aussi sur le transcodeur NacaRT puisque nos équipes de développement ont fait le choix pour des raisons spécifiques de continuer à maintenir une fraction minoritaire de nos programmes directement en Cobol et de les recompiler au vol en Java. Nous avons développé un plug-in Eclipse à cette intention
• Parce que Consultas, notre société informatique essentiellement interne, a développé une palette de compétences très spécifiques à cette occasion. Sans en faire son cœur d’activité mais pour malgré tout valoriser ce savoir-faire et surtout permettre à ses ingénieurs de se frotter à d’autres problématiques similaires pour s’aguerrir encore, Consultas prendrait volontiers quelques mandats de support / mise en place / extension de ces outils pour d’autres sociétés se lançant dans leur “propre NACA”.

Voilà, à vous de jouer: prenez le package complet NACA-Package 1.0 (Runtime, transcoder, Tests + docs) (4204) et mettez-le en place dans votre contexte. Faites-nous part de vos suggestions par vos commentaires sur ce billet.

PS: pour des contacts autour de projets particuliers, vous pouvez nous contacter aussi plus spécifiquement par email à cette adresse: naca-contact@publicitas.com

Cet article est le premier d’une série qui décrira le projet NACA ayant conduit au remplacement d’un mainframe IBM sous MVS/OS390 par des serveurs Intel sous Linux. Le projet a été lancé en Janvier 2003 et s’est terminé avec succès au 30 Juin 2007. Il a été réalisé volontairement de manière 100% iso-fonctionnelle (i.e. sans aucune modification pendant et par le transcodage) pour l’application et a permis la conversion automatisée de 4 millions de lignes de Cobol vers leur équivalent Java. L’économie en cash-outs - paiements externes - est de plus de 85% de leur montant annuel = initial d’environ 3 millions d’euros annuels

Tout d’abord le nom du projet:

• en français, NACA = “Nouvelle Architecture Centrale d’Applications”
• en anglais, NACA = “New Architecture for Core Applications”

Comme le titre de l’article et l’acronyme ci-dessus l’indiquent, ce projet lancé chez Publicitas a eu pour objectif initial la conversion d’un mainframe IBM modèle G5 exploité via les logiciels standards habituels (MVS/OS390, CICS, COBOL, DB2) vers son équivalent naturel dans le monde du Logiciel Libre (Open Source):Linux, Java, Tomcat, UDB. Il s’agissait d’amener l’application commerciale maison, appelée PUB 2000 et développée à la fin des années 80, vers un environnement technologique moderne et efficace.

Nous avons lancé ce projet à mi-2002 sur le constat que l’Open Source “montait en puissance” et était utilisé sur des applications autrement plus critiques que la nôtre: de multiples exemples émergeaient déjà dans le monde des industries classiques: énergie, aéronautique, aérospatial, finance avec des noms prestigieux comme Boeing, Sony, Nasa. Toutes ces applications industrielles trouvées au travers de notre veille technologique avaient des niveaux de charge et de volume bien supérieurs aux nôtres. Notre activité est d’environ 750′000 transactions par jour effectuée par une population de 1′500 utilisateurs environ.

Par ailleurs, dans un domaine moins habituel pour Publicitas, des startups (de l’époque….) comme Google nous montrait qu’elles arrivaient à délivrer sur Linux un service de qualité impeccable à des très hauts volumes de charge. Certes, à l’époque pas encore avec 1 million de serveurs pour délivrer 120 milliards de pages chaque mois mais quand même avec déjà des niveaux de charge bien supérieurs aux nôtres. Côté fiabilité, la solidité prouvée de l’Open Source est bien décrite par la célèbre Loi de Linus (Torwald, père de Linux) énoncée par Eric Raymond dans son essai “La cathédrale et le bazar” (à lire ou relire, impérativement!). Cette loi dit donc ““Étant donnés suffisamment d’observateurs, tous les bogues sautent aux yeux” Les feux étaient donc au vert et nous sommes lancés, conscients que de nombreux écueils se trouvaient encore devant nous car une telle migration Mainframe MVS était pour le moins pionnière (voire inconsciente ou hérétique au gré des interlocuteurs…)

Mais, nous sommes partis dans l’exploration des possibilités technologiques pour NACA car la première motivation du projet était massive: le mainframe IBM nous coûtait en “cashouts” (sommes payées aux fournisseurs IBM et tiers) environ 3 millions d’euros par an. 80%+ de cette somme, soit pas loin de 2.5 millions d’euros partaient dans les licences de location des logiciels utilisés comme “carburant de la grosse boîte”.

Le calcul financier initial était donc simple (même simpliste pour certains…) : le Logiciel Libre est gratuit. La plate-forme mainframe IBM supporte le Logiciel Libre et le remplacement intégral des logiciels propriétaires d’IBM et des tierces parties par leurs équivalents Open Source permet donc réduire les coûts annuels de 2.5 millions par euros. Si on calcule abruptement…

[Note: IBM annonçait à l'époque - preuve avec le code source à l'appui - que moins de 1% du noyau de Linux était modifié pour supporter sa plate-forme hardware mainframe de la série G.On parle donc véritablement du même logiciel Open Source que pour des serveurs Intel]

Ces économies très consistantes représentaient une motivation suffisante aux yeux des gestionnaires des finances de PubliGroupe pour lancer le projet puis le soutenir dans les moments difficiles qui ne manqueraient pas de survenir (on en reparlera dans les prochains épisodes…)

Nous sommes partis avec les objectifs et lignes directrices:

• migration douce: le “big bang” de la migration globale de l’ancien au nouveau système en une nuit a été banni d’entrée. Les uns et les autres de l’équipe connaissaient tous des projets internes ou externes ayant échoué par la volonté de passer “la grande marche” en 1 seule étape. Nous avons donc décidé de construire comme chemin de projet plutôt un long escalier doté de multiples petites marches permettant de progresser irrévocablement (mais avec retour arrière possible à chaque fois)
• transcodage iso-fonctionnel et automatique: il s’agit d’éviter le mélange des genres qui conduit le plus souvent à l’émergence de nouvelles contraintes souvent fatales. Donc, nous avons décidé de migrer les fonctions écrites en Cobol 1 pour 1 vers Java. A la sortie, le code Java fait juste la même chose que le code Cobol. Il le fait et juste pour beaucoup moins cher….
• préservation des équipes en place: les collaborateurs fidèles à l’entreprise et au système depuis 20+ ans sont les plus aptes à le faire migrer. Pour autant que l’on injecte juste le sang neuf nécessaire à l’infusion des nouvelles compétences Linux et Open Source.

Le principe de la migration douce est de construire le nouveau système non pas en parallèle (i.e séparée) du système historique mais plutôt de bâtir progressivement le nouveau système en remplaçant des parties de l’ancien et en interconnectant les nouveaux composants avec l’ancien système pour délivrer une qualité de service au moins identique (voire meilleure) en permanence aux utilisateurs sans créer de césure entre ancien système et nouveaux composants. La conséquence directe de cette stratégie est que l’on commence la migration du système par les couches basses puis que l’on remonte “la pile des niveaux logiciels” pour terminer par l’application maison.

Avantage de cette progression”bottom-up”: les administrateurs du système gérant habituellement ces couches basses sont les premiers à quitter l’ancien monde vers le nouveau. Ils ont donc la possibilité de dominer les technologies (nouvelles pour eux) du monde Linux et de s’y sentir très à l’aise quelques mois plus tard quand c’est le moment pour les développeurs applicatifs d’y entrer.

Par ailleurs, le transcodage iso-fonctionnel et automatique est essentiel pour la fluidité du projet. En effet, en utilisant un outil (que nous avons fini par développer “maison” - j’y reviendrai dans un autre article) de transcodage 100% automatique, on peut continuer la maintenance applicative fonctionnelle dans l’ancienne version et faire passer “fluidement” les nouveautés dans le nouveau monde par simple transcodage.

On n’impose ainsi aucune date à la mise en service de la nouvelle version Open Source de l’application qui serait par exemple due à un respect d’une nouvelle réglementation. Dans une telle situation, un conflit entre une nouvelle technologie applicative qui ne fonctionnerait pas comme prévu et une obligation règlementaire impérative pourrait avoir des conséquences dramatiques pour le projet.

Avec le stratégie retenue pour NACA, au contraire, les développeurs font leur maintenance sur l’ancien code COBOL jusqu’au jour où la nouvelle application Java est certifiée comme valide pour la production après plusieurs semaines d’utilisation opérationnelle satisfaisante. A ce moment seulement, le Java transcodé devient le nouveau code source. Avant, il n’était qu’un langage intermédiaire de compilation. [On y reviendra dans tous les détails ultérieurement]

Enfin, nous avons décidé de préserver les équipes en place au maximum en les formant au maximum sur les technologies Open Source. Le deal est très simple:

• une telle migration ne peut se réaliser sans la participation la plus entière des équipes en place. Il y a des dizaines de milliers de détails à connaître et à traiter de manière anticipée pour éviter au maximum tous les écueils (fatals) pouvant tuer le projet. Lancer les “jeunes loups de l’Open Source” contre les “vieux crocodiles du mainframe” serait la pire des erreurs de conduite d’un tel projet
• la plupart des membres des équipes (système et développement) en place souhaitent faire évoluer dans leur expertise quand il voit que le monde change autour d’eux. Ils suivent aussi l’émergence de l’Open Source depuis leur cockpit du mainframe et donc sont prêts à se convertir avec peu de résistance - quand les objectifs précédemment évoqués leur sont expliqués clairement - pour poursuivre leur carrière en tant qu’experts du monde Linux dès qu’on leur offre le service de formation nécessaire. Les experts technologiques pointus aiment le rester et savent faire ce qu’il faut en termes de “bits and bytes” pour adapter leurs connaissances généralesd’architecture informatique à une “nouvelle quincaillerie” qui fonctionnent le plus souvent sur les mêmes grands principes que la précédente génération (juste une syntaxe de commande un peu différente…)

Pour terminer ce premier épisode, j’attirerai l’attention sur le fait qu’une telle migration de l’application maison d’un contexte propriétaire fermé à un contexte Open Source ouvert apporte aussi un avantage intangible (i.e. pas quantifiable en euros) lorsque l’on démarre: celui de replacer l’application sur une plate-forme à partir de laquelle les mécanismes d’interaction avec le reste du monde (i.e. autres applications de la société) deviennent 10 / 100 /1′000 fois plus simples.

On peut donc intégrer cette application d’une manière beaucoup plus efficace et rapide: des processus “historiques” semi-automatisés et peu rapides de transfert de données d’un système à l’autre (les célèbres “moulinettes” d’import-export inter-systèmes) peuvent être remplacées par des communications directes en temps réel (type RPC - Remote Procedure Call) entre les blocs du système informatique global (par exemple entre l’application commercial et le système CRM)

En conclusion, le catalyseur initial d’un tel projet est sûrement le montant consistant des économies réalisées mais le vrai bénéfice à long terme est de replacer le système de l’entreprise dans un contexte technologique moderne qui lui permet d’améliorer son business parfois de manières imprévues au début du projet mais très significatives. Et tout cela, pendant toute la durée du projet (4.5 ans pour nous) sans jamais perturber l’évolution de l’application via la magie du transcodage automatique….

Exemples de tout ceci dans les futurs billets. Donc, à suivre!

This article is the first of a series that will describe the NACA project run by Publicitas, advertising sales company based in Switzerland and executed by Consultas, IT subsidiary of the group.

It was about replacing an IBM mainframe under MVS/OS390 (zOS) with Intel servers on Linux. The project started in January 2003 and successfully ended on june 30, 2007. It was on purpose implemented in a 100% iso-functional way, i.e. without any functional / applicational improvement brought during the process of trans-coding itself and by the transcoding engine. 4 millions lines of COBOL were 100% automatically trans-coded toward their Java equivalent.

The savings in cash-outs amounted to a total of 3 millions euros, 85% of the initial yearly level.

First of all, meaning of the project name:

• in French, NACA = “Nouvelle Architecture Centrale d’Applications”
• in English, NACA = “New Architecture for Core Applications”

As the title of the article and the project acronym imply, NACA was launched within Publicitas (Lausanne, Switzerland) to initially convert an IBM mainframe model G5 operated through the standard palette of “big iron” software (MVS/OS390/zOS, CICS, COBOL, DB2) toward its canonical equivalent in the Open Source world: Linux, Java, Tomcat, UDB.

The aim was to transfer the homegrown administrative application (called PUB 2000 - developed at the end of the eighties) to state-of-the-art technologies, i.e modern and efficient.

The first thoughts around the project emerged in July 2002 when we realized that Open Source software was gaining ground and was already heavily utilized for applications much more critical than ours. Multiple case studies were published about core applications in key industries: energy, aeronautics, space, finance, with famous names like Boeing, Sony, Nasa. Most of those industrial applications were run at much higher load with more severe performance / availability constraints than ours. Our own activity is around 750′000 transactions done by approx. 1′500 internal users.

From another perspective, the highly successful startups of that time like Google were demonstrating that Linux can be the cornerstone of a very large scale infrastructure delivering a complex service over the Internet, By that time, it wasn’t yet through 1 million servers delivering 120 billions pages per month but the load level of Google was already far higher than ours. About reliability, the proven resilience / reliability of Open Source is best described by Linus’ law (Linus = Linus Torwald, father of Linux) made famous in the essay of Eric Raymond named “The Cathedral and the Bazaar“: “given enough eyeballs, all bugs are shallow”.

All lights were green. So, we decided to launch the project knowing that many hurdles and unknowns were still in front of us: such a full migration from a mainframe under zOS was (minimally) to be considered as pioneer work. Some even said by that time that it was crazy or heretic…

But, we started to explore the technological possibilities for NACA because the first motivation was massive and critically important: the mainframe had a yearly cost of 3 millions euros paid to IBM and third parties and 2.5 millions euros, i.e. 80%+, were used operating the hardware.

The initial business case was simple (some even said simplistic…) : Open Source software is more or less free. IBM mainframe hardware can run Open Source. So replacing each component of the mainframe palette by its OSS counterpart would save us millions of euros. The only point being that you have to accept this brutal computation…

[Note: IBM was by then publishing figures saying that less than 1% of linux kernel had been modified to run on the mainframe hardware of series G.

So, mainframe Linux is clearly the same as the one running of Intel servers]

Those massive savings were attractive enough for the management and financial staff of Publicitas to authorize the project and support it further during the various troubled periods that always happen during the course of such a risky project. Those troubled times will be the core topic of a subsequent article.

We started NACA with following objectives et guidelines:

• progressive migration: the one-shot “big bang” of a global migration from the old system toward the new one, implemented over a single week-end was banned from day 1 and for ever. All team members knew internal or external “big bang” projects that failed after a couple of unsuccessful “big step” trials. So, we decided to build our project path rather than as a very long stairway with as steps as possible, those steps being as small as possible. The idea was to achieve many incremental and irrevocable (but always reversible) successes.
• 100% automatic and strictly iso-functional trans-coding: we did not want to mix genders between technology update and application improvement. This confusion inevitably leads to additional constraints becoming lethal most of time. So, we decided to migrate each COBOL function to its strictest equivalent in Java. So, at the end of the project, just the same application but delivering the same value for a drastically reduced cost. In addition, the automatic (i.e. costless) trans-coding means that the Cobol maintenance doesn’t have to be interrupted: the next run of the transcoder transfers the newly implemented Cobol code to its Java equivalent. So, the end users remain happy while the system engineers achieve their technological marathon over the many years of such a project.
• continuation with teams in place: the employees loyal to the company and its IT system over 20 years are the best experts to execute a smooth migration. Knowing that system engineer spend their career learning new technologies, shifting to Linux is just another milestone on this road. We just added a couple of linux- and OSS-oriented “rookies” to accelerate the technology adoption.

The tactics of this progressive migration is clearly NOT to build the new system in parallel to (i.e separated from) the old one. It is rather about replacing one by one components of the legacy system with OSS technological equivalent in the live production environment. The target is to preserve the quality of service of the old world in the new system under permanent mutation. Thus, the end-users never perceive the launch of a new system but rather sense the permanent evolution of functions that have always been there. This evolution also brings improvements at no big cost: for us, THE example is the generation as pdf files of our administrative documents (orders, vouchers, etc.): in the mainframe world, it was always too expensive to be done but under Linux it came for free in course of migrating the print management system.

The consequent logical order is to start from the lower system layers of the system stack and then go up toward the application layer: the transcoded Pub2000 could not be launched before the ground layers were there!

The advantage of this bottom-up progression is clear: the existing systems engineers are the first employees to get involved. As such, they become clearly the owners of the new system and master all the Linux and other OSS technologies before anybody else. They feel then highly comfortable and have no fear of being displaced when the developers enter the game a few months later.

From another perspective, the iso-functional transcoding to Java is essential: by using such a cross-compiling tool (that we ended up developing by ourselves in order to achieve the 100% automation that we targeted initially - I’ll come back on that in a subsequent article), the functional maintenance of application is never interrupted. All changes made to Cobol are smoothly, instantly and at no cost transferred to the Java version in the next run of the transcoder (almost done on an hourly basis)

.This relieves a very important constraint on the new Java / OSS version of the application: no firm release date is really needed from a functional standpoint. If, let say, a new legal function was implemented only in the new Java version after hand-tweaking of the half-baked java code, a delay on the productive release of the Java version could be dramatic for the entire project.

On the contrary, with the strategy that we chose for NACA, our developers did their functional maintenance on the cobol version (as they always did) until the new java version was satisfactorily used by 100% of our end users (progressively migrated groups by groups) for several weeks in the production environment. At this time only, the transcoded Java version of the application became the official new source code of PUB 2000. If any problem had occurred in this process and in the worst case, we could have brought 100% of the users back on the mainframe in matter of minutes.

It never occurred, by the way.

But this careful and parallel progressive allowed us to make quietly some (unexpected) stops in user migration at points were some performance thresholds were reached in our Java architecture: our java / database experts would then adapt the system architecture or transcoding + runtime strategies to overcome the hurdle and we could proceed further with more migrated users. [All details in a subsequent article].

Last but not least, we wanted keep the very loyal teams in place even though the entire system was eventually changed. We offered all of them a very intensive OSS training package. The motivations were those:

• Such a migration can’t succeed without full support of the team mastering the legacy system. Ten of thousands of tiny details (Remember: the devil is in them!) have to be handled for the project to succeed. So, hoping to generate competition by trying to oppose the young wolves of OSS to the old crocodiles of legacy mainframe would be a clear fatal mistake.
• Most system engineers are used to change the horse that they ride (i.e the operating system that they master) many times over their career. At the end of the day, this is just another occurrence of such a switch! When they see that the world around them is deeply changing around them through a massive migration toward OSS, they welcome (with minimal resistance to change) any opportunity that allow them and their competences to also switch through a good training. Fundamentally, they are more experts in system architecture than in any specific operating system. It means that they just have to learn a new set of “bits and bytes” habits to transfer their expertise to the world of Linux and OSS. The core fundamentals of most operating systems remains essentially the same whatever the name of the OS is! It is just another command syntax and parameter definition format to learn…

To close this first episode, I would like to add that such a migration from proprietary world also brings intangibles advantages that are eventually almost as important (more important than ?) as the very sexy financial fact-based ROI that you can demonstrate for such a project.

Those intangibles advantages can be presented in one sentence: “we are back in the market”. And even if you can’t equate this to euros, it has a clear value:

• you can hire new engineers in a much simpler way: mainframe system engineers tend to become rare and then expensive!
• you can interconnect the new version of the application in a so much easier way with other internal systems (CRM, SAP, etc..) as well as with external sites over the Internet (E-commerce, E-business). Those interconnections suddenly become 10 / 100 / (1000 ?) times more easier when you can rely on the full J2EE environment as well as on tons of open source java library.

You can then integration your home grown application in a much more flexible and efficient way to newer components of the IT systems: the old file exchanges, data conversion and import / export processes can disappear to be replaced by synchronous real-time data exchanges over any kind of remote procedure call. This clearly brings value to the business through processes that are accelerated.

As a conclusion, the only valid initial catalyst of such project are savings. They are so massive that they get the attention of any CIO. But, when those savings are achieved, another benefit probably even more important emerges: the company can now significantly improve its business through IT in ways that were only unachievable dreams before the migration. Some were not even anticipated!

And to close the loop, those improvements can even be financed through the savings just achieved via the migration…

Stay tuned for more details on specific topics in upcoming articles!