Unicode et IBM System i : évolution plutôt que révolution

Pour corser l’exercice, nous prendrons le cas d’un Chinois ayant une adresse russe.

Plus précisément, nous irons d’un programme applicatif ILE RPG en utilisant le support display file (*DSPF) pour présenter l’écran que l’on voit dans la figure 1, à la même application ILE RPG, en continuant à utiliser le support *DSPF, pour présenter l’écran de la figure 2. Vous remarquerez quelques différences !

Différence importante, nous utilisons maintenant un navigateur pour afficher l’information de livraison plutôt qu’une session d’émulation 5250 classique de iSeries Access for Windows. S’il est vrai que iSeries Access for Windows supporte Unicode dans beaucoup de fonctions qu’elle fournit, PC5250 n’en fait malheureusement pas partie. Pour afficher correctement l’anglais, le chinois et le russe dans un format d’enregistrement *DSPF, il nous faudra un émulateur 5250 validé Unicode. Pour cet article, j’utilise iSeries Access for Web et le serveur applicatif Web intégré sur V5R4. Pour installer iSeries Access for Web avec V5R4, rendez-vous sur le site d’IBM, de même que pour configurer le serveur d’applications Web intégré.

On peut utiliser d’autres émulateurs de type navigateur, par exemple HATS (Host Access Transformation Services). D’autres serveurs d’applications comme WebSphere Application Server et le serveur Tomcat ASF (Apache Software Foundation) peuvent être utilisés à la place du serveur d’applications intégré. Bien sûr, votre émulateur doit supporter le flux de données Unicode 5250. Autre possibilité : vous pouvez changer vos bases de données en Unicode et vous vous retrouverez avec les écrans tels que ceux de la figure 3.

Les « blobs » d’images inverses de la figure 3 s’expliquent par le fait que, sans Unicode, l’émulateur 5250 est limité à un flux de données EBCDIC (ou ASCII) traditionnel. Comme le soulignaient les articles précédents sur Unicode, les codings EBCDIC et ASCII ne supportent généralement qu’une langue (ou alphabet) à la fois. L’alphabet d’une langue peut servir à plusieurs langues nationales. Par exemple, CCSID 37 (généralement considéré comme la langue nationale de l’anglais américain du nord) utilise l’alphabet Latin-1 et donc CCSID 37 est efficace avec d’autres langues nationales (comme le français, l’allemand, l’espagnol et l’italien) qui utilisent aussi l’alphabet Latin-1. En revanche, un flux de données EBCDIC ou ASCII n’est pas efficace quand on travaille avec des alphabets de langues multiples, comme le cyrillique (russe), le chinois et le Latin-1.

Dans le cas de la figure 3, l’émulateur est configuré pour EBCDIC CCSID 37 et ce CCSID ne contient simplement pas les caractères nécessaires pour afficher et traiter les caractères chinois et russes, parce que ces langues ne reposent pas sur l’alphabet Latin-1. Si vous reconfiguriez l’émulateur pour le russe, vous pourriez voir l’adresse russe, mais le nom du contact chinois continuerait à apparaître sous forme de blobs d’images inverses. Configurez l’émulateur en chinois et vous verrez le nom chinois correctement mais l’adresse russe sera cette fois-ci en blobs d’images inverses sauf pour les valeurs numériques. En revanche, un émulateur Unicode basé sur 5250 peut autoriser l’utilisation simultanée des trois langues nationales (plus un certain nombre d’autres) car le jeu de caractères (alphabet si vous préférez) d’Unicode englobe toutes les langues écrites d’usage courant.

Le programme applicatif que nous utiliserons, SHIPTORPG, est montré dans la figure 4. Le DDS pour les fichiers physiques Order, OrdDet (Order Detail), et Inven (descriptions d’inventaires) se trouvent dans la figure 5 et le DDS pour le fichier écran SHIPTODSPF, dans la figure 6. Le source que vous trouvez dans les figures 4 à 6 représente une application de type EBCDIC classique : ici de l’anglais basé sur les invites faites dans le fichier écran.