Décembre 2014: Lettre RePeGlio 

 Bonjour #Surname# #Name#,

La modernisation et la Grande Lessive.

    Pour moderniser, il faut d’un côté des applications obsolètes et de l’autre des outils qui vont bien afin de leur redonner un second souffle. La modernisation concerne non seulement la webisation des écrans verts, mais aussi, et c’est moins connu, la mise en production des applications Windows.
    Si un informaticien développe et teste une application Windows sur son PC et si plusieurs utilisateurs doivent partager en production la même base de données, il conviendra alors de transporter les données dans un serveur. L’architecture Clients/Serveur met le doigt dans un processus de modernisation.

    Si après quelques années de fonctionnement en mode Client/Serveur, les coûts cachés s’accumulent : versionning lors des mises à jour des PCs, saturation du réseau, multiplication des serveurs, coûts de maintenances etc… la direction Informatique peut décider de passer du mode Client/Serveur au mode Serveur/Serveur. La virtualisation des PCs est une consolidation qui consiste à relocaliser les PCs dans des serveurs et même consolider les serveurs dans des serveurs. La virtualisation est une modernisation de deuxième niveau qui nécessite un hyperviseur propriétaire. Seule l'image écran transite sur le réseau.

Lorsque ce même service informatique, lassé des usines à gaz « virtualisées », décide finalement de réécrire les applications en Cloud pour ne plus subir une gestion complexe, la virtualisation native est dite multitenant par opposition au multi-instances sous contrôle d’un hyperviseur. Cette fois, par définition même, l’entreprise ne subit plus la gestion des changements de version puisqu’un seul programme et base de données sont partagés par tous les utilisateurs. Avec le Cloud, on parle d’industrialisation du logiciel, ce qui laisse sous-entendre qu’avant le Cloud la production logicielle était subie.

    Le passage au Cloud s’apparente plus à une Grande Lessive qu’à une modernisation. Nous le savons aujourd’hui, les applications AS/400 étaient multitenant en natif, l’utilisateur ouvrant dynamiquement une session sur le réseau. Sur AS/400, les informaticiens faisaient du Cloud Privé à leur insu comme monsieur Jourdain faisait de la prose car ce qui caractérise le Cloud est le multitenant. L’AS/400 avait 30 ans d’avance, mais, car il y a un mais, certains consultants blâment les écrans verts AS/400, ce qui nous amène à un autre type de modernisation, à savoir la modernisation des écrans...
    Formellement, les consultants reprochent au RPG de n’être pas un langage ouvert comme Java et d’afficher des écrans datant du DOS ou du Minitel. Examinons respectivement ces deux reproches dans le détail.
    Si le RPG était un langage ouvert comme Java, il fonctionnerait sur Windows et sur Linux. Il conviendrait ensuite d’avoir recours à la virtualisation des écrans avec les hyperviseurs propriétaires comme ESX VMware, XenServer de Citrix ou Hyper-V de Microsoft lors de la mise en production. Toutes ces solutions coûteraient bien plus cher que de recompiler les programmes RPG sur un IBM i où ils bénéficient d’une virtualisation native multitenant à chaque fois qu’un utilisateur ouvre une session sur le réseau pour se connecter. Nous voyons bien qu’avec un RPG ouvert il faudrait au pire avoir recours aux hyperviseurs propriétaires, au mieux recompiler les programmes RPG sur IBM i. Dans les deux cas, un RPG ouvert serait une infamie dans la mesure où la technique de virtualisation par hyperviseur date de la fin du 20ième siècle alors que le Cloud multitenant est une technologie du 21ième siècle. Venons-en maintenant aux fameux écrans verts.
    Les salariés qui ont pour objectif de finir leur travail dans les délais impartis, qui utilisent les mêmes programmes tous les jours, finissent par ne plus prendre en considération l’esthétique des écrans. Pour eux, une liste est une liste et ils demandent aux formulaires d’être contrôlés afin de prévenir toute saisie erronée. Ils demandent des temps de réponse les plus courts possibles, une ergonomie simple ultra standardisée avec les mêmes touches de fonction partout afin de pouvoir passer d’une application à l’autre en gardant les mêmes réflexes. Il est connu que toute nouvelle application de type écrans verts s’apprend en une demi-heure de formation. Si les salariés back-office sont satisfaits des écrans verts, qu’importe l’avis des consultants !
    Nous pouvons dire que, dans ce créneau de l’informatique de gestion back-office, les applications natives RPG sur IBM i sont vraiment des applications du 21ième siècle. La preuve : pour passer du Cloud privé IBM i au Cloud public, il suffit simplement de restaurer les programmes en PaaS (Platform as a Service) sans recompilation.
    Bien entendu, les écrans verts ne conviennent pas aux cadres des entreprises habitués au web ainsi qu’aux utilisateurs front-office du web. Là en effet, nous sommes conscients qu’une modernisation plus ou moins avancée de l’interface s’avère nécessaire.
    Pour le moment, retenons la différence des trois modernisations. Il faut avoir à l’esprit que moderniser peut impliquer des actions de webisation pour les applications IBM i alors que pour Windows une virtualisation des PCs et finalement une refonte totale des applications en Cloud finira un jour par s’imposer. Ainsi, ceux qui ont quitté l’IBM i pour Windows uniquement à cause des interfaces graphiques modernes auront tout loisir de méditer cette citation d’Oscar Wilde : « rien n’est plus dangereux que d’être trop moderne ; on risque de devenir soudain ultra démodé. »

 Jean Mikhaleff/RePeGlio

Pourquoi pas une interface virtualisée multi-tiers ?

    « Virtualiser l’interface utilisateur c’est être multitiers » nous dit Pascal Polvérini, auteur du Redbook IBM sur RPGOA. Pascal Polvérini a animé un groupe de travail composé de responsables de la plateforme IBM i et de développeurs de haut niveau. Voici les grandes lignes de ce projet. Le DSPF est composé de deux parties :
    1) Le programme RPG n’a besoin pour fonctionner que de la partie DDS du DSPF qui décrit la mémoire tampon des données avec la taille et le type (e.g. CODCLI alphanum. longueur : 10 caractères etc…) Cette partie peut être visualisée avec la commande IBM DSPFFD du fichier DSPF.
    2) L’autre partie du DSPF relative à la couche présentation, décrit la position des champs à l'écran ainsi que les attributs 5250 (e.g. COLOR(RED) DSPTR(RI) etc…)
    La virtualisation de l’interface consisterait à décrire la seconde partie, dite couche présentation, en substituant le DSPF avec un langage ouvert XML (ou JSON). « Une interface ouverte écrite en XML n’a aucune limite et peut être contenue dans un tiers autonome » nous dit Pascal. Aux attributs DSPF 5250 pourraient donc s’ajouter pour le Web des widget, des images enfin tout le nécessaire pour rendre une interface HTML attractive.
    Côté programme RPG, les mêmes ordres de lecture/écriture des formats écrans seraient utilisés (READ, WRITE, EXFMT). La cuisine web serait camouflée et prise en charge par un programme handler avec la technologie RPG OA. Pour ceux qui s’intéressent à ce projet ouvert, pragmatique et non intrusif, nous conseillons le lien suivant :
www.ibmioa.com 

Nos références:

Notre Site: www.repeglio.com

Pour un commentaire libre ou pour abonner quelqu'un: jean@repeglio.com


Pour retirer votre email d'envoi  de notre liste de diffusion: 

Retourner-nous la lettre avec en objet OPTOUT et votre email d'envoi:  #E-mail#    sera retiré de notre liste de diffusion.