J'ai été en désaccord avec un collègue au sujet de la manipulation d'indicateurs en tant que tableaux, comme dans le code suivant :
| C | MOVEA | '00000000' | *IN(60) |
J'ai été en désaccord avec un collègue au sujet de la manipulation d'indicateurs en tant que tableaux, comme dans le code suivant :
| C | MOVEA | '00000000' | *IN(60) |
néanmoins, même dans
des programmes RPG IV modernes. J’ai dû récemment changer
un programme d’affichage pour utiliser un autre indicateur
pour conditionner un champ sur l’affichage ; chaque indicateur
semblait avoir été utilisé, jusqu’à ce que j’aie
examiné toutes les lignes MoveA et trouvé un indicateur au
milieu d’un groupe qui avait été activé mais jamais utilisé.
Il est encore pire de souscrire à un indicateur à l’aide
d’une variable telle que *IN(Ind). Mon collègue était
convaincu qu’il devrait employer la souscription de tableaux
d’indicateurs pour résoudre ce problème particulier : il avait
environ 20 champs de valeurs différentes sur un écran pour
un système multidevise. Il fallait valider chaque champ quant
au nombre de positions décimales et à l’unité minimum autorisée
(certaines devises n’ont pas de décimales représentées
par des centimes ou des pences, et d’autres ont des valeurs
tellement petites que même une unité est trop petite).
Sa solution consistait à utiliser une sous-routine chargée
de valider la valeur. Pour chaque champ d’écran consécutif, la
valeur était placée dans un champ de travail et dans un jeu
d’index représentant le premier des deux indicateurs possibles
pour les messages d’erreur sur le fichier écran. Les
snippets de code suivants montrent ce qu’il avait fait :
| c | Eval | w#ValAmount = CostFld1 |
| c | Eval | Ind = 64 |
| c | Exsr | ValAmount |
|
:
: |
||
| c | ValAmount | Begsr |
Le coding de validation :
| c | If | . . . . |
| c | Eval | *in(ind) = *on |
| c | Endif | |
| c | If | . . . |
| c | Eval | *in(ind+1) = *on |
| c | Endif | |
| c | Endsr |
De mon côté, j’ai employé un appel prototypé adressé à
une procédure. Voici quelques snippets tirés de la solution
qu’il avait utilisée :
La définition de procédure dans les cartes D du programme
:
| d ValAmount | pr | |
| d w#valamount | 15 02 Value | |
| d w#inde | n | |
| d w#inma | n |
L’appel de procédure dans les cartes C :
| c | callp |
| ValAmount(Costfld1: *in64: *in65) | |
La procédure à la fin de la source :
| p ValAmount | b | |
| d ValAmount | pi | |
| d w#valamount | 15 02 Value | |
| d w#inde | n | |
| d w#inma | n |
Le coding de validation :
| c | Select | |
| c | When | . . . . |
| c | Eval | w#inde = *on |
| c | When | . . . . |
| c | Eval | w#inma = *on |
| c | Endsl | |
| c | Return | |
| c | e |
Vous conviendrez sûrement que la ligne CallP est bien
plus claire et qu’elle montre quels indicateurs sont utilisés.
Face aux failles de résilience des tenants M365 (configurations, privilèges, sauvegarde). Découvrez 5 piliers pour durcir, segmenter et surveiller vos environnements afin de limiter l’impact des attaques. Prioriser vos chantiers cyber et améliorer la résilience de vos tenants Microsoft 365.
Femmes et métiers de la tech : une attractivité réelle freinée par des stéréotypes persistants
Moderniser le développement logiciel : de la fragmentation à l’intégration
Analyse Patch Tuesday Mars 2026
Une nouvelle ère de la modernisation du mainframe
Communes, entreprises ? Non, face au RGAA 5, l’IA seule ne rendra pas vos sites accessibles