> Tech > La récupération d’erreurs RPG

La récupération d’erreurs RPG

Tech - Par iTPro - Publié le 24 juin 2010
email

par Julian Monypenny
Les gestionnaires de conditions peuvent piéger les bogues qui se glissent dans les programmes malgré un coding défensif

La récupération d’erreurs RPG

Dans deux de mes précédents articles, j’expliquais comment éviter les erreurs de programmation. Pour écrire des programmes sains, il faut apprendre à  s’attendre à  l’inattendu, pour anticiper les problèmes et s’en prémunir. Malheureusement, il n’existe pas de terminal avec boule de cristal. Malgré tous les efforts d’anticipation, des erreurs se produisent. Reste à  savoir où, quand et pourquoi. Mais la présence d’erreurs ne signifie pas que les programmes deviennent inexploitables. Nous allons voir qu’il est possible de redresser la situation, même après des erreurs.
On peut se récupérer après une erreur de programme en utilisant le modèle de traitement des erreurs de l’OS/400 appelé gestionnaire de conditions. Dans cet article, j’explique ce qu’est un gestionnaire de conditions, comment en écrire un simple et comment l’utiliser pour se rétablir après une erreur de programme.

Conditions et gestionnaires
Avec ILE (Integrated Language Environment), IBM a doté l’AS/400 d’un nouveau modèle de traitement des exceptions. Ce modèle repose sur deux éléments : conditions et gestionnaires.
Une condition est un message d’erreur de l’OS/400, défini par une structure de données appelée jeton de condition. Celui-ci contient une représentation, indépendante de la machine, de l’identificateur du message et de sa gravité. Un gestionnaire de conditions est une procédure qui détermine la marche à  suivre face à  une condition.
Comme les gestionnaires de conditions font partie intégrante de l’OS/400, quand un programme rencontre une erreur à  l’exécution, le système d’exploitation appelle son gestionnaire de conditions de premier niveau pour y répondre. Si le gestionnaire de premier niveau ne peut pas régler le problème, l’OS/400 en appelle un autre de deuxième niveau. Si celui-ci est également impuissant, un gestionnaire de troisième niveau est appelé. Si ce dernier ne parvient pas non plus à  résoudre le problème, le système vérifie que l’utilisateur ait défini et enregistré un gestionnaire de conditions. Dans l’affirmative, c’est celui-ci qui est appelé pour déterminer l’action à  mener. Les actions les plus courantes sont les suivantes :

 Reprendre l’exécution du programme défaillant. Le programme ignore que la condition a été générée et l’exécution se poursuit à  l’instruction suivante.
 Transmettre la condition au programme défaillant en envoyant un message d’exception à  sa file d’attente de messages. S’il s’agit d’un programme RPG IV, le message d’exception provoque sa fin anormale, sauf si l’on code dans ce programme une sous-routine de statut de programme (*PSSR, Program Status Subroutine).

L’action de transmission n’a qu’un effet, celui de mettre fin au programme par le système standard de traitement des erreurs du RPG. C’est l’action de reprise du programme qui fournit les moyens nécessaires pour redresser la situation après erreurs. Nous allons donc examiner un gestionnaire de conditions simple pour comprendre son principe de fonctionnement.

Téléchargez cette ressource

Microsoft 365 : HP Subscription Management Services en détail

Microsoft 365 : HP Subscription Management Services en détail

Collaboration à distance, environnements de travail et productivité optimisés, gestion évolutive des licences, accélérez la transformation de votre business pour le faire entrer dans l’ère de la collaboration hybride. Découvrez comment le service de gestion des abonnements HP peut vous aider à optimiser vos investissements et votre stratégie de gestion de vos abonnements Microsoft 365.

Tech - Par iTPro - Publié le 24 juin 2010