View Full Version : SQL QSYS2.MESSAGE_QUEUE_INFO MSGKEY
Hallo zusammen,
ich lese aus dem View QSYS2.MESSAGE_QUEUE_INFO Nachrichten der Anwender aus den MSGQ's, u.a. das Feld MSGKEY, das ist BINCHAR.
Lesen erfolgt in Net.Data, da wird das Feld MSGKEY allerdings ohne CAST nicht gefüllt bzw. is null !
Ich kann es in mit cast(hex(msgkey)) erfolgreich nach hex umsetzen....aber ich brauche das Feld als Parameter für den Befehl RMVMSG, char 4, den ich in einen CLLE-Pgm verarbeite !
Aber ich krieg es einfach nicht gebacken, hatte es u.a. auch schon mit VARCHAR_FORMAT_BINARY versucht, kiege aber immer den Fehler, dass das 1.Argument falsch ist.... select varchar_format_binary(a.msgqkey, 'XXXX') as msgqkeybinalt ...
Fehlermeldung: Argument 01 der Funktion VARCHAR_FORMAT_BINARY ungültig. (SQLSTATE 42815, SQLCODE -171)
Kann mir jemand sagen wie ich das hinkriege ???
Danke vorab !
Hast Du schon mal versucht die Spalte direkt nach CHAR(4) zu konvertieren?
also: Cast(Message_Key as CHAR(4))?
Birgitta
Hast Du schon mal versucht die Spalte direkt nach CHAR(4) zu konvertieren?
also: Cast(Message_Key as CHAR(4))?
Birgitta
Guten Morgen + Danke Birgitta..
ja habe ich, aber bei den unzähligen Test's kann ich gerade nicht sagen wie es damit war....
Probiere es nochmals und komme gleich zurück....
Birgitta,
also habe ich auch mit cast als char(4) getestet, auch ohne Erfolg.
Ich muss aber noch dazu sagen, dass ich bei Ausführung des SQL generell SqlCode 0462 zurückkriege, den fange ich zwar bei der Ausführung des SQL in Net.Data ab, aber dadurch wird es ja auch nicht besser.
In "5250" funktioniert es aber sehr wohl, auch ohne jeglichen cast, aber auch mit char(4)...output ist das gleiche in 5250 !!!...muss also eher an Net.Data liegen...schade !
Gibt es denn vielleicht eine Möglichkeit, den korrekt ermittelten Hexwert des msgqkey aus dem View wieder in den 4-stelligen Key für RMVMSG umzusetzen ???
Die Frage klingt vielleicht ein wenig nach "Anfänger", aber man versucht ja alles mögliche, um zum Ziel zu kommen....und wie IBM immer so schön sagt.... "Take the best of all"
Danke nochmals für deine Unterstützung !
Vg.
Versuche mal ein cast(Key as binary(4)) oder cast(as char(4) ccsid 65535).
Das Problem von net.data ist die Verarbeitung in ASCII, während die Daten ja in EBCDIC ausgelesen werden.
Nur Binärdaten unterliegen keiner Umsetzung.
Was das Übergeben dann an RMVMSG angeht, so könntest du da vor einem ähnlichen Problem nur umgekehrt stehen.
Hier böte sich dann ein SQL-Wrapper an, der ja wiederum Binärdaten akzeptiert und als ausführendes Programm an ein CLLE-Modul/CLP-Programm für den RMVMSG weitergibt.
SQLCODE 0462 ist kein Fehler sondern eine Warnung (der lediglich besagt, dass eine Warnung ausgegeben wurde), die ignoriert werden kann.
Birgitta
Versuche mal ein cast(Key as binary(4)) oder cast(as char(4) ccsid 65535).
Das Problem von net.data ist die Verarbeitung in ASCII, während die Daten ja in EBCDIC ausgelesen werden.
Nur Binärdaten unterliegen keiner Umsetzung.
Was das Übergeben dann an RMVMSG angeht, so könntest du da vor einem ähnlichen Problem nur umgekehrt stehen.
Hier böte sich dann ein SQL-Wrapper an, der ja wiederum Binärdaten akzeptiert und als ausführendes Programm an ein CLLE-Modul/CLP-Programm für den RMVMSG weitergibt.
Danke !!!
Beides geht leider auch nicht, aber wie du schon sagst, Net.Data arbeitet zumindest nicht mit BIN-Daten...leider ist das Forum "dtwdude" offline, Peter hat einen neuen Job :=(
Mal schauen, erst einmal weglegen :confused: ...ihr kennt das ja ....manchmal dämmert es einem ja dann beim z.B. "rasen mähen" :cool: ..
Danke euch beiden nochmals !!! :rolleyes:
Birgitta,
Ja ich weiß...aber man sucht ja dann an jeder Ecke, die "auffällig" ist :=(
Danke !
Dann schreib dir einfach einen kleinen SQL->CLLE/CLP-Wrapper, der mittels %BIN(&VAR 1 4) einen Zahlwert ermittelt und z.B. als Typ DEC(10, 0) zurückliefert.
Dazu dann das Gegenstück um aus DEC(10, 0) wieder einen %BIN erstellt.
Alternativ könntest du ja für den RMVMSG-Wrapper den Key als DEC(10, 0) übergeben und dann in %BIN umwandeln.
Möglichkeiten gibt es viele.
Hast Du schon mal probiert, die problematischen Hex-Werte mit HEX(MSGKEY) in ein unverfängliches Format zu konvertieren? Net.Data versteht x'00' als String-Ende, und das wirst Du im Msgkey wohl haben. Und mit der Original-Zeichenfolge fängst Du in Net.Data selebr sowieso nichts an, also ist etwas Lesbares wohl brauchbarer. Wenn es ein Programm wieder original brauchen sollte, kann es das ja wieder zurückwandeln.
In Amerika wird es wohl noch ein paar Net.Data-Nutzer geben, die wurden in der Vergangenheit von Nadir K. Amra vorbildlichst betreut, vielleicht tut er noch ein bisschen? amra@us.ibm.com
Das tote Pferd Net.Data ist in den allermeisten Fällen eigentlich recht leicht durch php ablösbar - warum gönnt man dem Gaul nicht seine wohlverdiente Ruhe? ;-)