SQL QSYS2.MESSAGE_QUEUE_INFO MSGKEY

[Fuerchau]

Eine Antwortnachricht wird mit dem Message-Key der INQ-Nachricht beantwortet.
Also müsste man da mal die eigentliche Antwort-Nachricht untersuchen, ob da der MSG-Key zur INQ-Nachricht irgendwo enthalten ist um dann per per Exception-Join die beantworteten Nachrichten wieder auszuschließen.
Nur so als Idee...

[itec01]

Ja, das würde ich dann machen, wenn es nicht per SQL auszuschließen geht. Ist aber halt sehr umständlich. Vermutlich werden die Messages in die View getriggert, wenn sie entstehen, aber es gibt dann leider kein update trigger mehr für die messages.

[Fuerchau]

Die Views sind nur Table-Functions auf die API's, da MSGQ's nicht per SQL abfragbar sind.
Um aber dem iDerector (oder so) die Möglichkeit zu geben alles per SQL zu machen, werden viele API's als SQL-Wrapper bereitgestellt.
Also jedes mal, wenn du die Table-Function aufrufst (indirekt über die View) wird das API erneut ausgeführt. Das hat nichts mit Trigger zu tun.
Ob da nun alle Inhalte angezeigt werden, die auch per API erreichbar wären musst du dann mal prüfen.
Z.B.:
select * from
TABLE(QSYS2.MESSAGE_QUEUE_INFO('QSYS', 'QSYSOPR'))

ggf. ist "ASSOCIATED_MESSAGE_KEY" dein Freund.
Hat eine INQ-Nachricht bereits einen ASSOCIATED_MESSAGE_KEY wäre dieser Key ggf. die Antwort-Nachricht.

[Fuerchau]

"ASSOCIATED_MESSAGE_KEY" ist es leider nicht.
Das API als Alternative findest duz hier:
https://www.ibm.com/support/knowledg...is/QMHLSTM.htm
Da gibt's z.B. das Feld "

Reply Status".
Schau einfach mal selber.

[harkne]

Ich hab aber auch das Problem wie zuvor schon mehrmals erwähnt. Es funktioniert bei mir dass ich den 4-stelligen Hexwert als MSGKEY in SNDRPY verwende. Allerdings schließe ich den Wert in "'" ein, also MSGKEY('xxxx'). Die xxxx sind nicht lesbare Zeichen. Jetzt hatte ich aber das Problem, dass genau eines der xxxx nämlich die vorletzte Stelle der hex-Wert von ' war also hatte der MSGKEY den Wert 'xx'x' und darufhin habe ich einen Fehler erhalten. Kann ich das irgendwie umgehen ?

[harkne]

ASSOCIATED_MESSAGE_KEY in einem 2. Satz enhält nach beantworten der offenen Meldung den MESSAGE_KEY des ursprünglichen Satzes mit der Meldung.

Offen Meldungen kann man wie folgt ermitteln
select * from qsys2.message_queue_info t1 where t1.message_queue_name = 'QSYSOPR' and t1.message_type = 'INQUIRY'
and not exists (select * from qsys2.message_queue_info as t2 where t2.message_queue_name = 'QSYSOPR' and t2.associated_message_key = t1.message_key);

Bitte die Nachricht zuvor noch beantworten wenn jemand was weiß.

[Fuerchau]

Hochkommata müssen verdoppelt werden, das war schon immer so.
Alternativ kannst du in SQL den MSGKEY mit "hex(...)" auslesen, das ergibt CHAR(8).
Dann funktioniert auch "SNDRPY MSGKEY(X'........') ...".

[harkne]

Das mit der Verdoppelung habe ich gemacht. Das Problem war dass das Ergebnis 'xx'x' war. OK das mit dem hex() probiere ich. Danke.

[harkne]

Ja hat funktioniert, tausend Dank.

Ich lese jetzt mit hex(message_key) das Feld aus in eine 8-stellige Charachter variable (SQL_MsgKeyHex) und baue mir den Command wie folgt zusammen.

w@Cmd = 'SNDRPY MSGKEY(x''' +
Sql_MsgKeyHex + ''') ' +
'MSGQ(QSYSOPR) RPY(MONITOR) RMV(*NO)'