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.
La Threat Intelligence (TI) rassemble des données, des informations et des analyses détaillées, dans le but de fournir aux RSSI des informations pertinentes, précises et exploitables pour lutter contre les attaques et d'autres problèmes liés à la cybersécurité. Découvrez dans ce Guide comment maximiser les bénéfices de la TI pour votre organisation.