La technique ERRSFL

mot clé ERRMSGID ou SFLMSGID pour afficher les
messages d’erreur, il faudra inclure un texte de second niveau dans les diverses
descriptions de messages.

La figure 2 présente les DDS du fichier écran AGEDS4, que j’ai utilisé
avec plusieurs variantes d’un petit programme de mise à  jour de données de
comptes fournisseurs, pour tester la techniques exposée dans cet article. En A
sur la figure, j’ai codé le mot clé ERRSFL.

Observez en C, D, E et F que j’ai codé des messages d’erreur
respectivement conditionnés par les indicateurs 40, 41, 42 et 43. Supposons que
le programme d’en-cours active ces quatre indicateurs avant d’exécuter une
instruction RPG ExFmt pour l’enregistrement SCR01. Sans le mot clé ERRSFL, seul
l’un de ces messages (le premier, AGE0004) s’afficherait. En revanche, avec
ERRSFL, le message AGE0004 s’affiche accompagné d’un signe plus indiquant
l’existence d’autres messages. En actionnant la touche PgDn, le curseur étant
sur le message, un défilement dévoile les trois autres messages. Un défilement
inverse à  l’aide de la touche PgUp permet de visualiser à  nouveau les messages
précédents.

En B sur la figure, j’ai codé les mots clés HELP et ALTHELP. Par conséquent,
si l’utilisateur actionne la touche Aide ou F1 (touche d’aide alternative par défaut),
il verra l’aide de second niveau (éventuelle) associée au message.

On voit bien que l’utilisation du mot clé ERRSFL présente de nombreux
avantages par rapport aux techniques DDS standard. Mais aussi quelques inconvénients.
Tout d’abord, elle nécessite des indicateurs, réduisant ainsi la lisibilité
et la maintenabilité des programmes. Deuxième inconvénient : on ne peut
associer qu’un seul message d’erreur à  une zone d’écran.

Un troisième inconvénient concerne les données de message. Les données
de message (les données substituées à  celui-ci) permettent de réutiliser le
même message dans diverses situations. Supposons un message présentant le
texte de premier niveau suivant : 

• ID &1 invalide.
  Enregistrement &1 introuvable dans le fichier. 

Dans la description du
message, je pourrais définir &1 comme une zone caractères de longueur 20.
Si j’indique ensuite "Client" comme donnée pour ce message, le
message suivant s’afficherait en cas d’erreur : 

• ID Client invalide.
  Enregistrement Client introuvable dans le fichier.
  

La technique ERRSFL permet de définir une zone programme/système dans
le fichier écran, qui contient la donnée du message. Mais l’obligation
d’utiliser ce type de zone limite la souplesse. Considérons le texte de premier
niveau suivant : 

• Montant &1 jours
  en retard invalide.
  

Je pourrais fort bien
utiliser deux fois cette description de message dans un sous-fichier de messages
pour produire deux messages : 

• Montant 30 jours en
  retard invalide.

• Montant 90 jours en
  retard invalide.
  

Si je ne définis
qu’une zone programme/système, je ne peux pas produire ces deux messages à  la
fois. Il faut alors définir deux zones programme/système différentes pour
contenir, respectivement, les données de message "30" et
"90". Pas très commode. En fait, le codage en dur des valeurs
"30" et "90" dans deux messages différents est probablement
aussi simple, et c’est d’ailleurs ce que j’ai fait dans ce cas. Donc, bien que
l’on puisse utiliser les données de message avec la technique ERRSFL, sa mise
en oeuvre n’est pas aussi souple qu’on le souhaiterait.

La technique du sous-fichier de messages utilisateur est supérieure à 
la technique ERRSFL, parce qu’elle présente les mêmes avantages, sans imposer
ces trois inconvénients. Voyons de plus près cette autre possibilité.