Les UDF en production

d’aujourd’hui. La colonne prix du rapport devra indiquer (en imprimant « inconnu »,
par exemple) si un enregistrement prix de base est manquant ou si un article n’a
pas de prix courant. Il est difficile d’extraire les données nécessaires avec
une instruction Select sans UDF, comme le montre la figure 10. Pour s’assurer
que la dernière date effective (à  la date du jour ou avant) est le seul enregistrement
sélectionné, il faut une sous-requête corrélée. Tandis qu’en écrivant une UDF
appelée RtvPrice, on peut réduire le SQL à  l’instruction Select, figure 11.

La figure 12 présente l’instruction Create Function qui définit l’UDF RtvPrice.
La fonction a deux paramètres, item (article) et date effective (Eff_date), et
renvoie le dernier prix de base en vigueur à  la date effective ou avant. La figure
13 présente le programme ILE RPG de l’UDF.

La section de code est constituée d’une instruction de position et d’un état de
lecture suivis d’une vérification pour voir si le prix a été trouvé. Si aucun
prix n’est trouvé, la variable d’indicateur null de la colonne de résultat (price_ind)
est mise à  -1 afin que le résultat de l’UDF soit null.

Il faut bien veiller à  ce qu’une fichier traite toutes les conditions d’erreur.
Si une fonction ne traite pas certaines erreurs, SQL s’en chargera, au risque
de fournir des résultats déplaisants. En général, une erreur UDF non traitée amène
SQL à  répondre par une annulation, à  tout message CPF qu’il reçoit, à  terminer
l’exécution de l’instruction, et à  émettre son propre message d’erreur sous la
forme d’un message informationnel ou d’un message d’échappement (selon l’application
SQL). Il est donc fortement conseillé de ne pas laisser les UDF se terminer anormalement.

Les programmes utilisant SQL doivent vérifier la variable SQLState après chaque
opération SQL. Les UDF écrites en CL doivent comporter des commandes MONMSG (Monitor
Message) aux endroits appropriés. Les UDF RPG peuvent utiliser la fonction intégrée
%Error sur les codes opération d’I/O appropriés (Les codeurs en RPG III peuvent
utiliser l’indicateur LO) et la sous-routine de traitement d’erreur *PSSR.

Figure 13, la sous-routine de traitement d’erreur *PSSR intercepte toutes les
erreurs de programmation (une erreur de donnée décimale, par exemple). En présence
d’une condition d’erreur, le programme donne aussitôt la main à  cette sous-routine.
De même, comme Infsr(*PSSR) est indiqué sur la carte F, les éventuelles erreurs
associées au fichier Item_Price invoqueront aussi la sous-routine *PSSR.

Notons que le fichier est ouvert manuellement (alors que RPG ouvre le fichier
automatiquement). Donc, si l’opération Open échoue, la sous-routine *PSSR traitera
l’erreur. Cette sous-routine se contente de mettre SQL State à  une condition d’erreur
(« 38I02 ») et de donner au paramètre Message Text le texte de message d’exception
extrait de la structure de données d’état du programme. L’application SQL qui
appelle la fonction aura son SQL State mis à  « 38I02 » et le champ SQLErrMc dans
la SQLCA (SQL Communication Area) reçoit le texte de message associé.