Monitoring des erreurs à  l’exécution

de gestion principal,
et l’erreur pouvait être résolue ultérieurement, grâce aux procédures de contrôle
des utilisateurs et de reporting des exceptions que nous avons mises en place.
Si nous écrivons maintenant le même code en utilisant des instructions EVAL, nous
allons au devant d’une erreur à  l’exécution. Dans l’incapacité de coder toute
les instructions EVAL de tous les nouveaux programmes pour que le résultat ne
saut pas en dépassement de capacité, nous courrons le risque d’avoir un traitement
important très difficile à  rectifier en cas de problème.



Il paraît étrange qu’IBM permette de coder TRUNCNBR(*NO) sur des vieux codes opération
RPG à  la compilation, mais pas l’inverse (TRUNCNBR(*YES)) sur les nouveaux. Je
sais qu’il est possible de capturer les erreurs à  l’exécution en utilisant l’extension
(E) sur certains codes opération, mais nos manuels nous incitent à  penser que
ce n’est pas le cas pour EVAL.

Comment puis-je monitorer ces types d’erreurs dans un programme qui autorise la
troncature d’une zone résultat et permet au programme de se poursuivre à  l’instruction
suivante ?



R : Je subodore qu’IBM regrette de gérer les dépassements de capacité arithmétiques
en RPG. La décision de gérer les dépassements de capacité arithmétiques a été
prise à  un moment où les principes de programmation n’étaient pas consolidés de
la même façon qu’ils le sont aujourd’hui. Le gestion des dépassements de capacité
en RPG encourage les pratiques de programmation douteuses et expose à  des problèmes
de performances potentiels. Les soucis de performances surviennent lorsque le
programme est en dépassement de capacité parce que le contrôle est passé à  la
routine de traitement des exceptions du système d’exploitation. Le gestionnaire
d’exceptions doit alors déterminer s’il y a ou non un gestionnaire pour cette
exception. Si oui, il passe le contrôle à  ce gestionnaire. La gestion des dépassements
de capacité nécessite des instructions supplémentaires, susceptibles d’affecter
les performances, surtout si on fait cela de manière répétée dans le même programme.



On peut faire en sorte qu’un gestionnaire de conditions ILE capture, et ignore,
les erreurs de dépassement de capacité. Il est également possible d’écrire ce
gestionnaire de conditions pour informer le programme en erreur qu’il y a eu un
overflow. Toutefois, il serait difficile (pour ne pas dire impossible) de singer
l’action RPG de troncature gauche du résultat en RPG IV parce que lorsqu’il y
a un overflow le résultat n’est pas disponible au gestionnaire de conditions.



Mike Cravitz