> 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

État des lieux de la réponse à incident de cybersécurité

État des lieux de la réponse à incident de cybersécurité

Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.

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