Nun ja, wenn ein Lese-Trigger auch noch schreiben muss, wird auch eine DTAQ nicht so wirklich viel helfen.
Da Daten sehr häufig auch unsinnig gelesen werden (Selektion per Programm und nicht per SQL) ergibt sich zwangsläufig ein hohes Datenaufkommen.

Auch ist die Auswertung ggf. an der Realität vorbei da eben auch Daten gelesen werden, die ggf. der User gar nicht sieht (eben programmintern).

Du kannst sicherlich die Daten in eine DTAQ schieben, wobei diese auf 16MB beschränkt ist. Wenn also das abnehmende Programm nicht schnell genug ausliest, läuft die DTAQ voll und der QSNDDTAQ bricht mit Fehler ab.

Dem kann man entgegenwirken, wenn genug abnehmende Programme die DTAQ auslesen.

Das zu erwartende Datenaufkommen kann gewaltig werden und dein System schnell über 90% bringen !!!

PS:
Das Schreiben in eine DTAQ kann ggf. langsamer sein als das Schreiben in eine Datei.
Der QSNDDTAQ muss nämlich die DTAQ immer erst mal suchen (vielleicht optimiert er das ja intern), wobei die Zieldatei ja bereits geöffnet ist.
Performancegewinn ergibt sich ggf. bei der PF mit FRCRATIO(*NONE).