Mais il ne donne pas d’ASCII en sortie !

pour faire une sortie en ASCII, le système d’exploitation se charge généralement de la traduction. Par exemple, dans une application Web, le serveur HTTP convertit votre EBCDIC en ASCII – il le fait pour n’importe quel langage, pas seulement RPG. Il en est de même pour les API IFS : elles vous permettent de convertir des jeux de caractères très facilement – aussi facilement qu’en Java.

Désordre des personnalités multiples

Selon Denoncourt, RPG a de multiples personnalités. Sur ce point, nous sommes d’accord. Cela dit, pour moi cette caractéristique est un atout, tandis que Denoncourt pense clairement le contraire. Quand vous consacrez du temps et de la sueur à développer une application, vous voulez préserver cet investissement. Cela ne signifie pas que vous deviez conserver la même ancienne technologie pour toujours – mais que vous devriez la conserver jusqu’à ce que le changement s’impose sous l’angle de la gestion, plutôt que de changer parce que tel dirigeant de Microsoft ou Sun a décidé de rompre la compatibilité.

Ceux qui ont développé du logiciel pour Visual Basic 3.0 en 1993 ne peuvent encore pas exécuter leur code dans le dernier VB.NET. Il faut le modifier et le retester en profondeur. Par comparaison, je peux prendre un programme RPG/400 de la même année, lui appliquer la commande CVTRPGSRC, le compiler comme une application ILE RPG/400 native, et il fonctionnera parfaitement.

Beaucoup de gens ne réalisent pas cela : même si vous investissez beaucoup en RPG/400 (le dialecte AS/400 de RPG III), vous pouvez convertir votre code en RPG IV très rapidement avec la commande CVTRPGSRC, et vous aurez un code RPG IV natif. Nul besoin de réécrire votre code ou même de le modifier : exécutez- le simplement au moyen d’un outil ! Bien sûr, il aura encore la personnalité RPG III, loin d’être idéale, mais au moins vous n’aurez pas à conserver votre code comme du code RPG III à tout jamais.

IBM s’est efforcée de fournir les mêmes fonctions en RPG IV qu’en RPG III, afin que les programmes continuent à fonctionner de la même manière. Il y a quelques exceptions mineures, comme l’opcode FREE. (Franchement, l’opcode FREE n’a jamais bien fonctionné. La plupart de ses utilisateurs n’ont pas remarqué qu’il laissait les fichiers ouverts quand il fermait le programme. Parce que RCLRSC ferme les fichiers et décharge les programmes de la mémoire, il y a peu de raison d’utiliser FREE, et s’il existe des exceptions, elles peuvent être traitées avec des groupes d’activation.)

Convertir l’ancien code est un bon moyen d’aborder la modernisation. Vous sortez ainsi de l’ancien langage RPG III obsolète et obtenez un environnement dans lequel vous pouvez commencer à ajouter des fonctions modernes à votre code. Mais ce n’est que la première étape vers la modernisation.

Il convient ensuite de réaménager le code existant pour en faire quelque chose d’un peu plus moderne. Ne comptez pas alors sur un outil : que vous vous accrochiez à RPG, ou que vous convertissiez votre code existant en Java ou en quelque chose d’autre, importe peu, les outils ne sont pas assez intelligents pour repenser votre logique de gestion. Il faut l’intelligence d’un programmeur pour rénover votre code en plus moderne.

L’avantage de garder RPG est de pouvoir moderniser graduellement. Vous pouvez convertir en RPG IV aujourd’hui, puis lentement et sûrement convertir des programmes existants en une « personnalité » plus moderne de RPG. Comme il s’agit toujours de RPG, l’apprentissage est moins important que si vous permutiez les langages. Il y a quand même une courbe d’apprentissage non négligeable et vous devez changer votre philosophie à propos de la conception d’applications, mais c’est un changement beaucoup plus facile que d’apprendre un langage différent issu d’une source différente.

Je l’ai dit, je suis d’accord avec le fait que RPG a différentes personnalités. L’article de Denoncourt en a même oublié quelques-unes. En V3R2, RPG a reçu des sous-procédures, ce qui permet d’écrire des modules avec de multiples routines appelables. Il a aussi fourni des prototypes, qui facilitent l’écriture d’interfaces bien définies pour ces routines, afin que votre code puisse être correctement encapsulé. A partir de ce jalon, est arrivée une personnalité complètement nouvelle en RPG IV, celle d’une application orientée service. Vous pouvez désormais créer toutes vos règles de gestion dans une suite de procédures qui sont disponibles (comme « services ») pour tous les autres programmes ILE de votre système.

Plus récemment, avec l’avènement des services Web et des procédures stockées externes, vous pouvez ouvrir ces services à des langages non ILE qui peuvent même se trouver sur un autre ordinateur. Cette personnalité de RPG, dans laquelle les programmes sont largement constitués d’appels de procédures, est celle que vous devriez viser dans des projets en Modern RPG.