> Tech > Le programme de traitement de la commande

Le programme de traitement de la commande

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Dans la sous-routine d’initialisation, l’une des premières choses que je fais dans la sous-routine @InzProgram du programme, est d’utiliser l’API opendir pour tester si le répertoire transmis a été correctement ouvert. Si ce n’est pas le cas, je renvoie un message à la commande indiquant que le répertoire n’existe pas.

Le programme de traitement de la commande

Si opendir a réussi, je continue à vérifier si le fichier CLNIDLOG existe et, si oui, à le supprimer.

Ensuite je crée et ouvre le fichier pour m’assurer qu’il est vide et prêt à l’emploi. Le fichier CLNIDLOG est un fichier plat natif qui sert à deux choses. Son double rôle est déterminé par le mode: *LIST ou *CLEAN. En mode *LIST, je liste les noms de fichiers IFS et les âges en jours dans le fichier log (figure 2). En mode *CLEAN, le fichier CLNIDLOG devient un enregistrement indiquant si oui ou non un fichier IFS a été correctement supprimé (figure 3).

La journalisation des suppressions réussies ou ratées par rapport aux fichiers IFS laisse une trace. Vous pouvez utiliser cette trace pour changer les autorités des fichiers qui ont besoin d’un nettoyage mais dont les privilèges d’accès ne permettent pas à la commande CLNIDLOG de les supprimer. Dans la logique principale, la première chose à faire est d’amorcer la boucle (DOU) en lisant la première entrée du répertoire que j’ai ouvert précédemment.

L’API readdir sert à cela. Readdir renvoie un pointeur vers la structure de données Entry si une entrée a été lue, ou renvoie null s’il n’y a pas d’autres entrées à lire. Quand j’ai une entrée, je vérifie bien qu’il ne s’agit pas des caractères point (.) ou doublepoint (..) qui servent à indiquer les placeholders de ce niveau et d’un niveau au-dessus. Ensuite, je construis le nom de fichier et de chemin complet vers l’entrée que j’ai lue, parce que je dois transmettre cela à l’API stat() , qui me donnera l’information restante pour ma tâche dans la sous-routine @GetStatInfo.

La seule chose qui me concerne à propos de cette entrée de répertoire IFS est le type d’objet qui m’indique si c’est un fichier stream et si oui, son âge exprimé en nombre de jours. A ce stade, je sais que c’est un fichier stream et j’ai déterminé son âge en jours. Une simple instruction if m’indique si ce fichier doit être nettoyé ou non. Si c’est un fichier nettoyable, j’utilise la procédure locale #DeleteIFSFile() pour le supprimer.

Cette procédure utilise la commande ERASE pour cela et renvoie un ID message indiquant si l’opération de suppression a réussi ou non. (Dans mon test, je n’ai pas pu supprimer certains fichiers pour des raisons d’autorité.) J’écris ensuite l’information log dans le fichier CLNIDLOG pour indiquer si la suppression a réussi ou échoué. Enfin, dans la sous-routine @Exit Program, je ferme le fichier log et je quitte. Remarque: La plupart des procédures locales dans le programme RPG CLNID, mis à part #LogMsg, résident normalement dans un programme de service.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010