Unicode et la conversion d’applications RPG

Application RPG, Guide de conversion

Dans un article précédent, « Unicode et System i : évolution plutôt que révolution », je montrais la facilité avec laquelle on pouvait prendre une application RPG interactive « anglais seulement » et la transformer pour l’adapter à diverses langues comme l’anglais, le russe et le chinois en même temps sur un fichier écran 5250.

Dans le cas du programme modèle SHIPTORPG présenté dans cet article, la prise en compte de multiples langues se faisait tout simplement : en changeant la base de données avec la commande Change Physical File (CHGPF) pour utiliser Unicode, puis en recompilant l’application *DSPF et RPG. Si vous n’avez pas lu l’article du mois d’octobre, je vous engage à le faire. En effet, le présent article s’y réfère beaucoup : programme, fichier écran et bases de données.

L’article précédent signalait aussi que tous les programmes RPG n’évolueront pas vers Unicode aussi facilement que l’exemple SHIPTORPG. Cet article expose certains de ces programmes « pas si faciles ».
Support de conversion explicite

Reference Field

L’une des raisons pour lesquelles le modèle de programme précédent est passé facilement à Unicode est que le développeur de l’application a tiré parti des outils proposés par le système. Par exemple, le développeur n’a pas défini explicitement les champs de base de données COMPANY, CONTACT, ADDR1 et ADDR2 lors de la définition initiale du fichier écran.

Au lieu de cela, il a utilisé la possibilité Reference Field (REFFLD) de DDS pour réutiliser la définition de données dans les fichiers physiques, ce qui nous a permis de changer la définition de base de données de caractère à Unicode et de confier au *DSPF le soin de repérer automatiquement le changement en Unicode au moment de la recompilation.

Dans la même logique, l’application RPG modèle a été écrite en utilisant des données décrites en externe, et  non des définitions décrites par programme pour les fichiers base de données ORDER, ORDDET et INVEN et le SHIPTODSPF *DSPF. Comme pour la recompilation du fichier écran, une simple recompilation du programme SHIPTORPG a permis au compilateur de repérer automatiquement le changement en Unicode.

Certains de vos programmes RPG ne tirent peut-être pas parti de tous les moyens disponibles. Prenons un exemple concernant REFFLD et les données décrites en externe : ce serait de ne pas utiliser le mot-clé RPG LIKE lors de la définition des champs de travail dans une application. On peut, par exemple, avoir des applications qui utilisent des champs de garde « temporaires » pour restaurer la valeur d’une variable donnée après traitement par un certain code. La figure 1 montre un cas très courant de définition d’un champ de garde, dans ce cas pour le champ CONTACT de la base de données.

Cette méthode, où l’on code explicitement le TempFld comme un champ caractère de 40 octets, vous obligera à modifier le programme source si vous passez à une solution Unicode. La simple recompilation du programme conduira au pire des comportements : le programme fonctionne parfois correctement, mais pas toujours.
Voyons pourquoi la simple recompilation du programme entraîne ce genre de comportement. Une première raison est que CONTACT a maintenant une longueur de 80 octets (CCSID 13488 Unicode requiert deux octets par caractère), alors que TempFld ne conservera que 40 octets de données. Il s’ensuit que la troncature de l’information CONTACT se produira par intermittence (mais de manière prévisible), plus précisément quand l’enregistrement du fichier ORDER traité contient un nom CONTACT dont le stockage demande plus de 40 octets. Autre cause pour ce comportement : quand on donne à TempFld la valeur CONTACT, le RPG runtime convertira les données codées en Unicode de CONTACT en EBCDIC de TempFld et, lors de la restauration de CONTACT à la valeur « originale », convertira les données codées en EBCDIC de TempFld en Unicode de CONTACT. Selon les caractères présents dans le champ CONTACT, la conversion entraînera parfois (mais pas toujours) une perte de caractères. Et les caractères perdus dépendront en partie du job CCSID sous lequel le programme s’exécute.

Mot-clé LIKE

Dans la figure 2, je montre un meilleur moyen de définir la variable TempFld en utilisant le mot-clé LIKE. En présence du mot-clé LIKE, le compilateur RPG définira correctement TempFld comme un champ Unicode de 40 caractères codé avec CCSID 13488. Dans ce cas, une simple recompilation de l’application SHIPTORPG peut encore être réalisée. Signalons au passage que la modernisation de vos applications RPG pour utiliser des fonctions comme le mot-clé LIKE, peut vous être utile même si vous n’utilisez jamais Unicode. Le mot-clé LIKE s’avèrera intéressant par exemple si un champ CONTACT « anglais seulement » doit être porté de 40 caractères à 50. Une recompilation tiendra compte de ce changement dans votre base de données, sans que vous ayez besoin de maintenir les définitions source dans votre programme.

Cette possibilité de RPG de convertir automatiquement des données EBCDIC traditionnelles en données Unicode CCSID 13488, et inversement, posait précédemment un problème parce que la variable TempFld n’était pas définie correctement. Cette possibilité de conversion implicite est généralement une aide utile, quand on passe à Unicode. C’est cette conversion implicite qui permet au code de la figure 3 de fonctionner sans modification du code source. Dans la figure 3, le compilateur RPG sait que le champ UnicodeFld est défini comme CCSID 13488 Unicode et traitera correctement les constantes figuratives comme *Blanks et *Loval, les valeurs littérales comme EBCDIC ‘A’ et ‘ABC’, et les variables comme EBCDIC_Fld lors de la définition de valeurs de variables Unicode. En outre, des opérations courantes comme IF, WHEN et DOW continuent à fonctionner comme prévu. Pour l’essentiel, RPG transformera les valeurs EBCDIC en valeurs Unicode.

Défaillances à la compilation. Cependant, toutes les conversions EBCDIC et Unicode ne sont pas automatiques. La figure 4 montre plusieurs opérations RPG qui échoueront au moment de la compilation. Plus précisément, toute tentative de :

•    concaténer le littéral EBCDIC ‘,’ à la variable Unicode City entraînera le message RNF7421—Operands are not compatible with the type of operator.
•    rechercher un caractère blanc EBCDIC dans la variable Unicode AddrLine provoquera le message RNF0353—The first and second parameters of %SCAN are not of the same type.
•    remplacer la valeur littérale Minnesota dans la variable Unicode AddrLine par la valeur  littérale EBCDIC MN provoquera RNF0382—The second parameter ADDRLINE for %REPLACE is not valid. (En plus de RNF0353 en raison de l’utilisation de %SCAN dans le troisième paramètre du %REPLACE intégré.)
Face à ce genre de situations, il vous faudra modifier le programme source RPG. Ces modifications ne sont pas difficiles, mais elles peuvent prendre du temps et, bien entendu, comme tout changement de code source, créer de nouveaux risques d’erreurs.

Pour pallier ces défaillances de compilation, une méthode consiste à demander explicitement une conversion de EBCDIC en Unicode, en utilisant le Convert to UCS-2 Value built-in %UCS2. Les changements nécessaires pour utiliser cette solution sont mis en évidence dans la figure 5, en montrant également comment le %UCS2 built-in peut empêcher un rapport d’erreur incorrect à partir de l’éditeur source, comme décrit dans la figure 4. L’opération inverse, c’est-à-dire la conversion d’un UCS-2 CCSID tel que 13488 en EBCDIC, peut aussi se faire en utilisant le Convert to Character Data built-in %CHAR. Cependant, ne convertissez vos données dans ce sens que si vous êtes certain des caractères dans la variable Unicode. Une variable Unicode peut stocker n’importe lequel des 96 000 caractères et plus, définis par le standard Unicode. En revanche, des codings EBCDIC à un seul octet courants tels que CCSID 37 ne définissent que 192 caractères. Compte tenu de cette énorme différence de taille du jeu de caractères, la conversion d’Unicode en EBCDIC risque fort d’entraîner une perte de caractères. Là encore, à moins d’être très sûr des caractères utilisés, il vaut mieux convertir les données caractères en Unicode en utilisant le %UCS-2 built-in. La figure 6 montre une seconde méthode de résolution de ces défaillances à la compilation ; bien sûr, elle demande davantage de changement de code source qu’avec le %UCS2 built-in.