Codes opération sans remplacement direct

BitOff et BitOn. Dans de tels cas,
il vaut mieux écrire un programme de
service avec des procédures « bitwise
» pour offrir la fonction équivalente.
Ces procédures utiliseront le
RPG en format fixe, mais au moins la
fonction est à  l’extérieur du code applicatif.
La figure 6 montre également
quatre codes opération de déplacement
de zone que le format libre ne
prend pas en charge. Comme avec
des fonctions « bit-wise », on peut
écrire des procédures pour réaliser la
fonction que ces codes opération fournissent.
Au cours des 20 dernières années,
je n’ai jamais écrit un programme
de production ayant besoin de ces
codes opération et je n’ai ni vu ni entendu
parler de quelqu’un qui ait été
dans ce cas.

Le RPG en format libre ne supporte
pas les codes opération TestB, TestN et
TestZ. Vos applications peuvent utiliser
modérément certains de ces codes
opération servant à  tester le contenu
de champs. C’est particulièrement vrai
pour TestN. Là  encore, un programme
de service avec des procédures écrites
par l’utilisateur peut convenir.
Les autres codes opération de cette
catégorie sont plus fréquemment utilisés
et plus difficiles à  remplacer.
Prenons, par exemple, le code opération
MoveA, qui permet de :

• déplacer plusieurs éléments de tableau
contigus dans un champ
unique

• déplacer un champ unique dans plusieurs
éléments de tableau contigus

• déplacer des éléments de tableau
contigus vers des éléments contigus
d’un autre tableau

Ajoutons à  cette souplesse la possibilité
de :

• spécifier optionnellement un index
de tableau pour identifier l’emplacement
dans un tableau à  adresser

• ajouter des considérations de longueur
de donnée en utilisant différentes
longueurs de données

• travailler sur plusieurs types de données,
y compris caractère, numérique,
Universal Multiple-Octet
Coded Character Set (UCS-2) et graphique

MoveA remplit tellement de fonctions
que sa puissance est évidente,
tout comme le fait que cette puissance
est fournie au détriment de la clarté.
En fait, il est difficile de déterminer rapidement
ce que sera le résultat d’une
opération MoveA.
Sans MoveA, il faut coder explicitement
les étapes nécessaires à  une situation
donnée. Dans certains cas, on
codera une boucle dans laquelle on déplacera
des données vers et à  partir
d’éléments individuels. D’autres fois,
la solution impliquera des structures
de données avec des sous-champs qui
remplacent les éléments du tableau.
Les possibilités sont trop nombreuses
pour les énumérer ici. Mais l’absence
de format libre pour MoveA incite à  de
meilleures pratiques de programmation
en nous obligeant à  écrire du code
beaucoup plus indicatif de la tâche
concernée.
S’il s’agit de convertir des applications
existantes, MoveA requiert
beaucoup plus de considération que
l’immense majorité des autres
codes opération non supportés.
Malheureusement, un seul fragment
de logique pour remplacer la fonctionnalité
de MoveA ne résoudra probablement
pas tous les problèmes. Et il faudra
probablement créer plusieurs
solutions d’après les circonstances.
Heureusement, la logique de remplacement
devrait être raisonnablement
simple et directe.

Le RPG en format libre ne permet
pas non plus de définir des listes clé.
Pour l’instant, vous avez encore besoin
d’une section de code en format fixe
dans laquelle classer les codes opération
KList et KFLd. Je pense qu’il devrait
y avoir une alternative à  l’utilisation
du RPG en format fixe pour définir
des listes clé. C’est d’ailleurs aussi probablement
l’opinion des concepteurs
du compilateur RPG. J’ai entendu parler
d’une possible syntaxe carte C (Cspec)
qui liste les champs clé sur le
code opération d’I/O. Il se peut également
qu’IBM mette en oeuvre des listes
clé dans des cartes D. Selon moi, il est
probable que nous verrons le format
libre prendre en charge les listes clé
dans un futur proche.