Exemple de conception d’écran et de programme

timeout) (Figure 2).
En plus du fichier écran, j’ai crée un programme RPG simple qui affiche le format,
vérifie que le temps imparti n’est pas écoulé. Si c’est le cas, il met fin au
programme. Les codes du DDS et du programme RPG III de cet exemple sont présentés
respectivement dans les figures 3 et 4.

Analysons le code du programme présenté dans la figure 4. La
ligne 1 représente une définition standard d’un fichier écran externe, d’I/O
combiné et entièrement procédural. La ligne 3 spécifie le nombre maximal de
périphériques pouvant être géré par une instance de ce programme. Autrement
dit, chaque instance du programme ne contrôle qu’un périphérique de sortie et
nous ne souhaitons pas ajouter d’autres périphériques à  chronométrer également.
(Remarque : en RPG IV, vous spécifieriez le mot clé MAXDEV(*FILE) au lieu de
NUM).

La ligne 4 se rapporte au fichier écran et elle indique que le
fichier contient des informations sur la structure de données (INFDS). Les lignes
5 et 6 représentent respectivement la structure de données et le champ permettant
de tester le code d’état retourné lorsque l’écran dépasse le temps qui lui est
imparti (code d’état 1331). La ligne 7 marque le début de la boucle principale
qui indique que le programme va s’exécuter jusqu’à  ce que l’indicateur de dernier
enregistrement (*INLR) soit détecté. La ligne 9 affiche le format à  l’écran.
La ligne 11 lit le fichier écran (et non le format de l’enregistrement) et modifie
l’indicateur 90 lorsque le temps alloué à  un écran est écoulé (c’est-à -dire,
si la valeur WAITRCD est dépassée sans qu’une touche de fonction ait été enfoncée).
La ligne 13 vérifie l’indicateur 90. Si il est activé et que le code d’état
est 1331 (ligne 14), l’indicateur LR est activé à  la ligne 15, mettant effectivement
fin au programme et rendant le contrôle au programme appelant. La ligne 18 vérifie
si la touche F3 (CA03 dans le DDS du fichier écran) a été enfoncée. Si c’est
le cas, elle met aussi fin au programme en activant l’indicateur LR.

L’horloge du timeout (la valeur WAITRCD) est réinitialisée lorsqu’un
utilisateur appuie sur la touche Entrée ou sur toute autre touche de fonction.
Soulignons qu’il faut utiliser les codes d’opérations WRITE et READ (ligne 9
et 11 dans la figure 4) au lieu du code d’opération EXTFMT et du mot clé INVITE
(dans la figure 3) pour autoriser la détection des timeout des écrans.

Toutefois, une mise en garde s’impose quant à  l’utilisation de
cette technique. En effet, il faut s’assurer que les mises à  jour complexes
des bases de données soient achevées avant de mettre fin à  un programme suite
à  la détection d’un timeout sur un écran. Il existe plusieurs façons de procéder
: une méthode consiste à  journaliser les fichiers et à  les soumettre au contrôle
de validation ; une autre méthode consiste à  effectuer toutes les mises à  jour
au moment de l’acceptation de la transaction (en utilisant par exemple, une
touche de fonction pour ajouter une commande). On peut également utiliser une
file d’attente pour enchaîner les mises à  jour et ensuite actualiser la base
de données lors de la confirmation de la transaction. Si on utilise le contrôle
de validation avec de multiples mises à  jour intercalées avec des affichages
à  l’écran, il faut annuler les mises à  jour précédentes avant de mettre un terme
au programme par suite de dépassement de timeout.

Jim Elkins est consultant
senior chez Bradford and Galt Consulting Services à  St. Louis.