Eprouvez-vous des difficultés à gérer les fichiers spoolés de votre système ? Il est vrai que la performance est freinée lors d’opérations de spooling du genre WRKSPLF ou WKROUTQ quand il y a un grand nombre de fichiers spoolés sur le système ou dans une file d’attente de sortie particulière.Jusqu’à la V5R4, il était compliqué de gérer des fichiers spoolés parce qu’il n’était pas possible de les sauvegarder et de les restaurer sans perdre plusieurs attributs clés (comme l’identité). De plus, comme il n’était pas facile de savoir quels fichiers spoolés pouvaient être supprimés sans risque après leur vieillissement, il était ardu de contrôler le nombre de fichiers spoolés sur le système. C’est pourquoi la V5R4 comporte plusieurs améliorations permettant de mieux gérer leurs fichiers spoolés.
Gestion des fichiers spoolés en V5R4
Jusqu’à la V5R4, on avait du mal à sauvegarder les fichiers spoolés en raison de leur nature et de leur mode d’identification. En effet, le fichier spoolé était identifié non seulement par le nom du fichier mais aussi par le nom qualifié du job qui avait créé le fichier spoolé et par le numéro de fichier alloué d’après ce job. Comme tout tentative de sauvegarde et de restauration d’un fichier spoolé créait à son tour un autre fichier spoolé (lequel était spoolé sous le job qui le restaurait), le fichier spoolé original avait une nouvelle identité avec un nouveau nom de job qualifié et un nouveau numéro de fichier spoolé. En outre, la liste de bibliothèques sauvegardée avec le fichier original était remplacée par celle du job chargé de la restauration. Une telle situation posait des problèmes lors de l’impression du fichier spoolé si l’on utilisait des ressources (comme des overlays, des segments de page) et si ces ressources étaient spécifiées en utilisant *LIBL comme nom de bibliothèque.
Désormais, il est plus facile de sauvegarder et de restaurer les fichiers spoolés, grâce à quelques changements subtils apportés aux dernières releases. En V5R2, IBM a amélioré le spooling de telle sorte qu’un fichier spoolé puisse exister même après disparition du job qui l’avait créé. Des champs supplémentaires – le nom du système de job (c’est-à-dire, le système sur lequel s’est exécuté le job qui a créé le fichier spoolé) et la date et heure de création – ont aidé à identifier le fichier spoolé après disparition du job qui l’avait créé. Ces champs étaient nécessaires pour l’hypothèse où les fichiers spoolés avaient été créés par deux jobs différents avec le même nom de job qualifié sur le même système ou sur deux systèmes différents. Grâce à ce changement, et aussi à d’autres améliorations de la V5R3, les fichiers spoolés pouvaient exister dans des pools de disques indépendants, utilisables par des systèmes multiples.
La V5R4 pousse encore plus loin cette logique en permettant aux utilisateurs de sauvegarder et de restaurer les fichiers spoolés de telle sorte que le fichier spoolé restauré soit identique à l’original – y compris son identité totale (c’est-à-dire le nom du fichier spoolé, numéro du fichier spoolé, nom du job qualifié, nom du système de job, date et heure de création). Le fichier spoolé peut être restauré sur le même système où il a été créé, ou sur un autre choisi par l’utilisateur. Le produit BRMS (Backup, Recovery and Media Services) a aussi été amélioré pour tirer parti de la nouvelle situation.
Téléchargez cette ressource
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é.
