En avant avec le RPG en format libre

Bon nombre des codes opération non
supportés ont une alternative en format
libre. C’est le cas, entre autres, des
opérations mathématiques que la figure
2 présente avec leurs alternatives.
La comparaison suivante démontre
que la version en format libre présente
le double avantage d’être plus concise,
et de refléter l’intention de l’opération
plus clairement que le format fixe :

C        X     Mult     Y       Z
 Z = X * Y;

Cette instruction en format libre
est en fait une instruction Eval. Le code
opération Eval est facultatif quand aucune
extension du code opération
n’est nécessaire.
Vous savez peut-être qu’il faut utiliser
les règles de précision décimale du
résultat (Result Decimal Precision)
(voir WebSphere Development Studio
ILE RPF Reference (SC09-2508)) pour
des instructions Eval contenant des
opérateurs de multiplication ou de division.
Ces règles stipulent que les valeurs
intermédiaires utilisées dans des
calculs n’auront pas moins de décimales
que le résultat. On peut appliquer
les règles de précision décimale
du résultat au niveau du module ou au
niveau de l’instruction. Si c’est au niveau
du module, on code les spécifications
de contrôle suivantes :

H ExprOpts(*ResDecPos)

Cette spécification applique les
règles de précision décimale du résultat
à  tous les calculs dans le module. Si
on applique les règles de précision au
niveau de l’instruction, il faut coder le
code opération Eval avec l’extension
requise. Pour appliquer les règles de
précision décimale du résultat à  l’instruction
en format libre ci-dessus, on
coderait

Eval(R) Z = X * Y;

En règle générale, on utilisera les
règles de précision décimale du résultat
quand les opérandes sont des valeurs
non entières.
Outre les règles de précision, il faut
tenir compte des règles de troncature.
Avec les codes opération Add, Sub,
Mult et Div en format fixe, le RPG
tronque les résultats quand ils dépassent
ce que le champ résultat spécifie.
Avec l’instruction Eval (comme le RPG
en format libre le requiert), il n’y a pas
de troncature : si le champ résultat
n’est pas suffisamment grand pour recevoir
le résultat d’un calcul, le système
émet une erreur.

Il est vrai que la plupart des programmeurs
RPG sont habitués à  la
« fonction » troncature du RPG et jugent
indésirable le comportement générateur
d’erreurs d’Eval. Ils autorisent
donc les champs résultat à  déborder
sans erreurs, suscitant ainsi des informations
inexactes, dont certaines peuvent
se retrouver profondément intégrées
dans la base de données, à  l’abri
de toute détection. Non seulement la
fonction troncature du RPG n’est pas
fiable, mais son utilisation produit un
code non intuitif. Il n’est pas sain d’accomplir
une tâche en s’appuyant sur
les astuces et bizarreries du RPG.
Le RPG en format libre vous oblige
à  connaître et à  traiter les sujets de
troncature quand vous convertissez
des programmes existants, et encourage
de meilleures pratiques de programmation.
C’est, selon moi, un pas
dans la bonne direction.