description d’erreur de caractère. En utilisant le paramètre d’erreur numérique, vous transmettrez un zéro en retour s’il n’y a pas eu d’erreur ; sinon, vous transmettrez un code d’erreur.

La description de cette erreur pourrait être dans un paramètre de sortie caractère ou un fichier base de données personnalisé, ou bien le code d’erreur pourrait être l ’ i d e n t i f i c a t e u r d’un membre de message iSeries.

Quelle que soit la stratégie de paramètre choisie pour communiquer les erreurs, standardisez-la avec toutes vos API CBD. Si vous améliorez votre mécanisme de traitement d’erreur, prenez le temps de revenir en arrière et de réagencer vos autres API CBD.

Lorsque l e s codeurs à l’ancienne (sur écran vert) développent une API à utiliser pour le Web, ils négligent souvent le traitement des erreurs imprévues.
Quand des erreurs inattendues se produisent dans une application 5250, un message OS/400 surgit sous les yeux de l’utilisateur, lequel appelle aussitôt le service informatique. Mais, quand cette même erreur survient dans une API invoquée à partir d’une application Web, le message va dans la file d’attente de messages de l’opérateur système, et l’utilisateur attend impatiemment devant le navigateur, une réponse qui ne viendra jamais.

Vous devez donc mettre une routine de traitement d’erreurs génériques dans votre RPG, capable de traiter les problèmes imprévus comme les verrouillages d’enregistrement et les erreurs décimales de données. Songez à utiliser les nouveaux codes opération MONITOR et ON-ERROR ainsi que l’ancien stanby : le *PSSR.