Ce qu’il faut savoir : Un coup d’oeil au code

fichier, le nom du journal, et la gamme des récepteurs (receiver range) transmis par l’utilisateur.

Quelques points à  prendre en compte :

1/ Comme le montre la figure 5, nous ne sélectionnons que les entrées  » R  » (Record ) du journal. Pour notre exemple, nous ne voulons que les entrées qui montrent qu’un enregistrement a été ajouté, mis à  jour, ou supprimé. Celles qui montrent qu’un fichier a été ouvert ou sauvegardé, ne nous intéressent pas.

2/ *TYPE4 est spécifié comme type de format. Des quatre options que propose le paramètre OutFilFmt, c’est celle qui donne le plus de détail.

3/ *CALC est utilisé pour la longueur de données propre à  l’entrée et pour la longueur d’indicateur nul. Ainsi, les enregistrements ne seront pas tronqués et seront de longueur fixe.

  Pour construire un nouveau fichier qui combine les colonnes des deux fichiers existants, il nous faut la source DDS de ces derniers. La commande RTVPFSRC (Retrieve Physical File Source) extrait la source avec l’aide de l’iSeries NEWS RPG IV Toolkit. On peut utiliser RTVPFSRC comme outil autonome, mais RTVJRNDTA l’utilise pour créer les membres source DDS pour le fichier de sortie DspJrn indiqué par l’utilisateur. RTVPFSRC1 (figure 6, disponible à  www.iseriesnetwork.com) est le programme de traitement de commande de RTVPFSRC. Il commence par la procédure MbrExists du Toolkit pour s’assurer que le fichier demandé existe réellement. D’autres procédures du Toolkit servent à  créer et/ou ouvrir un fichier source qui contiendra le DDS. Il faut ensuite créer un espace utilisateur pour recevoir les informations à  propos du fichier. Il existe plusieurs méthodes pour déterminer les noms de champs et de formats du fichier mais, heureusement, le Toolkit offre quelques programmes de service très utiles pour extraire les données nécessaires et les placer dans un espace utilisateur :

1/ CreateUsrLst crée l’espace utilisateur. Nous appellerons notre liste d’utilisateurs QTEMP/RTVPFSRCUL.

2/ Ensuite, la procédure LoadRfmtLst dans le programme de service RFMTLST met le nom du format d’enregistrement dans l’espace.

3/ La procédure NextUsrLstEnt nous permet ensuite d’extraire ce nom de l’espace utilisateur, de le formater, et de le placer dans le membre source.

4/ La procédure LoadFldLst réutilise le même espace utilisateur pour extraire les noms de champs pour le fichier.

5/ Une boucle utilise NextUsrLstEnt pour obtenir un nom de champ, puis pour appeler une routine chargée de formater et de placer le champ dans le fichier source.

6/ Après traitement du dernier champ, le fichier source est fermé et l’espace utilisateur supprimé.

  RTVJRNDTA1 appelle ensuite le programme RTVJRNDTA2 (figure 7, disponible à  www.iseriesnetwork.com) pour créer un troisième membre source DDS qui combine les enregistrements source provenant à  la fois du membre du journal et du membre du fichier original. Il n’est pas nécessaire d’inclure la colonne JOESD provenant du fichier de sortie, parce que nous remplaçons cette colonne par les définitions de colonnes provenant du fichier demandé par l’utilisateur. RTCVJRNDTA1 revient en scène pour compiler le source DDS et créer le nouveau fichier. La dernière étape consiste à  faire un CPYF avec Format Option (*NOCHK) qui copie dans le nouveau fichier, le fichier de sortie provenant de DspJrn. Quand on utilise la commande RTVJRNDTA, il faut savoir ce qui suit :

1/ Pour compiler les programmes pour RTVJRNDTA, l’iSeries NEWS RPG IV Toolkit doit être installé.

2/ L’outil RTVJRNDTA contient les entrées pour les enregistrements supprimés. Si vous ne journalisez que les images  » after  » (après), le résultat risque d’être surprenant (des figures nulles, par exemple). Rappelons donc que les colonnes provenant des enregistrements supprimés ne contiendront pas de données utilisables si l’on ne journalise que des images  » after « .

3/ De même, quand la commande DspJrn crée un fichier de sortie avec un format *TYPE4, elle comporte un identificateur de journal (JOJID) de 10 octets contenant des données hexadécimales importantes pour l’OS/400 mais beaucoup moins intéressantes pour vous. Les données hexadécimales de ce champ peuvent amener le terminal à  afficher les données sous forme d’image inversée, clignotante, ou de couleur inattendue. Pour éviter cet inconvénient, il suffit de ne pas inclure la colonne JOJID dans les requêtes.