, , CCSID des fichiers sources

Retour sur une problématique récurrente et souvent mal comprise, donc mal gérée … Et qui pourrait bien s’amplifier avec l’usage plus intensif de l’Open Source.

Vous utilisez historiquement des fichiers sources (objet *FILE attribut PF-SRC) pour stocker vos sources : ces fichiers sont créés avec un CCSID, par défaut le CCSID du job dans lequel vous exécutez la commande CRTSRCPF

Usuellement vous obtiendrez des fichiers sources avec un CCSID 297 ou 1147 pour la France. Si vos machines sont « incorrectement » réglées, un CCSID 65535 (hexadécimal).

Mais également, par restauration d’autres produits, certainement des fichiers avec un CCSID 37 (US).

Pour les langages de programmation (dont le SQL), le CCSID du fichier source est important pour les constantes, qui peuvent par définition êtres des caractères nationaux quelconques. Quant aux instructions, la grammaire des langages les définis sans ambiguïtés.

Caractères spéciaux / nationaux

Pour toutes les commandes, instructions, éléments du langage, pas de soucis d’interprétation

A la compilation, les constantes sont interprétées suivant le CCSID du job, pas celui du source !

En général, les deux CCSID sont identiques.

Par contre, pour les caractères spéciaux utilisés, si l’on regarde de plus près le cas du CL, la documentation indique :

Voilà qui explique les fameuses transformations de @ en à !

En synthèse : le compilateur considère tous les éléments du langage comme étant en CCSID 37, hors les constantes alphanumériques et les quelques caractères listés ici.

Pour le CL : impossible d’utiliser les opérateurs symboliques |> (*BCAT), |< (*TCAT) et || (*CAT)

Le caractère | est mal interprété. Vous devez le remplacer par un !, ou utiliser les opérateurs non symboliques (*BCAT, *TCAT et *CAT).

Pour le SQL : impossible d’utiliser l’opérateur || (même raison).

Vous devez le remplacer par un !!, ou utiliser l’opérateur concat.

Evolution du RPG

Le principe est le même.

Toutefois le langage vous permet également de contrôler le CCSID des variables déclarées. Et depuis la 7.2, de nouvelles directives de pré-compilation permettent d’indiquer des valeurs de CCSID par défaut par bloc de source :

Et pour l’IFS ?

Sur l’IFS, chaque fichier (source ou non) dispose également d’un CCSID. Sa valeur dépend principalement de la façon de créer le fichier (par un éditeur type RDi/VSCode, partage netserver, transfert FTP …).

Premier point d’attention : l’encodage du contenu du fichier doit correspondre à son attribut *CCSID !

VSCode vous indique le CCSID de la donnée, par exemple :

Mais :

1252 = Windows occidental (proche de l’UTF-8 mais pas identique). La raison est que VSCode travaille naturellement en UTF-8.

RDi gère correctement l’encodage/décodage par rapport à la description du fichier.

Pour les autres outils, à voir au cas par cas !

Evolution des compilateurs

Les compilateurs C, CPP, CL, RPG, COBOL supportent désormais (PTF en fonction des compilateurs) un paramètre TGTCCSID :

En réalité ce paramètre a été ajouté pour permettre la compilation plus facilement depuis l’IFS, principalement depuis des fichiers IFS en UTF-8.

Cela ne règle pas nos problèmes précédents, les éléments du langage n’étant pas concernés : nous auront toujours le problème d’interprétation du |

Par contre, c’est utile pour la bonne interprétation des constantes lorsque le job de compilation a un CCSID du source. Et cela permet une meilleure intégration dans les outils d’automatisation.

Conseils

Eviter les caractères spéciaux !

  • N’utilisez pas |>, |< ou || en CL
  • N’utilisez pas || en SQL

Mais on ne peut pas toujours : nous avons voulu compiler QSHONI depuis le build fourni (https://github.com/richardschoen/QshOni?tab=readme-ov-file#installing-and-building-qshoni-via-git-clone-and-buildsh)

Le script propose d’indiquer un CCSID pour les fichiers sources. Mais la seule solution viable est de compiler avec un job en CCSID 37 :

  • soit CHGJOB CCSID(37) avant de lancer le script
  • soit vous pouvez vous créer un profil dédié en CCSID 37 si ces opérations sont récurrentes

Tant que vous n’avez pas de caractères nationaux dans le codes !

Retrouver le CCSID de ses fichiers sources

SELECT f.SYSTEM_TABLE_NAME,
       f.SYSTEM_TABLE_SCHEMA,
       c."CCSID"
    FROM qsys2.systables f
         JOIN qsys2.syscolumns c
             ON (c.SYSTEM_TABLE_NAME, c.SYSTEM_TABLE_SCHEMA) = (f.SYSTEM_TABLE_NAME, f.SYSTEM_TABLE_SCHEMA)
    WHERE f.file_type = 'S' AND
LEFT(f.system_table_name, 8) <> 'EVFTEMPF' AND
          c.SYSTEM_COLUMN_NAME = 'SRCDTA'
    ORDER BY c."CCSID",
             f.SYSTEM_TABLE_SCHEMA,
             f.SYSTEM_TABLE_NAME;

Références

https://www.ibm.com/support/pages/ifs-stmf-ccsids-1252-437-and-819

https://www.ibm.com/docs/en/i/7.4?topic=languages-language-compilers-ccsid

https://www.ibm.com/mysupport/s/fix-information/aDrKe000000PE0UKAW/fi0132711?language=en_US

https://www.ibm.com/mysupport/s/defect/aCIKe000000XohkOAC/dt418562?language=en_US

https://www.ibm.com/docs/en/i/7.5?topic=elements-cl-character-sets-values

https://www.ibm.com/docs/en/i/7.5?topic=values-symbolic-operators

https://www.ibm.com/docs/fr/i/7.5?topic=languages-language-compilers-ccsid

https://www.ibm.com/support/pages/have-you-heard-set-and-restore-directives

https://github.com/richardschoen/QshOni