Bonjour,
lorsqu'un fichier est en disp=old dans un job, est-ce qu'il est inaccessible au DELETE ADRDSSU pendant toute la durée du job ou uniquement la durée du step qui détient le fichier en DISP=OLD ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
ADRDSSU et delete de fichier
Bonjour,
lorsqu'un fichier est en disp=old dans un job, est-ce qu'il est inaccessible au DELETE ADRDSSU pendant toute la durée du job ou uniquement la durée du step qui détient le fichier en DISP=OLD ?
Le fichier sera seulement inaccessible pendant la durée du step qui le prend en old. L'addrdssu pourra donc faire le delete sans problème.
Je trouve ça dangereux...
Il n'y a pas de moyen de bloquer l'accès à un fichier tant qu'il est pris par le job... au moins d'empêcher le delete... Car si un fichier est dumpé deleté alors que le job est en plein traitement, ça craint un peu...
Bonjour
Une précision, l'ENQ sur un fichier est posé au début du job. ET, comme dit précédemment, levé à la fin du STEP qui utilise le fichier.
Si un fichier n'est plus utile au job, en quoi est-ce génant qu'il soit effacé?
a+
Je rejoins Bernard.
Après, il y a plein de solution pour parer ton problème si c'est un problème et la première est de se pencher sur l'ordonnancement. Tu peux mettre des dépendances entre tes jobs où si tu possèdes TWS (je ne connais pas les autres ordonnanceurs), tu peux mettre des ressources sur des jobs (ainsi, ton fichier sera réservé par le job jusqu'à la fin de celui-ci).
Ben je suis d'accord mais le fichier est utilisé par plusieurs steps...Envoyé par bernard59139
Le premier step qui utilise le fichier va le libérer, et ensuite pendant le lap de temps qu'il y a entre le le premier step qui utilise le fichier et le dernirr step qui s'en sert, le fichier à ce moment là peut- être effacé et là ça pose problème...
Et c'est à ce moment précis qu'interviennent les ordonnanceurs.
Bonjour
Dans ma précision, j'aurai du dire
l'ENQ sur un fichier est posé au début du job. ET, comme dit précédemment, levé à la fin du dernier STEP de ce même job qui utilise le fichier.
Dans un job, un fichier utilisé au 1er step et réutilisé "n" steps plus loin ne pourra pas être éffacé.
"Dans un job, un fichier utilisé au 1er step et réutilisé "n" steps plus loin ne pourra pas être éffacé."
Je ne suis pas tout à fait d'accord avec toi Bernard ou alors on a du mal à s'expliquer. Au sein d'un même job, c'est possible. Entre job différent, non, tu auras une contention.
Mais sur le fond, il y a quand même un problème. Comment sont gérés tes jobs? Comment est déclenché ton DUMP DELETE? Est-il possible que ton DUMP DELETE se déclenche avant ton job qui prend le fichier en old que va t-il se passer si tel est le cas? Je trouve cela bizarre.
Ce que je lis dans le JCL Reference ( une doc qui n'est pas toujours d'une évidente lecture ... ) :
Donc il semblerait bien que le fichier soit alloué en exclusif jusqu'à la fin du dernier step le référençant dans le job.DISP and ENQ: Before starting the first step of a job, the initiator requests control of all of the data sets in that job by issuing an ENQ for each of them, using the value specified for DISP to determine the kind of ENQ issued. The initiator issues the ENQ for each data set at the highest level required for that data set by any step of the job. For example, if all steps of the job request shared control of a specific data set (DISP=SHR) then the ENQ for that data set is requested as SHR. If, on the other hand, any step of the job requests exclusive control of a specific data set (DISP=NEW, DISP=MOD, or DISP=OLD), then the ENQ for that data set is requested EXCL.
The ENQ for each dataset is released at the end of the last step of the job referencing it. Since ENQs cannot be downgraded from EXCL to SHR, if one step needs the ENQ EXCL and a following step only needs it SHR, the ENQ is still issued as EXCL and held until the end of the last step which references that data set, at which point the ENQ is released entirely.
Ceci étant, je suis je suis d'accord avec "Lemming1406", cet d'enchaînement d'actions est plutôt étrange.
C'est un comportement prévu au départ ou tout simplement une erreur de manipulation ou de planification ?
Ben au fait, je suis dans le cas d'un DUMP/DELETE assynchrone.
Ce qui s'est passé :
Le DUMP à dumpé le fichier vide... (le DUMP est en TOL(ENQF))
Ensuite le delete s'est effectué quand le fichier à été alimenté...
Donc on dump le fichier vie et on le delte quand il est plein... C'est facheux...
La solution est peut-être de faire planté le dump si le fichier est en ENQ.
Bonjour
Pour être sur d'avoir en exclusivité un fichier, il faut enlever TOL(ENQF)
Pour être sûr d'éffacer uniquement les fichiers sauvegardés et sans avoir eu de maj, il faut utiliser ADRDSSU (pour le dump et le delete) avec le paramètre DSCHA (dataset changed), doc adrdssu & dscha.
Sans cela, il y aura toujours un risque.
Bonjour bernard59139 et merci pour cette option de ADRDSSU que je ne connaissais pas.
Par contre je ne peux pas m'en servir.
Tu peux comprendre que dans la complexité d'une production il y a toujours des fichiers qui ne sont pas mis à jour et que l'on a besoin de sauvegarder...
Si j'intègre cette option, je vais avoir pas mal de chaîne qui vont plantés uniquement parceque des fichiers n'ont pas été mis à jour...
Je trouve que c'est une option dangereuse..
Re bonjour
Je comprend ton problème, mais j'ai répondu technique de base.
Si le DELETE a eu lieu sans sauvegarde, c'est que votre facon de planifier les évènements (les jobs, mais pas que cela) n'est pas bonne.
UN travail de fond s'impose peut-être
Non, non la sauvegarde à bien eu lieu et le delete aussi.
mais seulement, la sauvegarde à sauvegardé le fichier vide, et le delete à supprimé le fichier plein, je pense que le mieux est de supprimer le TOL(ENQF)
comme tu me l'as suggéré précédemment.
tu as sauvegardé n'importe quoi, c'est comme si tu n'avais rien fait, vu du fichier, désolé d'être aussi direct.
Tu as eu la cas 1 fois, il va se reproduire, c'est certain. Et reste la possibilité que ce cas se soit produit et que personne n'est rien vu.
Quoiqu'il en soit je trouve que c'est une aberration d'effectuer un DUMP avec le paramètre TOL(ENQF) en production.
Mias même en retirant ce paramètre, il est tout de même possible que je retombe dans le même cas...
Le souci général c'est que ce n'est ps la chaîne elle même qui sauvegarde ses propres fichiers, c'est une chaîne exterieurs qui sauvegarde les fichiers de toute la production.... Ca permet d'économiser des K7, mais il y a des cas, comme celui que je viens de vous exposer ou ça ne fonctionne pas terrible...
Quelles méthodes utilisez-vous pour la gestion des sauvegardes dans les différentes productions que vous avez pu rencontrer ?
Si chaque chaîne sauvegarde ses propres fichiers, comment faites-vous pour économiser de la K7 car cette méthode est très consommatrice de K7 ?
Sur mon site, il y a des sauvegardes "avant batch" (K7), des sauvegardes disques avant chaque passage de job qui modifie un fichier (on ne sauvegarde que les fichiers mis à jour) et enfin, il y a une sauvegarde "après batch" (K7) avec les enchainements qui vont bien.
A te lire, j'ai l'impression que la sauvegarde dont tu parles devrait attendre la fin de tous les traitements avant de se dérouler mais visiblement, ce n'est pas le cas. J'insiste mais es-tu réellement sûr de tes enchainements?
Ben au fait c'est plus compliqué que ça notre gestion des sauvegardes...
Ca va pas être facile d'expliquer ça ...
En gros il y a tous les jobs de fin de chaînes qui dépose un ordre de sauvegarde dans une tables DB2. Donc tous les fichiers sont sur disques jusqu'à 3 h00 du matin ou il y a une application qui tourne et qui va gober tous les ordres DB2 (lignes de sysin ADRDSSU) se créer une sysin et tout sauvegarder d'un seul coup. Comme je l'ai dis, ça permet d'économiser de la K7.
Par contre le souci c'est quand une chaîne passe 2 par jour. (C'est ce qu'il s'est passé)
A la fin de la première chaîne, un ordre de sauvegarde est placé dans la table DB2,or il y a une 2ème chaîne qui passe juste après. Si on ne fait rien il va y avoir des duplicate dataset vous êtes d'accord.
C'est là ou il faut s'accrocher...
He ben, pour éviter ça, tous les chaînes ont un job au début qui scanner cette fameuse table DB2, s'il trouve un ordre de sauvegarde qui les concerne il vont exécuter cette sauvegarde (là on consomme de la K7, on n'a pas le choix )
Dans mon cas, cette sauvegarde de début de chaîne à bien eu lieu et s'est bien passé ( la deuxième application à donc sauvegardé les fichiers de la première application) Jusque là on est bon.
Mias l'application qui tourne à 3h00 du matin (vous vous souvenez, celle qui gobe tous les ordres DB2) avait pris du retard... Elle avait donc gobé l'ordre de la première application. vous suivez toujours là, on y est presque ;-)
Et elle à donc essayé d'exécuter la sauvegarde de la première application (mais c'était déjà fait par la deuxième),
Elle s'est donc occupé des fichiers de la deuxième application qui elle était en cours.... Et catastrophe, Dump de fichier vide et delete de fichier plein...
Ouf...
Bonjour
Comme tu n'as pas de dépendance entre les sauvegardes et les traitements de maj, le seul moyen de résoudre ce genre ce problème est de rendre "unique" chaque fichier à sauvegarder.
Un truc que j'ai souvent vu, c'est de coller un time-stamp (ou équivalent) au fichier, soit dans toute la chaine, soit en fin de chaine par un rename.
Ne pas oublier qu'un robot peut casser et être indisponible quelques heures. J'ai déjà vu une prod devoir faire 3j sans k7, ca a été très très chaud. et dans un autre cas, un robot qui tombait en panne toutes les heures, sans raison évidente.
ce que je ferais:
- repérer les fichiers critiques
- agir pour rendre ces fichiers uniques (le problème s'est produit, il se reproduira)
- analyser le job de sauvegarde et agir (ou pas) sur les fichiers utilisés par qqun d'autre
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager