data queue

[karine Gourmelon]

Bonjour,

si vous avez un peu de temps, je souhaiterais votre avis concernant l'utilisation d'une Dtaq.

Quand j'ai eu l'occasion de travailler avec des dtaq, elle servaient à envoyer des enregistrements en intéractif d'un As400 vers un autre As400. Tout se passait bien.

Je suis aujourd'hui confrontée à un cas d'utilisation particulier : les utilisateurs modifient en masse un fichier (80 000 enregistrements) sur lequel pointe un trigger. Ce trigger envoie l'info vers une dtaq et au final reçoit un "CPF950A Echappement" ayant pour cause "Limite mémoire dépassée pour file d'attente de données".

Ma préconisation est de remplacer le traitement trigger/dtaq par des écritures dans un fichier et traitement batch de ce fichier. Qu'en pensez vous ? L'utilisation de dtaq pour du batch est elle possible ?

merci, bonne journée

[Nicolas.MAZO]

Bonjour,
Si vous n’êtes pas encore à la taille max de la dtaq vous pouvez peut etre l'augmenter ? Ce qui ne fait que repousser le problème mais peut permettre d'attendre une évolution.

[cmasse]

Le problème c'est que , historiquement, les DTAQ ne récupéraient pas la place des enregistrements supprimés(comme les fichiers) mais ne possèdent pas de commande RGZDTAQ.

il faut la détruire et la recréer avec le nouveau paramètre AUTORCL(*YES)

[Nicolas.MAZO]

Si je fais le parallèle avec les message queue que je pratique plus l'idée est de :
- surveiller la taille message queue (fait par nagios)
- monitorer l'erreur d’écriture (put) en cas de taille dépassée et de sauvegarder l'information à écrire (dans notre cas on écrit une log)
- être prévenu du problème : écrire inquiry message dans qsysopr

[Nicolas.MAZO]

et surtout consommer les messages au fil de l'eau car la message queue est une zone de transit pas de stockage.

[karine Gourmelon]

Je vous remercie de vos réponses.

Quand il y a potentiellement de nombreux enregistrements et aucun impératif de temps, autant remplacer la dtaq par un traitement batch traditionnel, non ?

[cmasse]

C'est pas tout à fait le même service, la DTAQ intègre :

- le fait de détruire automatiquement à la lecture
- le fait d'être en attente (paramétrable ou indéfini) si elle est vide.

[karine Gourmelon]

d'accord, merci -)

[eric.lebrun]

Bonjour,

pour ce genre de traitement, nous utilisons un PF.
Il est traité par un programme qui se met "en attente" grâce à la commande :
OVRDBF FILE(xxxxxxxxxx) EOFDLY(5)

Celle-ci est exécutée par un CLP, juste avant l'appel du programme RPG qui traite les enregistrements au fil de l'eau. Celui-ci contient une boucle "tant que" de lecture sur le fichier xxxxxxxx.
Contrairement à la DTAQ, il faut supprimer le record une fois traité.

Le CLP est bien sûr déclenché par un poste de travail à démarrage automatique.

[karine Gourmelon]

Bonjour,

oui, c'est exactement la solution que nous préconisons en remplacement du trigger/dtaq

merci de votre réponse, bonne journée