MCH1202

Comment s'en sortir

Une zone numérique (condensée ou étendue) contient autre chose que des chiffres valides : des blancs, des zéros binaires, du texte. Le système ne sait pas la lire comme un nombre.

Les causes les plus fréquentes

• Des données chargées sans contrôle : un CPYF FMTOPT(*NOCHK), un transfert de fichier ou une reprise qui a rempli les zones numériques avec des blancs.
• Une structure de données non initialisée : ses sous-zones numériques contiennent des blancs tant qu'on ne les a pas remplies (d'où INZ en RPG).
• Une zone mal définie : le programme lit comme numérique un endroit de l'enregistrement qui contient en réalité du texte, par exemple après une modification du fichier.

Diagnostiquer

En RPG ILE, le message associé est RNQ0907 (erreur de donnée décimale). Pour voir le contenu réel de l'enregistrement en hexadécimal :

DSPPFM     FILE(MALIB/MONFIC)   /* puis F10 pour l'affichage hexadécimal */

En SQL, SELECT RRN(f), HEX(zone) FROM MALIB.MONFIC f montre la zone brute : un blanc apparaît en 40, un zéro binaire en 00, là où l'on attend des chiffres.

Corriger

Réparez les données à la source : corrigez les enregistrements fautifs, puis le programme ou le transfert qui les a produits. En RPG, initialisez toujours les structures de données :

dcl-ds ligne inz;       // INZ : sous-zones numériques à zéro, pas à blanc
  quantite  packed(7:0);
  montant   packed(11:2);
end-ds;

L'option de compilation FIXNBR(*ZONED *INPUTPACKED) fait remplacer les données invalides par des zéros à la lecture : le programme ne plante plus, mais il calcule avec des zéros là où il y avait peut-être une vraie valeur abîmée. À réserver à un contournement temporaire, le temps de corriger les données.