Discussion :

[letophe44]

Bonjour à tous,
Je poste ce message pour avoir des infos sur les codes à ajouter dans nos JCL pour créer des OPC Recover.
Nous avons une chaîne de traitement qui utilise plusieurs DSN pour modification tout le long de la chaîne. Quand le traitement plante, nous sommes très souvent obligé de relancer le traitement depuis le début. J'aimerais faire des points de reprise sur ces jobs qui appel ces DSN pour faire une copie de sauvegarde si plantage. Nous pourrions alors faire une relance manuelle qui déclencherait le Recover de reprise qui utilisera alors le fichier sauvegardé.
Auriez-vous des infos ou des exemples pour paramétrer ce type de RECOVERY?

En attendant vos réponses, je vous souhaite une bonne semaine.

Cdt

[Lemmings1406]

Bonjour,

Le recover est une fonction de TWS qui sur plantages (précisé dans les cartes OPC RECOVER) reprend automatiquement les jobs de certaines façons (substitution de jcl, reprise à l'étape, mise à complete...). Ce que tu veux faire me parait compliqué.

Un exemple d'opc recover: (il faut également l'activer sous tws sinon ça ne fonctionnera pas)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
//*%OPC RECOVER JOBCODE=(*,08-4095),DELSTEP=(DEBUT-FIN),        
//*%OPC ADDPROC=(TOTO,TITI),RESTART=Y

Dans le cas ci-dessus, pour tous les plantages compris entre 8 et 4095 toutes les étapes contenues entre DEBUT et FIN seront supprimées et remplacées par les étapes contenues dans TOTO et TITI puis le job sera relancé.
Le recover est à usage unique. Si le job se plante à nouveau, il restera en l'état.

Pour faire fonctionner RECOVER, il faut aller dans l'option "9 SERVICE FUNC" de TWS puis faire "4 ACTIVATE". Vous devez alors voir la ligne suivante:
"Automatic recovery: Current Status: Active".

Vous pouvez également spécifier des heures de fonctionnement pour le recover dans la bibliothèque TWSPARM dans le membre STDAR.

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
AROPTS  PREDWS(CPU*),EXCLUDERC(0),EXCLUDECC(NOAR)  
             STARTTIME(0145) ENDTIME(0600)

Dans le cas ci-dessus, le recover fonctionnera de 1h45 à 6h00 pour toutes les workstation CPU*.

[letophe44]

Bonjour et merci pour votre réponse.
Je deviens un peu tendu quand vous me dite que se n'est pas si simple (OUPS).
La solution ne serait-elle pas la bonne???
Nous voulons effectivement utiliser la fonction de TWS sur plantage mais sans relance automatique. Si plantage, l'erreur sera analysé et résolu par les pilotes ou les analystes d'exploitation qui feront alors une relance manuelle.
Leurs problèmes concernent les jobs qui apportent des modifications de donnée dans certains DSN utilisé du début à la fin de la chaîne. Si un de ces jobs plantent, ils n'ont pas d'autre choix que de relancer le traitement depuis le début.

Pour chaque job d'actualisation de DSN (ajout ou/et modification de donnée), nous souhaiterions faire une copie de sauvegarde qui sera repris automatiquement si le job est relancé manuellement.
Pour reprendre votre exemple, faire une copie des DSN qui vont être modifié au premier step TITI quand le job s'exécute automatiquement et si relance manuelle, remplacer ce step TITI de copie par le step TOTO de restauration de DSN qui écraserait le DSN modifié par le DSN sauvegardé. Nous pourrions ainsi reprendre le traitement au job en erreur avec les DSN de données dans leurs états initiales.

Start AUTO : Step Début (TITI) => Initialisation et copie du DSN
Ou
Start Manuel : Step Début (TOTO) => Remplacement du DSN par la copie

step de traitement des données => Modification et actualisation du DSN
Step de FIN

Ce principe de copie et remplace est compliqué à mettre en œuvre?

[Lemmings1406]

Re,

Déjà, il suffira de mettre RESTART=N et le job restera en erreur et pourra donc être repris manuellement plus tard.

Pour la substitution de jcl, de nombreuses possibilités sont offerte par RECOVER et il faudrait se plonger dans la doc (qui n'est pas non plus monstrueuse) et faire des essais pour trouver le "bon réglage".
Il faut être très prudent avec l'utilisation de cette fonction et surtout bien la paramétrer.
Ceci-dit, ce que vous voulez faire me parait réalisable assez facilement si vous n'avez pas multitude de fichiers modifiés dans votre job et dans des étapes différents mais je ne vois pas trop l'utilité. Pourquoi ne pas faire une sauvegarde de l'ensemble des fichiers modifiés juste avant passage du job puis de mettre des OI (Operator instructions) pour indiquer les conditions de reprise sur incidents?

[letophe44]

Bonjour,
Nous n'avons pas un grand nombre de fichier en modification dans nos jobs, entre 1 à 10 fichiers suivant les jobs. Je ne saurais dire quelle est la solution la plus simple entre les "OPC Recover" et le "Opérator Instructions" car j'avais juste connaissance de la première solution que j'ai d'ailleurs testée sur un JCL tout simple mais j'ai quelques difficultés.
Si mon JCL plante, malgré le restart à "Yes", il ne fait pas la relance automatique et effectivement, en consultant le JCL en 5.2, je remarque qu'il a bien supprimé le STEP "S010" que j'avais mis dans les paramètres et exécute bien les deux STEP S015 et S020 quand je le relance manuellement.

//*****************************************
//*%OPC BEGIN ACTION=INCLUDE
//*>OPC RECOVER STEPCODE=(*,9-4095),DELSTEP=S010,
//*%OPC ADDPROC=(S015,S020),RESTART=Y
//S010
//
//S015
//
//S020
//
//*%OPC END ACTION=INCLUDE
//*****************************************
Par contre, si je supprime la cause de l'erreur qui est un step de création de fichier qui existe déjà (duplicate existe) en faisant un delete en début de JCL,

//S005 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=R
//SYSIN DD *
// DELETE MDRT.RP.B01.TEST.CPTRE.KIN
// DELETE MDRT.SS.B01.TEST.FCOMM
// IF MAXCC = 8 THEN SET MAXCC = 0

L'OPC Recover se lance aussi en exécutant les trois STEP (S010; S015 et S020). Il y a surement quelques choses que je n'ai pas compris mais là encore, je ne trouve pas.
J'ai ajouté le BEGIN et End action mais peut-être pas au bonne endroit.
Concernant les OI, je connais encore moins et malgré mes recherches dans les docs http://www.mainframegurukul.com/ibm/manuals.php, je n'ai pas trouvé d'aide sur ses deux solution.

[letophe44]

J'ai oublié de préciser que j'avais fait un test avec cette organisation ci-dessous en mettant le begin après l'appel de l'OPC Recover.
//*****************************************
//*>OPC RECOVER STEPCODE=(*,9-4095),DELSTEP=S010,
//*%OPC ADDPROC=(S015,S020),RESTART=Y
//S010
//
//*%OPC BEGIN ACTION=INCLUDE
//S015
//
//S020
//
//*%OPC END ACTION=INCLUDE
//*****************************************

Merci pour le temps que vous consacrez pour aider les novices comme moi.
Bon courage à vous tous

[letophe44]

encore moi, je crois que j'ai mis le doigt sur un premier problème. Dite moi si je suis sur la piste. Il semble que les ADDPROC soient créés dans une bibliothèque particulière connu par OPC. J'ai fait une recherche dans ce sens mais je ne trouve pas où ces PROC peuvent être créés

[letophe44]

J'ai retrouvé la bibliothèque OPC.
Concerant les OI, est-ce vraiment plus simple à mettre en oeuvre que les recovery?

[Lemmings1406]

Désolé pour la réponse tardive. Les OI et RECOVER n'ont pas du tout la même utilité. Cependant, je trouve les OIs très utile et facile à mettre en oeuvre. Cela permet très rapidement de savoir quelles actions sont à entreprendre en cas d'incident. Ils sont accessibles directement en 5.4 sous tws en tapant O devant un job planté.

[letophe44]

Bonjour et merci pour votre retour. Retard de ma réponse aussi, de retour de vacance!!!
Les OI seraient effectivement plus simple mais le choix de l'équipe système se porte sur l'utilisation des OPC-recovers. J'attend d'avoir les droits d'accès pour créer les proc de reprise dans la bib d'OPC pour pouvoir effectuer mes premier test. Je reprendrais sans doute ces échanges avec vous car j'aurais surment d'autres questions.
Merci encore pour vos bon conseils. bon courage à vous