J'ai vu le serpent de mer: il est reparti mais il reviendra !

[JPL]

 Bonjour . .
 
J'ai vu le serpent de mer: il est reparti mais il reviendra.
 
Nous avons examiné de plus prêt l’avancée d’IBM vers les interfaces graphiques natives  attendues par les clients de la plateforme i depuis plus de 10 ans. L’offre est aujourd’hui connue sous le nom d’ « RPG Open Access » ou encore RPG OA. Selon nous, sur le plan commercial, l’offre est politique. Sur le plan technique, l’offre est potentiellement très prometteuse mais inachevée. Nous pensons qu’ IBM va très certainement faire évoluer RPG OA dans un futur proche.
 
Nous disposons de tout le détail technique d’Open Access RPG depuis une semaine environ. L’offre est prometteuse sur le papier car elle est ouverte. En effet, depuis l’ OS/38 et l’ OS/400, nous savons tous que les langages informatiques comme le RPG ou le COBOL ne font qu’appeler une série d’API, qui sont des programmes C++ paramétrés et assurent une indépendance matériel/logiciel.

 

Partant de ce constat, IBM a ouvert les instructions I/O des fichiers PF, LF, DSPF et PRTF aux développeurs. Il est techniquement possible  avec RPG OA de remplacer les API d’une instruction WRITE d’un PF par une écriture exogène, par exemple une ligne d’un fichier Excel. Il suffit de remplacer les API de l’instruction WRITE par un autre programme qui va écrire une ligne Excel. Bien entendu, il faut indiquer au code source RPG que ce fichier fait l’objet d’un traitement spécial. Techniquement, le mot clé HANDLER sera ajouté en carte F avec le programme spécial associé qui gère l’écriture dans un fichier Excel. L’avantage pour le développeur RPG est qu’il n’a pas besoin d’apprendre la syntaxe d'un enregistrement Excel : une fois le programme testé avec un PF standard, le développeur ajoutera en surcharge le mot clé HANDLER avec le programme associé qui va bien pour obtenir une écriture dans un fichier Excel.

En se basant sur ce principe, le développeur RPG sera compétent pour un nombre infini de terminaux et de fichiers divers et variés sans rien connaître de ces technologies, simplement en ajoutant le bon Handler en carte F après avoir testé son programme RPG avec un fichier classique natif PF, PRTF ou DSPF.

 


Vous l’aurez compris, des sociétés pointues sont chargées de commercialiser des Handler très spécialisés. Cependant certains d’entre eux pourraient être disponibles en Open source via internet. Par exemple, des Handler Excel ou des Handler XML pourraient très bien être proposés en Open source par des développeurs de haut niveau comme Scott Klement, Jon Paris ou Aaron Barthel. Plus besoin pour le développeur RPG lambda d’appeler des procédures complexes puisqu’elles seront masquées sous les I/O natifs. On pourra tout faire avec le RPG qui deviendra du jour au lendemain LE langage phare de gestion du 21ième siècle, simplement en remplaçant dynamiquement les API des I/O avec les programmes appropriés à l’aide d’une petite surcharge anodine en carte F appelée Handler, sans oublier de recompiler le programme après bien entendu… l’avenir s’annoncerait brillant pour nous autres développeurs RPG mais… car tout de même il subsiste un énorme mais…

 

Munis de la description technique complète du Handler fournie par Barbara Morris que vous trouverez en fin de lettre, nous avons recherché une possibilité d’utiliser la technologie RPG OA pour nos deux offres 5250 et Full Web RPG. Dans la brochure technique, nous avons bien trouvé la description du Handler mais rien à propos de son implémentation. Pour bien se rendre compte de l’étendue du problème, il convient de revenir sur la différence entre une webisation du flot 5250 et une interface Web vue sous l’angle du Handler.

Avec la webisation, le flot 5250 est traité en bout de course. Il est interprété, parfois sur le poste client et traduit à la volée en HTML. C’est en quelque sorte un rapide maquillage marketing de dernière minute connu sous le nom de « modernisation » juste avant de présenter les écrans aux utilisateurs supposés ébahis.

 


Avec la technologie Handler, les I/O sont traités dès la sortie du programme RPG contrairement au flot 5250 qui est traité au moment de l’affichage. L’idée est donc excellente en elle-même car les interfaces deviennent natives, mais dans le cas du Web, il faut un contrôleur Web pour gérer la persistance, les sessions, le travail de l’utilisateur. En fait, il faut l’équivalent pour le Web de ce qui existait en 5250. Or cette partie de l’operating system pour le web n’est pas fournie par IBM ! Surprise: IBM ne fournit pas l’implémentation !!!

 

Deux éditeurs qui ont eu la chance de travailler avec IBM sur le projet RPG OA  commercialisent des accès natifs Web pour les programmes persistants 5250. Ce sont respectivement les sociétés Look Software et Profound Logic Software. J’ai pu assister à une démonstration en ligne de la société Profound Logic Software. Je me suis demandé comment ils avaient fait pour traiter le problème de la persistance et des sessions multi-utilisateurs. Selon Jon Paris, il semblerait qu’il existe deux solutions,  soit un programme de dispatching  qui soumet un programme pour chacune des sessions utilisateur et c’est depuis ces programmes soumis que le Handler interviendrait ; soit un système mixte avec une webisation de certains écrans standards et le Handler pour les écrans de certains applicatifs. En fait, rien n’est très clair à ce niveau car chacun est libre de bricoler son propre operating system dans son coin comme il l’entend.

 

Combien de temps cela prend-il d’écrire un operating system afin de gérer les multi-sessions persistantes à partir du handler ? Nous avons un début de réponse avec la société VAI éditeur d’ ERP, qui avait fait partie avec Profound Logic et Look Software des sociétés qui avaient été retenues dès l’origine pour travailler avec IBM sur le projet RPG OA. La société VAI souhaite remplacer la solution de webisation Seagul Software par un Handler maison. Nous pouvons supposer que la société VAI a travaillé sur le sujet depuis des mois. Selon Kevin Beasley, CIO VAI, la compagnie devrait avoir une solution prête fin 2010 ou début 2011. Nous avons donc la réponse : il faut environ un an de travail minimum pour fabriquer un operating system pour des interfaces Web natives pour les programmes RPG persistants en partant du Handler. Pour une société comme VAI cela vaut l’investissement, car ils étaient partis  sur une solution Java pour remplacer le RPG il y a quelques années. A priori, il semblerait qu’ils sont en train de revoir leur copie, d’autant que l’IBMi et Unix partagent la même machine Power : lorsqu’une solution ERP clés en main est proposée, le client final ne s’occupe pas du langage ou du système d’exploitation mais des fonctionnalités, de la fiabilité et des interfaces.

 

Parmi les autres éditeurs de logiciels, Lansa et BCD disent avoir été contactés par IBM et avoir décliné l’offre de participer au projet Handler. En effet, Lansa et BCD pensent que la technologie Handler est appropriée pour les programmes stateless, sans état persistant du Web, mais ne fonctionne pas à elle seule pour les programmes persistants stateful où c’est le programme qui dirige les transactions. Dans une lettre IT Jungle Lansa et BCD ont rédigé un communiqué commun. Ainsi Ducan Kenzie, le CIO de BCD dit ceci : "So when you have an execute format, you are waiting for a response from the user,"  autrement dit: “quand vous avez une instruction RPG EXFMT, vous attendez une réponse de l’utilisateur.Et plus loin : Web applications--whether they are Web services, browser apps, or mobile apps--are not stateful. They are written differently. So the notion that you can plug a single command and have everything work differently is ridiculous. Handlers can't do anything about whether the conversation is stateful or not. You have to rewrite all your code to make it stateless” Ce qui peut se traduire ainsi en simplifiant:  “Les applications Web ne sont pas stateful. Aussi l’idée que vous pourriez brancher une simple commande et faire que tout fonctionne autrement est ridicule.  Le Handler ne peut pas faire qu’une transaction devienne stateful ou non. Vous devez réécrire tout votre code pour le transformer en programme stateless ».

 

A priori il semblerait que des sociétés comme Lansa ou comme BCD aient refusé de cuisiner un operating system pour gérer la persistance étant donné l’énormité de la tâche qui aurait normalement due, selon eux, incomber à IBM. Les grands gagnants dans ce combat entre éditeurs  de « modernisation » semblent bien être Profound Logic et Look Software.

 

En effet, le produit RPG OA qui fait fonctionner le Handler est disponible à partir de la version V6.1 et est commercialisé séparément en fonction de la machine par IBM. Il faut donc des plateformes en V6.1 et déjà dotées du produit RPG OA avant de tester la version Profound Logic ou Look Software. Mais Profound Logic, selon un blog, aurait un pré-compilateur spécial qui ferait marcher son produit Web 2.0 à partir de la version V5R3… Donc il est certain que ces deux éditeurs ont au minimum réussi un coup marketing énorme car ils sont les seuls à avoir des interfaces web qu’ils peuvent qualifier de natives car fonctionnant avec les fameux Handler. A dire vrai, ces deux sociétés avaient déjà une excellente solution Web2.0 sans Handler qu’ils peuvent toujours commercialiser. A eux deux ils vont donc rafler quantité de nouveaux clients au détriment des concurrents. Nous comprenons mieux pourquoi les sociétés Lansa et BCD doivent écumer de rage. Martin Fichman CIO de Lansa tient des propos outranciers à l’encontre de ce pauvre serpent de mer  qui ne le mérite pas: « …it's not a good thing or a bad thing. It's a nothing. » Ce qui pourrait se traduire par : « …ce n’est pas une bonne chose ou une mauvaise chose. C’est un rien du tout. » et plus loin : « Open Access has been billed as a panacea…That can be real dangerous when people don't understand what Open Access can or can't do for them."  Traduction: “RPG OA a été présenté comme la panacée… cela peut être réellement dangereux dans la mesure ou les gens ne comprennent pas ce que RPG OA peut faire ou ne pas faire pour eux.”

Ainsi le Handler devrait fonctionner en l’état pour l’informatique Web stateless qui n’a pas besoin d’un contrôleur dédié par définition même. Nous avons depuis cette année une solution RPG qui utilise les procédures CGIDEV2 et qui permet la génération de programmes RPG Full Web. Nous avons donc étudié la possibilité d’utiliser les Handler dans le cadre du RPG CGIDEV2. Selon nous, la technologie Handler permettrait d’enfouir beaucoup de code système traité actuellement par l’appel de programmes de services dans le programme RPG. Pour donner un seul exemple, le langage de présentation HTML ne connait pas  autre chose que les données alphanumériques et les constantes. Il deviendrait possible avec un Handler de camoufler toutes les routines système qui traduisent dans un sens puis dans l’autre l’alphanumérique en numérique. Il suffirait d’enfouir les routines existantes sous les I/O avec un Handler dédié lors de l’écriture des sections dans la page HTML. Ces simplifications apporteraient quelque chose aux clients car le point fort de CGIDEV2 est de permettre à ceux qui connaissent le RPG d’écrire des programmes stateless Web de gestion sans devoir apprendre langage autre que le RPG, ni devoir confier les applications Web stateless à des équipes externes toujours débordées donc peu réactives.

Ceci étant, reste le problème commercial car RPG OA doit être commandé en option. On peut se demander quel prospect acceptera de payer RPG OA à IBM uniquement pour tester gratuitement pendant un mois le Handler d’un éditeur ?

 

Disons que la technologie RPG Open Access est vraiment très prometteuse sur le papier car elle permet de masquer la complexité. Indiscutablement, c’est là une demande des développeurs RPG en entreprise qui sont à la fois des analystes de gestion et non des techniciens pointus. Simplement, l’offre a été selon nous mal emmanchée. Beaucoup de consultants US pensent qu’IBM devrait réagir vite car RPG OA est un produit stratégique qui a suscité d'énormes attentes et une grande émotion dans la communauté de la plateforme i comme en témoignent les nombreux blogs sur le sujet.

 

Donc, pour le moment disons que le serpent de mer a disparu mais qu’il va revenir. Nous le guettons  et nous tiendrons nos lecteurs informés dès qu’il apparaitra à nouveau. Espérons qu'il se montrera moins timide la prochaine fois.

Jean Mikhaleff