Tivoli Workload Automation version 9.2

Dépendances de condition

Dans Tivoli Workload Scheduler for z/OS, vous pouvez indiquer les travaux qui dépendent d'autres travaux. Par exemple, si le travail A1 doit être terminé avant que le travail A2 ne commence, alors A1 est un prédécesseur de A2, et A2 est un successeur de A1. Ces relations entre les travaux sont appelées dépendances.

Lorsque vous indiquez des dépendances, vous pouvez également définir les flux de travaux dotés de branches alternatives en fonction de conditions, destinées spécifiquement à obtenir les mêmes résultats que lors de l'utilisation des instructions IF/THEN/ELSE dans le langage de contrôle des travaux (JCL). Vous pouvez utiliser le code retour et le statut du travail comme éléments de logique conditionnelle afin de déterminer le début d'un travail successeur. L'exemple suivant illustre le fonctionnement de ces dépendances.

Une relation de dépendance de condition se configure en utilisant une condition.

Vous pouvez définir des dépendances de condition aux niveaux suivants :

Niveau d'un travail: En conditionnant le démarrage du travail successeur à la vérification du code retour du travail ou du statut du travail prédécesseur.
Niveau d'une étape: En conditionnant le début du travail successeur au code retour d'une étape spécifique du travail prédécesseur.

Fonctionnement des dépendances de condition

Une dépendance de condition est une vérification spécifique du statut ou du code retour d'un travail prédécesseur ou du code retour d'une étape du travail.

Le flux de traitement de travaux est affecté par l'ensemble des conditions et leur statut final.

Le statut d'une condition est défini selon la règle définie et selon les statuts de ses dépendances de condition.

La dépendance de condition est évaluée uniquement lorsqu'un chemin existe dans le plan, sinon la dépendance de condition reste Non définie jusqu'à ce qu'une intervention manuelle ou qu'un redémarrage soit effectué(e).

Un chemin possible existe pour le prédécesseur conditionnel lorsqu'au moins une des conditions suivantes est satisfaite :

Le travail a le statut Terminé et un successeur normal existe.
Il existe au moins un successeur conditionnel qui possède tous les sous-ensembles de conditions référençant ce prédécesseur conditionnel par true, en fonction des règles de condition.

Par exemple :

Un prédécesseur conditionnel (Travail A) possède plusieurs successeurs conditionnels (travaux B, C, D)
Chaque successeur conditionnel possède un ensemble de dépendances de condition, liées au travail A, qui doivent être satisfaites pour que le successeur puisse démarrer.
Le travail A s'exécute et son état change.
Si au moins un sous-ensemble de conditions entre le travail A et l'un de ses successeurs est défini sur true, le chemin du plan existe et toutes les dépendances de condition du successeur associées au travail A sont évaluées. Autrement, toutes les dépendances de condition restent non définies.

Lorsque vous indiquez des prédécesseurs dans la base de données, vous pouvez définir une liste de conditions en combinant des dépendances de condition uniques avec le statut ou le code retour du travail prédécesseur. Vous ne pouvez pas définir un travail comme étant à la fois conditionnel et prédécesseur normal d'un autre travail. Pour chaque condition, vous pouvez indiquer l'une des règles suivantes :

Au moins n conditions doivent être satisfaites sur l'ensemble des dépendances de condition. Cette règle correspond à l'opérateur OR de la logique booléenne.
Toutes les dépendances de condition de la liste doivent être satisfaites. Cette règle correspond à l'opérateur AND de la logique booléenne.

Lors de l'exécution, le planificateur évalue le statut de la condition résultant des statuts des dépendances de condition, en fonction de la règle sélectionnée. Le statut de condition peut être le suivant :

Vrai

Lorsque toutes les dépendances de condition sont vraies.

Si la règle est définie sur AND: Lorsque toutes les dépendances de condition sont vraies.
Si la règle est définie sur OR (au moins n dépendances de conditions doivent être vraies): Lorsqu'au moins n dépendances de condition sont vraies.

Faux

La condition n'a pas été satisfaite.

Si la règle est définie sur AND: Lorsqu'au moins une dépendance de condition est fausse.
Si la règle est définie sur OR (au moins n dépendances de conditions doivent être vraies): Lorsqu'au moins n dépendances de condition ne peuvent être vraies.

Non défini

Lorsque la règle ne peut pas encore être évaluée.

Un ensemble de conditions prend la valeur satisfait si toutes les conditions sont définies sur satisfait, selon la logique de l'opérateur AND.

Lorsqu'un prédécesseur se termine, le statut du travail successeur prend l'une des valeurs suivantes :

En attente: Non défini, jusqu'à ce que le planificateur évalue toutes les conditions définies. Au moins un prédécesseur normal n'a pas l'état Terminé ou Supprimé par la condition ou au moins une condition est définie sur U (Undefined, non défini). Le planificateur traite tous les statuts ultérieurs de la manière habituelle jusqu'au statut final.
Prêt: Prêt, lorsque toutes les conditions définies sont satisfaites (satisfied). Les prédécesseurs normaux ont le statut Terminé ou Supprimé par la condition et toutes ses conditions ont le statut True. Le planificateur traite tous les statuts ultérieurs de la manière habituelle jusqu'au statut final.
Supprimé par condition: Supprimé par condition, lorsque la dépendance de condition définie n'est pas satisfaite. Au moins une condition est False (Fausse).
Remarque : Lors de l'évaluation du statut des successeurs conditionnels, les travaux prédécesseurs à l'état Supprimé par la condition sont considérés comme égaux aux opérations de prédécesseur de statut Completed (Terminé).

Exemples de dépendances de condition

Utilisez une dépendance de condition de niveau travail lorsque vous voulez qu'un travail successeur démarre en fonction d'une combinaison d'un ou plusieurs codes retour ou statuts de travaux prédécesseurs.

La Figure 1 présente les deux types de conditions au niveau d'un travail, l'une étant basée sur le code retour du prédécesseur et l'autre sur le statut du travail prédécesseur. Par exemple, en utilisant le code retour comme type de condition, vous pouvez définir que le travail OP2 dépend du travail OP1, en indiquant qu'il doit s'exécuter lorsque le travail OP1 se termine avec un code retour compris entre 1 et 3. De même, en utilisant le statut du travail comme condition, vous pouvez définir que le travail OP4 dépend du travail OP3, en indiquant qu'il doit s'exécuter lorsque le travail OP3 se termine avec le statut Error (Erreur).

Figure 1. Exemple de définition de dépendance de condition

Dans l'exemple suivant, OP1 est un prédécesseur conditionnel d'OP2 et OP3 est un prédécesseur conditionnel d'OP4.

Dans l'exemple précédent, si OP1 se termine par le code retour 8, le planificateur considère OP2 comme Supprimé par condition, car la condition est elle-même définie sur non satisfait.

Figure 2. Exemple de dépendance de condition en phase d'exécution

Dépendance de condition au moment de l'exécution

Pour plus d'informations sur la logique conditionnelle, voir Tivoli Workload Scheduler for z/OS - Gestion de la charge de travail.

Dépendance au niveau d'une étape

Si vous avez configuré Tivoli Workload Scheduler for z/OS pour suivre les événements de fin d'étape, les dépendances d'étape sont alors vérifiées au moment de la fin d'étape lorsque la valeur du code retour est disponible.

Cette section contient un exemple illustrant comment le flux de traitement du travail est affecté lors de l'utilisation de conditions de niveau d'étape.

Si le travail prédécesseur est associé à un travail comportant plusieurs étapes, vous pouvez indiquer une dépendance sur les codes retour d'une étape. La Figure 3 présente un exemple de logique de dépendance conditionnelle au niveau d'une étape de travail, qui permet d'obtenir des applications à reprise automatique, dotées de travaux de reprise pouvant démarrer avant la fin des travaux prédécesseurs, en fonction du résultat de certaines étapes spécifiques.

Figure 3. Flot de travaux à reprise automatique avec dépendance au niveau d'une étape

Dans cet exemple :

JOBB peut démarrer si STEP100, appartenant à JOBA, se termine avec RC=4.
JOBC est un successeur normal de JOBA et démarre par conséquent si le statut de JOBA est Completed (Terminé).

Gestion de la reprise utilisant des dépendances de condition

A l'aide des dépendances de condition, le statut d'erreur d'un travail peut être utilisé comme critère pour le démarrage d'un successeur, lorsque ce dernier est utilisé en tant que travail de reprise.

En spécifiant l'option de travail de reprise conditionnel, vous pouvez définir que le travail est utilisé en tant que travail de reprise pour un prédécesseur conditionnel.

Tout prédécesseur conditionnel se terminant par une erreur, avec un statut ou un code d'erreur qui correspond à une dépendance de condition définie pour le travail, n'empêche pas le processus de plan quotidien de supprimer l'occurrence à laquelle appartient le prédécesseur. Pour vérifier si le statut Ended-in-error (terminé par une erreur) peut être ignoré lors de la phase de suppression de l'occurrence, le processus de plan quotidien utilise une zone définie automatiquement par le planificateur, correspondant au statut Récupéré par condition.

Remarque : Dès que le travail de reprise devient près, le planificateur vérifie les prédécesseurs en état d'erreur à ce stade. Tout prédécesseur qui se termine en erreur après l'exécution du travail de reprise ne peut pas être signalé comme Récupéré par condition. Le processus de planification quotidien supprime l'occurrence dans les cas suivants :

Le statut de l'occurrence est Completed (Terminé).
Le statut de l'occurrence est Ended-in-error (Terminé avec erreur), et inclut uniquement les travaux à l'un des statuts suivants :
- Terminé
- Supprimé par condition
- Ended-in-error (Terminé avec erreur) avec l'option Récupéré par condition spécifiée.

Par exemple, supposons que JOBR1 ou JOBR2 doit être exécuté lorsque JOBB se termine par une erreur. Vous pouvez désigner JOBB comme leur prédécesseur conditionnel, comme indiqué à la Figure 4.

Figure 4. Exemple de travail de reprise avec des dépendances de condition

Lorsque vous définissez JOBR1 and JOBR2 et que vous désignez JOBB comme prédécesseur conditionnel, vous pouvez également définir l'option Travail de reprise conditionnel pour que la processus de plan quotidien supprime l'occurrence contenant JOBB, car elle s'est terminée avec un code d'erreur correspondant à l'une des dépendances de condition définies.