que la fermeture du fichier (sauf pour un shared close) et l’utilisation de l’opération force-end-of-data forcent les mises à jour, suppressions et additions restantes en stockage auxiliaire. En fait, elle devrait dire que quand un job ferme un fichier pour lequel il est le seul job ayant le fichier ouvert pour mise à jour, le système le considère comme une limite de transaction et s’assure que toutes les pages changées du fichier sont écrites avant que l’opération de fermeture ne se termine. Quand le programme utilisateur reprend la main après la fermeture, tous les enregistrements auront été planifiés pour écriture. Cela peut demander des secondes ou des minutes, parce que chaque écriture est planifiée de manière synchrone pour s’assurer qu’elle est reçue à l’IOP disque et que l’écriture peut aller à son terme.

L’utilisateur final doit donc faire un compromis entre la performance et la reprise. Sachant que les fonctions de terminaison système sont plus intelligentes maintenant que par le passé et qu’elles sont généralement capables d’assurer l’intégrité des données, bien souvent Company aBc peut améliorer le temps d’exécution en évitant une grande partie du traitement du flux de données du last closer.

Savez-vous ce qui se passe si Job A est suivi de Job B, luimême suivi de Job C, où chaque job traite le fichier X et est le seul job présent dans le système ? La fermeture de fichier de Job A a lieu avant que Job B ne démarre, et ainsi de suite. Vous pourriez exécuter chaque job dans un environnement de test pour voir s’il peut être traité dans un certain laps de temps. L’opération peut durer plus longtemps quand tout le flux du job est rassemblé et exécuté avec un jeu complet de données et de mémoire disponible. L’une des premières choses à vérifier est la possibilité d’un scénario last updaterclose.

Le correctif suivant a été utilisé dans des flux de job batch et a réduit de plus de 50 % le temps d’exécution, en évitant le last updater-close. Ce n’est certes pas la solution élégante, mais elle marche.

Pour éviter les écueils du scénario last updater-close, je vous conseille de dire au système que, même si un job ferme le fichier, il y a un autre job dans le système qui a le fichier ouvert pour la mise à jour, et par conséquent un forçage de fichier n’est pas nécessaire à cette fermeture. Pour cela, démarrez un job d’application fictif ayant un programme qui ouvre le fichier pour la mise à jour et lit et met à jour un enregistrement dans le fichier. Il ne suffit pas d’ouvrir le fichier. Les fonctions base de données exigent qu’au moins une écriture soit effectuée dans le fichier. Après avoir ouvert le fichier et réécrit un enregistrement, le programme met le job dans un état d’attente de temporisation jusqu’à ce que le flux du job de production se termine. Ensuite, le programme utilise CL pour trouver et annuler le job fictif, lequel est implicitement réveillé et le système ferme les fichiers ouverts. Avant d’annuler le job fictif, vous devez exécuter un close explicite dans le dernier job de production.