Fonctions RPG, Support de conversion implicite

•    Initialisation avec le mot-clé INZ
•    Attributions avec EVAL, MOVE, MOVEL et free-form =
•    Comparaisons avec IF, IFxx, DOW, DOWxx, DOU, DOUxx, WHEN, WHENxx, CABxx, CASxx et COMP
Les opérations RPG qui ne supportent pas la conversion implicite incluent :
•    concaténation en utilisant le free-form + ou CAT
•    Les fonctions intégrées %CHECK, %CHECKR, %REPLACE, %SCAN, %TRIMx et %XLATE
•    Les valeurs de renvoi de prototype de procédure et/ou des paramètres passés comme CONST ou VALUE

Ces deux listes ne sont nullement exhaustives. Elles couvrent simplement les principales fonctions RPG que vous êtes susceptible d’utiliser.

Bien que certaines fonctions supportent effectivement la conversion implicite, elles peuvent demander quelques changements supplémentaires. L’opcode DSPLY, par exemple (qui, je l’espère, n’est pas standard dans votre entreprise pour les affichages interactifs), peut afficher avec succès le nom COMPANY EBCDIC mais échouera à la compilation en présence d’un nom COMPANY Unicode. Tout simplement parce que DSPLY supporte une longueur maximum de 52 octets pour l’affichage de variable. On l’a vu, Unicode CCSID 13488 utilise deux octets par caractère, et donc la version Unicode de COMPANY est définie comme ayant 80 octets de long. Un moyen de contourner cette erreur de compilation consisterait à utiliser le %SUBST built-in avec l’opcode DSPLY. Mais le mieux serait de « moderniser » et de cesser d’utiliser l’opcode DSPLY.

Une langue à la fois ou plusieurs simultanément

Le passage de vos bases de données en Unicode peut se faire pour de nombreuses raisons. Souvent, on veut avoir un ensemble de programmes et de définitions de bases de données utilisables, une langue à la fois, dans n’importe quel pays. (Notons qu’il est possible d’avoir un ensemble de programmes remplissant la condition de n’importe quelle langue à un moment donné, sans utiliser Unicode. C’est l’exigence d’avoir une définition de base de données qui requiert l’usage d’Unicode.) Dans d’autres cas, la motivation peut être d’avoir un ensemble de programmes et de définitions de bases de données utilisables comme démontré dans le programme SHIPTORPG (voir l’article « Unicode et System i : évolution plutôt que révolution). C’est-à-dire, un programme qui traite de multiples langues simultanément comme le programme SHIPTORPG permettait l’utilisation simultanée de texte en anglais, russe et chinois.

Une langue à la fois. L’utilisation de la conversion de caractères RPG, implicite ou explicite, est gérable dans le cas d’une langue à la fois. Vous connaîtrez à l’avance la langue nationale à utiliser pour une installation donnée de votre produit, vous pourrez anticiper le jeu de caractères dont l’utilisateur se servira, et vous pourrez définir les attributs job CCSID et Language ID (LANGID) appropriés pour l’utilisateur. Le mode une langue à la fois offre un environnement bien défini où les conversions de caractères se font de manière prévisible. J’ai signalé dans la figure 1 que des caractères Unicode peuvent être perdus pendant une conversion en EBCDIC, selon le job CCSID. Si vous savez déjà que l’utilisateur n’emploiera que Simplified Chinese, vous pouvez mettre le user job CCSID à 935—Simplified Chinese extended. En utilisant le CONTACT et l’exemple TempFld à base de caractères (parce que le nom CONTACT pour Order number 2 est entièrement en Simplified Chinese), l’opération de conversion du nom CONTACT en TempFld puis restauration de la valeur de CONTACT ultérieurement, réussira. En revanche, si vous changez le nom CONTACT en une autre langue : russe, thaï, arabe, Traditional Chinese, ou une autre des dizaines de langues nationales prises en compte par l’IBM i, certains caractères nationaux risquent d’être perdus. Face à ce risque de perte, vous devez savoir si votre objectif est de prendre en charge une langue à la fois ou plusieurs simultanément. C’est un point de conception clé qui déterminera si votre programme pourra bénéficier de la conversion de caractères RPG.

Plusieurs langues simultanément. En cas d’utilisation simultanée de plusieurs langues, je déconseille les conversions RPG de type implicite ou explicite entre des variables EBCDIC et des variables Unicode. Vous pouvez raisonnablement permettre à RPG de faire des conversions avec des valeurs littérales ou des constantes nommées, parce que vous savez à l’avance exactement quels caractères interviennent dans la conversion. Mais sachez que l’utilisation de constantes pourrait causer des problèmes lors du développement d’une application multilingue — indépendamment des considérations Unicode. Des constantes comme le signe $ (dollar) ou l’utilisation d’une virgule dans une ligne d’adresse ne sont pas d’un usage universel. Mais avec des données variables, on risque fort de perdre des données caractères à cause de la taille imposante du jeu de caractères Unicode. Or, la perte occasionnelle d’un caractère, la sortie prématurée (ou tardive) d’un DOU, ou l’obtention d’une comparaison incorrecte avec une instruction IF vous causera bien des soucis dans le futur. Le changement de toutes les opérations de calcul pour être certain que vos programmes n’utilisent que des variables de types de données identiques  (EBCDIC ou Unicode) peut donner plus de travail initialement pour adapter les applications existantes, mais vous en serez récompensé par la suite. Heureusement, les données les plus susceptibles d’être converties en Unicode sont du texte et pas souvent utilisées dans des comparaisons logiques. Bien sûr il y a des exceptions.

Quelle que soit la méthode (une langue à la fois ou plusieurs simultanément) choisie en définitive, considérez les deux avant de faire évoluer vos applications existantes vers Unicode. Pour toute nouvelle application, il vaut mieux opter pour plusieurs langues simultanées, pour préserver l’avenir.