Tester des données numérique non condensées

nombre est positif ou négatif.

Lorsqu’un programme AS/400 définit la valeur d’un champ non condensé via une opération
numérique, il utilise automatiquement le chiffre hexadécimal F pour les zones
de tous les octets à  l’exception de celui placé à  l’extrême droite. Si le nombre
enregistré est positif, il utilise F pour la zone de cet octet. Si le nombre est
négatif, il utilise D. Donc, le nombre 123 sera stocké dans un champ de (7,0)
de la manière suivante :

F0 F0 F0 F0 F1 F2 F3

De la même manière, le nombre -123 sera stocké ainsi :

F0 F0 F0 F0 F1 F2 D3

Lorsqu’il s’agit de lire les données non condensées, l’AS/400
est un peu plus souple. En effet, il peut interpréter des champs qui ne correspondent
pas tout à  fait à  ce modèle. Voici les règles appliquées pour lire des données
non condensées :

• Le demi-octet de droite de chaque octet doit contenir une valeur comprise
  entre 0 et 9.
• La zone de l’octet à  l’extrême droite doit être une lettre de A à  F. A,
  C, E et F signent un champ positif. B ou D impliquent qu’il est négatif.
• Il n’existe aucune restriction sur le contenu des zones pour les autres
  octets que celui se trouvant à  l’extrême droite. Ils peuvent contenir n’importe
  quel chiffre de 0 à  9 ou lettre de A à  F.

Si nous faisons correspondre les caractères numériques et alphabétiques d’un champ
avec des caractères spéciaux (à  l’instar de ce que nous avons fait en testant
les données condensées), nous pouvons utiliser ces règles pour écrire une requête
qui teste la validité d’un champ non condensé de type (7,0).

Notez dans la figure 2 que la chaîne de caractères utilisée pour le test de concordance
utilise un _ et non un %. La raison en est que le deuxième chiffre de chaque octet
d’un champ non condensé doit être numérique. Pour tester cela, spécifiez les chiffres
qui doivent correspondre au caractère numérique de substitution (#) et lesquels
peuvent prendre n’importe quelle valeur. Les opérateurs SQL/400 de comparaison
de chaînes de caractères ne sont pas assez puissants ni flexibles pour permettre
d’écrire une instruction SELECT complètement générique pour travailler avec n’importe
quel champ non condensé, sans tenir compte de la taille.
Cependant, si on connaît la longueur du champ lorsqu’on écrit la routine SQL,
il est encore possible de coder une requête chargée de tester les données illisibles
dans un champ numérique non condensé (certaines implémentations de SQL autorisent
également des “expressions régulières” qui permettent de tester l’existence d’une
valeur parmi plusieurs ou la présence d’une chaîne de caractères périodique).

Cette fonctionnalité SQL constitue un utilitaire générique

Les instructions SQL telles que celles des figures 1 et 2 peuvent être complexes,
mais elles permettent de rechercher les données numériques non valides dans les
fichiers, ce qui n’est normalement possible qu’en écrivant des programmes personnalisés.
Avec un peu de travail, il est possible de les intégrer dans un programme RPG
(avec un nom de champ et un nom de fichier comme paramètres), et peut-être avec
une routine, de générer une chaîne de caractères de test pour les données numériques
non condensées en fonction de la taille du champ. Dans la pratique, cette fonctionnalité
SQL constitue un utilitaire générique pour garantir que les champs numériques
de tous les fichiers demeurent impeccables.

Ann Lewkowicz est senior analyst chez ITP Management Services à  Cincinnati,
Ohio.