Page 1 sur 1

data queue

Posté : lun. 24 juin 2019, 08:50:27
par 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

(sans sujet)

Posté : lun. 24 juin 2019, 08:56:59
par 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.

DTAQ

Posté : lun. 24 juin 2019, 09:21:04
par 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)

(sans sujet)

Posté : lun. 24 juin 2019, 11:17:56
par 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

(sans sujet)

Posté : lun. 24 juin 2019, 11:20:39
par Nicolas.MAZO
et surtout consommer les messages au fil de l'eau car la message queue est une zone de transit pas de stockage.

(sans sujet)

Posté : lun. 24 juin 2019, 11:54:17
par 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 ?

DTAQ

Posté : lun. 24 juin 2019, 12:09:35
par 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.

(sans sujet)

Posté : lun. 24 juin 2019, 12:24:59
par karine Gourmelon
d'accord, merci -)

(sans sujet)

Posté : mar. 25 juin 2019, 07:44:41
par 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.

(sans sujet)

Posté : mar. 25 juin 2019, 08:11:38
par 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