Lettre Aout 2013    

 Bonjour {Genre} {Nom},

L’ardoise magique et le serpent de mer.

Avant les écrans 5250, il y avait le mode conversationnel. Un utilisateur muni d’un clavier connecté à une imprimante, attendait que l’ordinateur imprime la question d’un programme comme : « Entrer le montant et ENTREE ou F3=Sortir» l’utilisateur saisissait alors un montant et la conversation continuait : « Entrer le code TVA puis ENTREE » à la suite de quoi le montant hors taxe, la TVA et le montant TTC, calculés automatiquement s’il vous plait, s’imprimaient en retour. Le programme bouclait pour répéter la conversation depuis le début, à condition d’avoir assez de papier.

    La mécanique du mode conversationnel pouvait alors être assimilée à une sorte de machine à calculer programmable.
    Il y eu ensuite les écrans en mode caractères que nous connaissons. L’informatique passa alors du conversationnel au mode transactionnel, la page correspondant à une transaction. On passa du papier imprimé à l’écran, véritable ardoise magique électronique qui effaçait tout à chaque transaction.
    Puis, les types d’écrans se sont multipliés avec le client/serveur évènementiel, le Web et maintenant les terminaux mobiles. Cependant, force est de constater après tant d’années qu’aucune ardoise magique ne s’est imposé par rapport à l’autre :

  • les écrans en mode caractères restent très efficaces en Back-Office, plus particulièrement en saisie où les temps de réponses sont inférieurs à la seconde. Il ne faut pas oublier qu’un utilisateur salarié qui utilise un logiciel longtemps et souvent finit par connaitre l’ergonomie par cœur : les temps de réponses et la stabilité deviennent alors les facteurs les plus importants du rendement.
  • les écrans évènementiels PC excellent (sans jeu de mot) lorsqu’ils sont en relation avec la bureautique.
  • les écrans Web sont omniprésents du fait de la popularité les navigateurs.
  • enfin les terminaux mobiles à ergonomie bien particulière sont incontournables pour les itinérants.
   Autrement dit, une équipe informatique devrait en théorie pure connaitre le RPG, HTML, PHP, .css, javascript, Java, .net… en plus du métier du client et des besoins des utilisateurs. Nous voyons bien que les équipes informatiques croulent sous la complexité. Cette situation est devenue non viable et non enviable.
    Il n’y a pas d’autre alternative crédible selon nous que de changer de logiciel. Nous pensons que les programmes multi-tiers permettraient une adaptation au changement.
    Un programme est dit multi-tiers lorsqu’à l’exécution il sélectionne de lui-même automatiquement l’interface qui va bien en fonction du terminal client. Vous l’aurez compris, cela suppose avant tout une indépendance presque totale de la logique applicative réutilisable avec une déclinaison de présentations. Toutes ces présentations pourraient être mises en œuvre à l’aide d’un designer wysiwyg de très haut niveau ne nécessitant pas de connaissance en nouvelles technologies.
    D’où une question existentielle relativement à la pérennité de nos applicatifs hérités : le programme RPG serait-il un bon candidat au multi-tiers?
Première constatation : le DSPF (display file) du programme RPG est compilé afin d’obtenir un fichier de communication, plus précisément un objet *file, pour transporter l’information sur le réseau jusqu’au terminal client. Il serait intéressant d’analyser l’objet *file du DSPF avec la commande IBM DSPFFD. Nous remarquons que pour chacun des formats écran (Record), nous avons des champs décrits les uns à la suite des autres dans la mémoire tampon du programme RPG. Donc, le programme RPG ne connait que les données et pas du tout la présentation.
Voici une expérience complémentaire: supprimons dans le DSPF toutes les constantes et déplaçons les champs -mais en prenant soin de ne pas les intervertir-. Après compilation du DSPF, nous constatons avec la commande DSPFFD que l’objet *file est absolument identique. De plus, le programme RPG peut s’exécuter sans recompilation, sans aucune erreur de niveau, ce qui confirme qu’un programme RPG n’utilise du DSPF que les données de la mémoire tampon visibles avec la commande IBM DSPFFD du DSPF compilé.
    Ceci démontre que nos programmes RPG existants ne gèrent que la logique applicative et pas du tout la couche présentation. Donc, le DSPF pourrait être remplacé par un PF multi-formats de communication et/ou un flot xml sans modification de la logique applicative persistante. On y adjoindrait ensuite par exemple du HTML5+CSS ou autre pour la couche présentation. Le programme fonctionnerait de façon transparente de la même manière.
Deuxième constatation : Il n’y aucune différence, au niveau de la logique applicative (mémoire tampon du programme RPG) entre un formulaire contrôlé 5250 et un formulaire contrôlé Web ou entre une liste Web et un sous-fichier 5250, si ce n’est quelques widgets, des images, des couleurs, des polices de caractères, des calendriers en javascript et parfois des services web. Par exemple, un compte bancaire client contient exactement les mêmes informations en mode caractères, en Web, en mode mobile ou autre : malheureusement si vous êtes en découvert toutes les interfaces vous afficheront le même solde négatif (moins triste en couleurs ?).
    Nous observons que l’architecture de l’IBM i pourrait résoudre le problème avec une seule logique applicative RPG pour plusieurs rendus. A chacun son ardoise magique !

 Jean Mikhaleff/RePeGlio

Le retour du serpent de mer

   Il est certain qu’IBM a déjà donné à ses clients des interfaces graphiques Web sous forme de webisation du flot 5250 avec HATS et Webfacing. Partant de ce principe, les éditeurs en modernisation disent qu’IBM ne fera rien d’autre car si IBM avait dû faire quelque chose, il l’aurait déjà fait. Les éditeurs en modernisation ont très certainement raison.
    Ce n’est pas RePeGlio mais IBM qui a reparlé du serpent de mer ces dernières années alors que tout le monde le croyait disparu et à jamais enfoui sous les abysses:

  • IBM vient de mettre gratuitement à disposition des clients RPGOA qui permettrait notamment d’intercepter les données de communication et d’appeler un programme « handler » (qui prend la main). RPGOA serait la pièce centrale du multi-tiers par l’interception des instructions RPG de lecture et écriture afin de les router.
  • Parallèlement, nous avons un travail collectif, où IBM est partie prenante, pour substituer un .xml standard au DSPF, PRTF mais également PF et LF afin d’ouvrir les interfaces au monde extérieur.
    Il nous manque encore un designer multi-tiers et un environnement « runtime ».
    Le marché du Cloud donnera-t-il assez de grain à moudre à IBM pour ressortir un serpent de mer multi-tiers? Dans les prochaines années peut-être ? Une chose est sure : dans un monde Cloud nos applications héritées vaudront leur pesant d’or avec le multi-tenant natif et le multi-tiers natif!

Produit et site RePeGlio:

RePeGlio est un générateur expert de programmes RPGIV:
Caractéristiques:
- 20 templates ou Wizards pour programmer en questions réponses.
(pas de dépendance à un tiers)
- Code RPGIV homogène, lisible et commenté
-Programmes éprouvés en production sur des milliers de programmes.
  Avantages :-)
- Temps de développement divisé par 10.
- Temps de maintenance divisé par 20.
- Temps de test divisé par 30.
Avec RePeGlio un programme ne se code pas, il se dessine.
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:  {Email}    sera retiré de notre liste de diffusion.