SQL QSYS2.MESSAGE_QUEUE_INFO MSGKEY

[derMuller]

Hallo Zusammen,

das Thema ist zwar schon ein knappes Jahr alt, aber ich versuche ebenfalls den 'Message_Key' über die 'qsys2.message_queue_info' zu ermitteln. Wollte den Wert für den Befehl 'SNDRPY', genauer für das Feld 'MSGKEY' verwenden. Nur bekomme ich das Ganze leider auch nicht in char(4) via SQL gecastet.
Nutze SQL unter DB2. Hat vielleicht jemand einen Rat?

Danke im Voraus!

Gruß
derMuller

[Fuerchau]

Wenn du SQL verwendest, must du das Feld als Binary(4) casten.
Dann kannst es auch so an eine Prozedur übergeben.

[derMuller]

Hallo Fuerchau,

wahrscheinlich verstehe ich den Sinn dahinter nicht so ganz.
Ich will ja etwas wie z.B. '3652' haben. Wenn ich es in Binary caste erhalte ich ja genau das Gleiche wie vorher. Gecastet in Binary(4) ist ja immernoch nicht vernünftig lesbar.
Kannst du mir das mal genauer erklären?

Gruß
Dennis

[Fuerchau]

Der MSGKEY muss nicht vernünftig lesbar sein, da er eben ein Binary(4)-Wert ist.
Du erhältst den Binärwert als Binary(4) und kannst ihn so wie er ist für die Messagefunktion verwenden.

[itec01]

Hallo Zusammen,
ich habe auch ein Frage zu dem SQL:
SELECT *
FROM qsys2.message_queue_info m
WHERE message_queue_name = 'QSYSOPR' and message_type = 'INQUIRY';

Ich würde gerne alle unbeantworteten Messages erhalten und dann prüfen und per Programm beantworten, bekomme aber alle INQUIRY Messages.
Weiß jemand, wie ich nur die erhalte, welche noch nicht beantwortet sind.
Wenn es darüber nicht geht, dann werde ich mir den timestamp des letzen Aufrufes ermitteln und eben dann nur noch da schauen. Ein Problem ist aber auch dabei, dass es über die RPLYE autom. beantwortete messages gibt, wie ich die dann prüfe, muss ich schauen.

Danke.
Gruß Klaus

[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'........') ...".