Discussion :

[fspiecart]

Bonjour,
je voudrais qu'un programme s'exécute toutes les heures. Y at-il un moyen de le faire ?
Merci

[FORMULARY]

Ca n'est pas un "never ending program" mais un programme qui se lance toutes les heures. Ce n'est pas tout à fait la même chose.

1) On peut acheter Advanced job Scheduler chez IBM qui permet de lancer un travail plusieurs fois par jour (entre autre ! )

2) On peut créer 8 taches dans le job scheduler qui lancent le même programme mais chacune à son heure.

3) On peut lancer un CLP le matin qui effectue un DLYJOB d'une heure, lance le programme, puis tourne en boucle.

4) Il y a surement une autre possibilité à laquelle je n'ai pas encore pensé.

[K2R400]

Il suffit simplement que le programme se REsoumette lui même après son execution (juste avant le RETURN). Il calcule la prochaine heure/date et fais un SBMJOB (ne pas "câbler en dur" le délai dans le programme pour plus de souplesse) avec les mots clés SCDDATE & SCDTIME de la commande SBMJOB.
Pour le tout début, son lancement "initial" peut être schédulé ou il peut être considéré comme un travail anticipé (au démarrage d'un sous système)

[m4k-Hurrican]

Je suivrais presque la même méthode que K2R400, mais personnellement je patienterai dans le programme soumis à l'aide d'un RCVMSG MSGQ(&MSGQ) WAIT(&DLYTIM). Avec la variable DLYTIM récupérée dans une DTAARA par exemple.
L'avantage avec cette méthode c'est que le RCVMSG peut être déclenché instantanément en envoyant un message à la file d'attente concernée. Ce message peut être une demande d'exécution immédiate, ou une demande d'arrêt par exemple.
Avoir un job bloqué en file d'attente de travaux n'est, à mon avis, jamais bon, il peut se lancer à tout moment (pendant un traitement sensible par exemple), et l'arrêter devient plus problématique (il faut retrouver le job dans la file d'attente).

[K2R400]

Avoir un job bloqué en file d'attente de travaux n'est, à mon avis, jamais bon, il peut se lancer à tout moment (pendant un traitement sensible par exemple), et l'arrêter devient plus problématique (il faut retrouver le job dans la file d'attente).

Euuh, je ne vois pas comment.
Un job en attente SCD ne va pas se lancer tout seul.
Pour le libérer, il faut le modifier et en mettre SCDTIME à *CURRENT.
Et on peut imaginer une JOBQ (à entrée multiple) dédiée à cet effet.

[m4k-Hurrican]

Je ne parlais pas du job quand il est dans le planning, mais une fois lancé.
Tu proposes que le programme se soumette lui même et utilise les paramètres SCDDATE & SCDTIME. Il va donc être en quasi permanence dans la file d'attente de travaux, à attendre que l'horaire indiqué arrive.
J'avoue que moi, le job une fois lancé, je ne le soumettrai pas à nouveau. Dans les quelques applis que j'ai développé et qui tournent selon ce modèle, le programme reboucle sur le RCVMSG jusqu'à ce qu'on lui demande de s'arrêter, simplement.

[Mercure]

Les jobs soumis selon la méthode indiquée par K2R400 peuvent parfois ne jamais être exécutés. J'ai eu le cas.

Il s'agissait de jobs soumis par un client ODBC avec peu de décalage entre le lancement de la soumission et le démarrage de l'exécution en batch, de l'ordre de qq minutes. Entre les PC client et le serveur AS400, les clocks n'étaient pas synchronisées et la clock client était en retard par rapport à la clock serveur si bien que certains jobs restaient indéfinément en file d'attente

[K2R400]

Les jobs soumis selon la méthode indiquée par K2R400 peuvent parfois ne jamais être exécutés. J'ai eu le cas.

Il s'agissait de jobs soumis par un client ODBC avec peu de décalage entre le lancement de la soumission et le démarrage de l'exécution en batch, de l'ordre de qq minutes. Entre les PC client et le serveur AS400, les clocks n'étaient pas synchronisées et la clock client était en retard par rapport à la clock serveur si bien que certains jobs restaient indéfinément en file d'attente

Ce n'est pas du tout le cas dans ce post, pas de lancement depuis ODBC et de plus "in the real world", c'est à dire en entreprise, on est tous basés sur un ou plusieurs serveurs SNTP

[Mercure]

Je ne dis pas que la méthode que tu proposes est mauvaise, je rapporte simplement ce qui m'est arrivé, c'est tout. Je suis aussi le premier à l'utiliser si besoin est.

Mais, ce qui m'est arrivé, c'est dans le "real world" en entreprise.

[K2R400]

Je ne dis pas que la méthode que tu proposes est mauvaise, je rapporte simplement ce qui m'est arrivé, c'est tout. Je suis aussi le premier à l'utiliser si besoin est.

Mais, ce qui m'est arrivé, c'est dans le "real world" en entreprise.

Il n'y a jamais de bonne ou de mauvaises solutions, tout dépend du contexte, chaque projet étant unique.
Le but d'un forum est justement de proposer plusieurs solutions à un même problème, et en fonction du contexte on choisira l'une ou l'autre.

Ce que je proposais est simple, rapide à mettre en oeuvre et basé sur le scéduler interne du système. Ce n'est pas un travail ACTIF qui attend une action, mais un job schédulé qui ne prend aucune ressource, qui ne bloque pas la JOBQ et qui sera lancé automatiquement par le système.
Maintenant si l'utilisateur planifie le travail à la date d'hier c'est autre chose.
Mais ce que je suis certain, c'est que l'OS lancera bien le job à l'heure et à la date prévue et sans retard.