de travail, ou autres objets associés
à  la gestion des travaux, par exemple). En revanche, les modifications apportées
aux objets de la bibliothèque QSYS sont perdues parce que tous ces objets sont
remplacés.



Pour réduire le risque de perte d’objets système modifiés, il faut documenter
les modifications qu’on leur a apportées afin de pouvoir les remettre en service
après installation de la nouvelle release. Je suggère de maintenir un programme
CL contenant du code permettant de réinstaurer les modifications personnalisées,
comme les valeurs par défaut des commandes. Il suffira alors d’exécuter ce programme
avec chaque mise à  jour de release.



Si c’est possible, il vaut mieux effectuer ces personnalisations dans une bibliothèque
créée par l’utilisateur que dans QSYS. Bien que l’installation ne remplace pas
le contenu de la bibliothèque créée par l’utilisateur, il faut régénérer les objets
personnalisés qu’elle contient pour éviter des problèmes potentiels, comme par
exemple si IBM rajoute un paramètre à  une commande. A moins de dupliquer la nouvelle
commande puis d’appliquer sa propre personnalisation, on utilisera une structure
de commande périmée. Cette différence peut parfois avoir de graves conséquences.
Le programme CL qui personnalise les objets livrés par IBM doit par conséquent
dupliquer d’abord chaque objet (le cas échéant) puis modifier la copie nouvellement
créée.