As400, iSeries, i5, System i, une machine qui évolue pour être de plus en plus puissante.
Vous n'êtes pas identifié.
Pages: 1
Discussion fermée
Bonjour,
Je m'explique (je n'était pas inspiré pour un titre plus parlant et plus simple
)
Nous avons un CL qui nous sert de lanceur pour une application EDI.
Toutes les x minutes le programme tourne et appelle toute une chaine de programme EDI.
Ce programme est lancé par WRKJOBSCDE le matin à 8H00 et reste actif toute la journée.
les délais d'attente étant gérés par une boucle et un DLYJOB DLY(xxx). A une heure donnée on débranche vers le ENDPGM pour terminer le programme.
Ça vaut ce que ça vaut mais ça fonctionne comme on veut.
Le seul point négatif de cette méthode est que si pour une raison ou pour une autre on veut forcer le déclenchement du programme avant le délai prévu on est coincé.
Connaissez vous une autre méthode qui fonctionnerait à l'identique mais qui permettrai de sortir de l'attente à la demande (et surtout qui ne consommerai pas trop de CPU) ?
Merci
Laurent
P.S c'est pas urgent je suis en vacance la semaine prochaine ![]()
Dernière modification par macounet (2009-05-04 11:05:05)
Hors ligne
Met ton programme en attente mais plutôt avec RCVMSG...
Si un message arrive, le déclenchement est instantané. Ce message peut être une demande de fin, etc...
En plus, comme il verrouille la file d'attente de messages, il est aisé de vérifier qu'il est déjà lancé, et donc d'éviter les doublons.
Hors ligne
Hurrican a écrit:
Met ton programme en attente mais plutôt avec RCVMSG...
Intéressant.
Et qu'est-ce qui envoi le message au programme à intervalle régulier ? Un autre CL avec un DLYJOB ?
Tu aurais un exemple d'application pour le RCVMSG ?
Merci
Laurent
Hors ligne
Hurrican a raison.
Tu créés une MSGQ, tu la mets en *BREAK avec programme d'interruption (ton CLP qui lance l'EDI). Il sera appelé automatiquement à l'arrivée d'un message.
C'est un autre CLP qui devient schedulé avec son DLYJOB, toutes les x minutes il envoi un message dans cette MSGQ.
Ainsi, quand tu veux forcer, tu envoies un message dans la MSGQ.
CQFD
Dernière modification par k2r400 (2009-04-24 17:13:17)
Hors ligne
Tiens voilà le code d'un programme que j'utilisais pour vérifier toutes les x secondes s'il y avait des documents mails ou faxs à transmettre (maintenant j'utilise un RPG Ile avec une DataQueue, et le programme attend simplement une entrée...).
Je te le mets "brut", tu feras le tri...
PGM
DCL VAR(&MSG) TYPE(*CHAR) LEN(512)
DCL VAR(&TIMA) TYPE(*CHAR) LEN(3)
DCL VAR(&TIMN) TYPE(*DEC) LEN(3 0)
/* Crée la file d'attente de message si elle n'existe pas */
CRTMSGQ MSGQ(EUROFOUTIL/ALBEMIMSG) TEXT('File attente +
messages gestionnaire fax/mail')
MONMSG MSGID(CPF0000)
/* Tente d'allouer la file d'attente */
ALCOBJ OBJ((EUROFOUTIL/ALBEMIMSG *MSGQ *EXCL)) WAIT(2)
/* Le programme est déjà lancé ! */
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(THEEND))
/* Vide la file d'attente au cas où des demandes d'arrêt y seraient encore */
CLRMSGQ MSGQ(EUROFOUTIL/ALBEMIMSG)
MONMSG MSGID(CPF0000)
/* Récupère la fréquence d'activation en secondes */
RTVDTAARA DTAARA(PARDTA (4 3)) RTNVAR(&TIMA)
CHGVAR VAR(&TIMN) VALUE(&TIMA)
/* Valeur non numérique => valeur par défaut de 60 secondes */
MONMSG MSGID(CPF0000) EXEC(CHGVAR VAR(&TIMN) VALUE(60))
/* Partage les fichiers communs pour éviter les ouvertures/fermetures */
OVRDBF FILE(SOCIET) SHARE(*YES)
OVRDBF FILE(MAILSE) SHARE(*YES)
OVRDBF FILE(FAXSE) SHARE(*YES)
/* Boucle d'appel du programme d'émission. Appel toutes les &TIMN secondes */
LOOP:
CALL PGM(EMI001)
MONMSG MSGID(CPF0000 RPG0000) EXEC(DO)
SNDPGMMSG MSG('Erreur lors de l''éxécution du +
programme de traitement des émissions +
fax/mail. Veuillez contacter la +
maintenance logicielle.') TOPGMQ(*EXT) +
MSGTYPE(*DIAG)
ENDDO
/* A t'on reçu un message ? Si non mise en sommeil du programme */
RCVMSG MSGQ(EUROFOUTIL/ALBEMIMSG) WAIT(&TIMN) MSG(&MSG)
IF COND(&MSG = 'END') THEN(DO)
GOTO CMDLBL(THEEND)
ENDDO
GOTO CMDLBL(LOOP)
THEEND:
ENDPGM
Hors ligne
macounet a écrit:
Et qu'est-ce qui envoi le message au programme à intervalle régulier ? Un autre CL avec un DLYJOB ?
pas la peine, RCVMSG a un paramètre WAIT qui est le temps d'attente en secondes d'un nouveau message : ça fait l'équivalent du DLYJOB, sauf que si un message arrive (KEYVAR <> blanc) tu le récupère et tu le traites.
J'utilise fréquement cette technique qui est simple à mettre en oeuvre (plus que les DTAQ) et souple car on peut intervenir facilement sur le programme en attente simplement en envoyant un message !
Le seul inconvénient (AMHA) de cette technique , c'est que le job apparait en MSGW dans les travaux actifs ![]()
Hors ligne
Laurent,
Pour ajouter mon grain de sel, c'est également cette dernière méthode que je suivrais.
Le programme CL qui contient la commande "RCVMSG WAIT(x)" se déclenche automatiquement dès la réception d'un message quelconque. Tu n'as plus qu'à tester le contenu de ce message et si le message contient par ex. "EDI", tu appelles l'application EDI puis tu boucles en retour sur le RCVMSG. S'il contient "FIN", tu arrêtes le traitement de ce programme. It is that simple !
Comme te le dit k2r400, c'est un autre CL planifié en amont qui fait le DLYJOB et, à l'expiration de ce délai, envoie le message "EDI" à la MSGQ que tu as déclarée dans le RCVMSG. Pour terminer à un moment quelconque de la journée, une simple commande SNDMSG passée "à la main" contenant "FIN" dans son message est alors suffisante pour arrêter les 2 programmes CL.
Bonnes vacances.
Hors ligne
Merci à tous.
Si avec tout ça je ne m'en sort pas c'est vraiment qu'il faut que je change de métier ![]()
Je test ça à mon retour de vacances et comme on dit dans ch'nord "j'vous dit quoi" ![]()
Hors ligne
Philippe a écrit:
Le programme CL qui contient la commande "RCVMSG WAIT(x)" se déclenche automatiquement dès la réception d'un message quelconque. Tu n'as plus qu'à tester le contenu de ce message et si le message contient par ex. "EDI", tu appelles l'application EDI puis tu boucles en retour sur le RCVMSG. S'il contient "FIN", tu arrêtes le traitement de ce programme. It is that simple !
Comme te le dit k2r400, c'est un autre CL planifié en amont qui fait le DLYJOB et, à l'expiration de ce délai, envoie le message "EDI" à la MSGQ que tu as déclarée dans le RCVMSG. Pour terminer à un moment quelconque de la journée, une simple commande SNDMSG passée "à la main" contenant "FIN" dans son message est alors suffisante pour arrêter les 2 programmes CL.
Bah, moi je lancerai le programme EDI par défaut à chaque fois que la commande RCVMSG va atteindre le fameux délai (ce que je fais dans mon exemple). Cà évite de rajouter un programme pour rien. ![]()
Quant à l'arrêt, un petit CL qui fait le SNDMSG c'est mieux qu'à la main (voire une commande).
Et si en plus on le lance à heures fixes via la planification des tâches, comme le lancement du programme de traitement d'ailleurs, on a plus rien à faire (sauf en cas d'arrêt du serveur dans la journée, dans ce cas, rajouter le lancement dans le programme Startup) !
Dernière modification par Hurrican (2009-04-25 10:31:40)
Hors ligne
hurrican a écrit:
Cà évite de rajouter un programme pour rien. Quant à l'arrêt, un petit CL qui fait le SNDMSG c'est mieux qu'à la main.
Pour rien et mieux, c'est ton avis et pas le mien, monsieur le suffisant donneur de leçons.
Moi, je préfère et de loin utiliser un CL pour avoir la possibilité de reprendre la main en vue de modifs/améliorations ultérieures et à l'usage, je me suis souvent rendu compte que j'avais eu raison de le faire.
Et un SNDMSG "à la main", m'évite un CL inutile.
Je n'ai fait que donner ici une orientation, une marche à suivre à Laurent pour appuyer le post de k2r400. Laurent décidera de toutes façons de ce qui lui convient le mieux.
Hors ligne
Philippe a écrit:
Pour rien et mieux, c'est ton avis et pas le mien, monsieur le suffisant donneur de leçons.
Merci, çà fait plaisir... ![]()
Tu ne me retireras pas de la tête qu'un programme, lancé automatiquement pour gérer les arrêts est mieux qu'un SNDMSG lancé à la main. Non seulement on évite les "oublis", mais on évite du travail idiot à l'utilisateur final. De même que le démarrage planifié. Je ne sais pas si tu as lu le 1er post, mais cet arrêt/démarrage est quotidien !
Quant à ton programme qui fait le DLYJOB, je ne vois aucun intérêt, excuses moi, mais pour la simple est bonne raison que le RCVMSG fait déjà le boulot du DLYJOB ! Pourquoi rajouter une attente, alors qu'elle est déjà faite ? Je suis pour le découpage des tâches mais là, c'est de la multiplication.
Hors ligne
Bonsoir à tous,
Histoire de pimenter encure un peu plus le débat, j'utilise pour ma part les DTAQ pour traiter le problème des programmes à l'écoute.
Les APIs QSNDDTAQ et QRCVDTAQ pour ne pas les citer.
FRED
Hors ligne
Bonjour tout le monde.
Faut pas vous battre ! Les gouts et les couleurs ... l'important c'est d'apporter sa pierre à l'édifice et c'est ce que vous faites (très bien) tous les deux.
Sinon je viens de tester la solution de Hurrican et ça me convient parfaitement.
Ce que je voulais c'est pouvoir forcer manuellement le lancement de mes progs EDI donc je vais ajouter le test sur la valeur du message pour
rentrer dans la boucle et quand j'en aurai besoin j'envoi un message à la file d'attente sinon je laisse le délai s'écouler et ça marche comme "avant".
Pour ma culture personnelle je vais aussi me documenter sur les dataq (ça va peut-être me servir pour un autre problème). J'avoue que la aussi je n'y connais pas grand chose !
Merci
Laurent
Hors ligne
Discussion fermée
Pages: 1