Coder une UDTF externe

pour une
UDTF. Pour les paramètres d’entrée et
de sortie, il faut que le type de données
SQL soit compatible avec le type de
données HLL. Pour savoir comment établir l’égalité entre les types de données SQL et les types de
données dans un HLL particulier, voir le manuel DB2
Universal Database for iSeries SQL Programming with Host
Languages (voir http://publib.boulder.ibm.com/
iseries/v5r2/ic2924/info/rzajp/rzajpmst.pdf). Par souci de
simplicité, c’est la liste des paramètres de base. Vous pouvez
transmettre des paramètres supplémentaires selon les autres
options spécifiées sur l’instruction CREATE FUNCTION. La
figure 4 montre la liste des paramètres RPG pour le programme
IFSDir.
Le deuxième point du coding consiste à  saisir le paramètre
« call type ». La figure 5 montre ses valeurs possibles.
Bien que le résultat de la fonction soit une table entière, le
programme UDTF est en réalité appelé plusieurs fois ligne à 
ligne. Par conséquent, la logique du programme s’articule
sur la valeur transmise au paramètre CALL TYPE. Voici le
pseudo-code pour la fonction principale de IFSDir :

IF CALLTYPE=-1 //OPEN
CALL OPENDIR
IF ERROR
RETURN ERROR
ENDIF
ELSEIF CALLTYPE=0 //FETCH
CALL READDIR
IF ENTRYFOUND
RETURN COLUMN DATA
ELSE
INDICATE EOT
ENDIF
ELSEIF CALLTYPE=1 //CLOSE
CALL CLOSEDIR
ENDIF

Le programme utilise trois
API principales : OpenDir pour
ouvrir un dossier, ReadDir pour
lire son contenu et CloseDir
pour le fermer. Pendant l’initialisation
de la fonction table
comme indiqué par le type d’appel
de -1, l’API OPENDIR est appelée
pour ouvrir le dossier demandé.
Les paramètres d’entrée
sont disponibles mais des données
ne devraient pas être renvoyées
à  ce stade.
Après l’initialisation, le gestionnaire
de base de données
transmettra une requête
« fetch » comme indiqué par le
type d’appel de 0. A ce momentlà ,
le programme appelle l’API
READDIR pour atteindre le nom
d’un fichier provenant du dossier
IFS spécifié. Après avoir lu
un nom de fichier, le programme
appelle le Qp0lGetAttr
pour extraire les attributs du fichier
comme la taille allouée, la taille réelle et la date de création.
Après avoir extrait l’information, le programme définit
les paramètres de sortie (c’est-à -dire, les données colonne
pour la table) et ajoute une ligne à  la table UDTF. SQL continue
à  appeler l’UDTF avec un type d’appel de of 0 (fetch) jusqu’à 
ce que le programme signale la fin de table (EOT, end of
table). Quand READDIR signale cela, il n’y a plus d’entrées à 
lire, le programme IFSDir définit le paramètre d’état SQL à 
‘02000’ pour indiquer qu’il n’y a plus de données (End of
Table).
Après avoir reçu le signal EOT, SQL appelle IFSDir une
fois de plus avec le type d’appel de 1 (cleanup) pour indiquer
au programme qu’il doit maintenant procéder aux activités
de nettoyage. Puis SQL appelle l’API CLOSEDIR, met *INLR à 
« on » pour préparer le programme à  se terminer en bon
ordre. Chaque programme UDTF externe suit la même structure
de base d’initialisation (open), d’extractions de lignes répétées (fetches) et de nettoyage (close), comme indiqué
par le paramètre type d’appel.