[V6R1] - Verrouillage d'une bibliothèque [Résolu]

[pwrdwnsys]

Bonjour.

Sur ma machine de développement, je dispose d'une bibliothèque de recette sur laquelle nous simulons les mises en production (livraison des nouveaux objets ou des objets modifiés).

Malheureusement, beaucoup d'applicatifs de recette tournent en même temps que les mises en recette (au mépris de toutes les consignes données) et nous avons donc régulièrement des problèmes concernant l'allocation des fichiers.

L'allocation de la bibliothèque en exclusif (*EXCL) n'a aucun effet : cette bibliothèque peut être mise en ligne et ses fichiers peuvent être utilisés sans aucun problème.
Il n'est pas raisonnable de tenter d'allouer tous les fichiers de cette bibliothèque en exclusif (leur nombre est trop élevé).

Quelqu'un connait-il un moyen me permettant "d'isoler" ma bibliothèque pour que son contenu soit inaccessible, quel que soit le moyen utilisé (y compris l'ODBC et le requêteur SQL interactif) durant mes opérations de restauration ?

Merci.

[m4k-Hurrican]

Je ne vois pas de solution "propre".
Mais si tu peux envisager de renommer ta bibliothèque le temps de la restauration, personne n'y aura accès...

[punkoff]

et avec des droits spécifique ?

[Mercure]

AMA, faire les restaurations le soir, ou la nuit si possible, évite ce genre de problème avec les utilisateurs en journée.

[pwrdwnsys]

Merci pour toutes ces pistes.

Envoyé par m4k-Hurrican

Je ne vois pas de solution "propre".
Mais si tu peux envisager de renommer ta bibliothèque le temps de la restauration, personne n'y aura accès...

Cela n'est pas possible, car j'ai simplifié mon processus, mais mon environnement de recette est une kyrielle de bibliothèques et nous l'avons donc automatisé...

Envoyé par punkoff

et avec des droits spécifique ?

Impossible, nos profils informaticiens nous autorisent de contourner tout cela (je ne vais pas entrer dans le détail)

Envoyé par Mercure

AMA, faire les restaurations le soir, ou la nuit si possible, évite ce genre de problème avec les utilisateurs en journée.

C'est bien dans cette direction que je vais essayer d'aller. En complément de ce que tu m'as conseillé en bricolant les JOBD des utilisateurs...

Merci pour toutes ces pistes. Ca confirme ce que je présentais : pas de solution technique simple...

[m4k-Hurrican]

Je rajouterais une solution, si tu en as la possibilité.
Je ne sais même pas pourquoi je n'y ai pas pensé plus tôt puisque j'ai l'utilisé cette technique moi-même, pour éviter que des personnes se logguent pendant les sauvegardes, à l'époque (lointaine) où la sauvegarde en mise à jour n'existait pas.
Si tes utilisateurs ont un point d'entrée commun (dans mon cas un programme unique chargé d'établir l'environnement de travail complet), tu peux éventuellement tester qu'une dtaara est verrouillée ou non pour leur autoriser l'entrée. Quand tu lances tes interventions, alloues cette dtaara de manière exclusive, et libères là quand tu as fini.

[Mercure]

Envoyé par m4k-Hurrican

...tu peux éventuellement tester qu'une dtaara est verrouillée ou non pour leur autoriser l'entrée.

Cela marchera si on "prend la main" en amont des utilisateurs, mais pas si les utilisateurs sont déjà logués.

[m4k-Hurrican]

C'est vrai dans tous les cas. Quelle que soit la solution, si les utilisateurs sont déjà loggués, il faut bien les faire sortir des applications.
Là il est simple de tester que la DTAARA est déjà verrouillée (les utilisateurs l'allouent en *SHRRD) pour savoir si on doit d'abord les faire sortir. Ensuite une fois le processus lancé, ils ne peuvent plus rentrer.