IBM i, considérations sur la base de données

Bien sûr, vous ne pouvez pas chaîner (CHAIN) à un champ Unicode en utilisant une constante EBCDIC ou une variable EBCDIC.

En réalité, il sera plutôt rare d’accéder aléatoirement à une clé validée Unicode en utilisant des constantes, ou des variables, qui ne nécessitent pas une définition Unicode. Nous avons vu dans l’article « Unicode et System i : évolution plutôt que révolution » et à propos du champ Order Status field ORDSTS, que vous n’êtes pas obligés de changer tous les champs dans vos bases de données en Unicode. Seuls doivent être changés les champs qui seront exposés au plus grand jeu de caractères d’Unicode. Et, si votre application doit lire aléatoirement un enregistrement avec une clé composite de types de données mixtes, par exemple une clé composée de ORDSTS (défini comme EBCDIC) et COMPANY (défini comme Unicode), vous constaterez que CHAIN (OrdSts :Company) FileName;, avec des valeurs spéciales comme SETLL *Start FileName2;, où la clé pour FileName2 est basée sur Unicode, continueront à fonctionner comme prévu.

Le passage d’EBCDIC à Unicode risque de causer un problème lié aux données : il concerne l’ordre de collation ou de tri.

La figure 7 montre les valeurs hexadécimales EBCDIC et Unicode associées à trois noms de sociétés. Comme les index de base de données – par défaut – sont créés au moyen du tri hexadécimal, vos applications verront peut-être des différences dans l’ordre de lecture des enregistrements quand les applications lisent une base de données séquentiellement par clé. En particulier, observez dans la figure 8, où un coding COMPANY EBCDIC est utilisé, que la société 1st National est traitée après XYZ Company. Comparez cela à la figure 9, où un coding COMPANY Unicode est utilisé. Dans ce cas, 1st National est traité avant ABC Company. Vous seul savez si la différence éventuelle dans la séquence de tri est importante ou non. Parfois, la différence n’aura aucune conséquence. Dans d’autres cas, vous serez obligé de maintenir l’ordre de tri original, au prix d’un travail supplémentaire.

Pas d’inquiétude, il n’est pas techniquement difficile de rétablir l’ordre de collation original. C’est aussi simple que de spécifier la table correcte avec le mot-clé SRTSEQ quand vous créez le fichier physique ou logique. Mais je vous conseille de laisser la séquence de tri en l’état si vous recherchez l’effort minimum. La raison de ce conseil est, en partie, due à la difficulté de déterminer la table « correcte ». Il n’y a pas de méthode universelle pour trier des données textuelles. Par exemple, la séquence Unicode par défaut, au moins pour les caractères utilisés dans les figures 7 à 9, est ce à quoi un utilisateur ASCII s’attend et il sera surpris par un rapport qui utilise la séquence EBCDIC de la figure 8. Cependant, le problème plus vaste est qu’il n’y a aucune séquence de tri répondant aux attentes culturelles des diverses langues supportées par Unicode. Vous pouvez bien sûr spécifier des tables d’ordre de tri différentes pour différents utilisateurs (c’est-à-dire, fournir des vues de fichiers logiques différentes par langue), mais avant de vous engager dans cette voie, demandez-vous si quelqu’un est sérieusement préoccupé par ce détail. Si l’ordre par défaut pose un problème, il existe une solution.

On l’a vu, la solution peut consister à associer la table d’ordre de tri correcte au fichier approprié. Ou, si vous préférez une solution plus robuste, vous pourriez mettre à niveau/moderniser votre accès base de données de RPG I/O à SQL imbriqué pour l’application concernée. SQL, entre ses nombreuses caractéristiques, permet de réordonner dynamiquement les enregistrements de la base de données d’après les préférences culturelles de l’utilisateur actuel, sans être obligé de créer des fichiers logiques uniques pour satisfaire chaque utilisateur. Et, vous vous en doutez, l’IBM i permet plusieurs autres solutions. Mais c’est un sujet trop vaste pour cet article.

Cette même considération sur la collation s’applique aux applications RPG. Si un programme suppose, dans l’esprit EBCDIC, qu’une valeur de champ de « 1st Federal » est supérieure à une valeur de champ de « ABC Company », le fait de passer à Unicode sans changer le comportement de l’application RPG invalidera cette supposition. C’est une situation plutôt rare, mais il existe des solutions.
La transformation d’une application pour supporter des langues multiples ne se limite pas à *DSPF, aux calculs de programmes, et aux accès aux bases de données. En effet, il est probable que vos applications génèreront un rapport ou deux, enverront des messages contenant un texte de remplacement qui est actuellement en EBCDIC, et ainsi de suite. Mais vous constaterez que le système et le compilateur de langage RPG sont prêts. Et il y a d’autres documentations. L’IBM Information Center offre des informations sur :

•    générer des fichiers d’imprimante basés sur Unicode
•    quelles polices d’imprimante supportent le jeu de caractères Unicode (sachez que toutes les imprimantes ne peuvent pas imprimer le jeu de caractères Unicode)
•    envoyer un texte de remplacement de message en Unicode
•    utiliser Unicode avec SQL, Query, Open Query File (OPNQRYF), User Interface Manager (UIM) et Client Access
•    créer des fichiers logiques pour associer Unicode à EBCDIC, une possibilité utile pour fournir l’accès à des champs Unicode à l’aide d’utilitaires comme le Data File Utility (DFU). DFU est l’exemple d’un utilitaire qui ne supporte pas Unicode directement, mais il peut travailler avec des données codées en Unicode en utilisant un fichier logique EBCDIC
•    créer des fichiers logiques pour associer EBCDIC à Unicode, une possibilité utile, par exemple, pour le test rapide du support Unicode dans un programme ou utilitaire système
•    bien d’autres domaines de support Unicode
J’espère que vous êtes prêts à commencer à utiliser certains des outils permettant de convertir des applications pour qu’elles reconnaissent diverses langues.