SQL QSYS2.MESSAGE_QUEUE_INFO MSGKEY

[Peet]

Danke für die Antwort,
die Vorgehensweise kenne ich, es ging ja nur noch um den letzten Schritt "Umwandlung" zurück aus Hexwert.
Bin aber noch nicht wieder dazu gekommen, wenn ich es habe werde ich die Lösung hier posten.


Und in Sachen "Net.Data ist tot" muss ich dir widersprechen, Net.Data ist alles andere als Tot !!!

Ich arbeite seit 1997 mit Net.Data, mit 4 Jahren Auszeit, bis heute bin ich immer noch begeistert, und ich habe viele PHP-Entwickler in Projekten kennen gelernt, die alle, zumindest, beieindruckt waren von Net.Data !

PHP bietet mit keine "unersetzbaren" Vorteile, ganz im Gegenteil, ich brauche einen Apache mit PHP...sicherlich für uns Profis kein Problem, aber hunderte (!!!) AS400-Kleinkunden haben keine eigene EDV...Wartung und Probleme mit PHP-Versionen etc. usw. kommen dann bei dir an...

Mit Net.Data + RPG/REXX/JAVA und allem anderen, was ich noch mit Net.Data problemlos nutzen kann, habe ich alles aus einem "Guß", Updates, zumindest Lic DG1, kommen von IBM...einen Wartungsvertrag haben die meisten der hunderte AS400-Kleinkunden dann Gott sei Dank doch !!!

Und das Net.Data von IBM nicht weiter entwickelt wird, ist aus meiner Sicht kein Problem !
Es gilt die "uralte" Devise der IBM für Entwickler...."Take the best of all !"
2006 hat Steve Will von IBM versprochen, dass Net.Data auf unbegrenzte Zeit in der AS400 unterstützt wird...und er hat Wort gehalten !!! (siehe Anlage)


Ich bediene unsere Kunden laufend mit Entwicklungen in Net.Data in deren Anwendungen ERP, Personal und alles was da so läuft.


Vor Jahren habe ich mir einen Generator codiert, mit dem "generiere" ich auf der Basis einer PF, LF, DSPF oder SQL-Befehl eine komplette "Standardanwendung" zur Verwaltung der Daten mit Ãœbersicht + Filter mit allem drum und dran, so wie der Standardbearbeitung von Daten durch Anzeigen, Ändern, Kopieren und Löschen.
Das ganze sehr intensiv mit Einstellungen/Parametern sowohl hinsichtlich Funktionalität wie auch Berechtigungssteuerung usw.
Und alles in einem "Standard" Apacheserver auf der AS400, mit z.B. den vielen Systeminformationen, die man z.B. mittels den vielen SQL-Views der AS400 (siehe TR's der IBM) "rauskiizzeln" kann.
Dazu noch das beste aus CGIDEV und Scott Klemment...was will man mehr ????
Damit können wir kleine Kunden mit Systembetreuung, große mit kompletten Systemen versorgen !


Das beste Forum "ever" für Net.Data, http://dtwdude.com/forum/main.php, ist leider offline gegangen, Peter Connell, der "Kopf" der Bande, hat leider sie "Seiten" gewechselt, aber Amri ist auch ein sehr erfahrener Entwickler.

Schade das wir hier in Deutschland keine "Lobby-Organisation" für Net.Data haben...wir könnten zig Kunden erfolgreich davon abbringen, die AS400 wegen "KlickyBunti"-Oberflächen von Anwendungen auf anderen Plattformen zu verlassen.
Uns ist das in den letzten 5 Jahren bei 8 Firmen gelungen !!!!
Und IBM hat sich diesbezüglich nie "reingehängt", ganz im Gegenteil, schon ab 1999 haben sie ausschließlich Werbung für ihr "WAS" gemacht, LEIDER !!!!

Und PHP programmiere ich auch, meist bei Kunden die keine AS400 haben, für die sich eine Umstellung aufgrund der Firmengröße auf AS400 nicht lohnt !

Aber alleine die Syntax und Integration in HTLM/JS/jQuery-Code von Net.Data sind einfach nur "genial" !
Und dann noch Net.Data als "Batchjob"....so geil !!!!!
Was ich da schon realisiert habe, was ich sonst in CLLE/oder DB-Jobs hätten packen müssen...

Bei PHP fühle ich mich dann nicht so wohl, von wegen "PHP-Beginn-Code" und "Ende-Code"-Syntax.

Aber das ist natürlich nur meine und "eine" Meinung unter vielen !!!!


Also, sollte jemand Interesse haben etwas in Richtung "Net.Data" erfolgreich aufzuziehen, ich bin bereit !!!

Sorry für den langen Post, aber ich kämpfe gerne leidenschaftlich für Net.Data !!!

Weiterhin viel Erfolg !

Peet

[AG1965_2]

Ich habe Net.Data lange und gerne genutzt, es ist aber kein supportetes Produkt mehr. Sie löschen es nicht, oh Danke (weil sie es vielleicht selber noch wo benutzen). Das ist aber auch schon alles.
Nadir K. Amra hat schon die letzten Jahre diverse Updates nur unter Tricks unterbringen können.
Dieser 1 (in Worten: EINE) Supporter ist nun aber auch weg, und in einem ganz anderen Bereich, soweit ich weiß.
Das ist für ein Unternehmen vielleicht doch nicht ganz der Weg, den man gehen sollte.
Wer einen Haufen alter Makros hat, mag es weiter benutzen und mehr oder minder glücklich damit sein, aber neue Anwender in die Sackgasse zu locken, hat was von Nekrophilie / Fahrlässigkeit.

[holgerscherer]

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? ;-)

Wir verwenden für unsere internen Zwecke auch viel Net.Data - beim Monitoring auch auf bis etwa 500GB Datenbank. Das habe ich einmal mit PHP (Zend) probiert - eine Katastrophe...

-h

[AG1965_2]

Wow, in wiefern sollte das mit php eine Katastrophe sein bzw. wie hast Du denn das geschafft?
Ich habe NICHTS gefunden, das Net.Data besser als php könnte.

[Fuerchau]

Das lag u.U. nicht an PHP sondern am Zend.

[andreaspr@aon.at]

Oder es lag einfach an der Umsetzung.
Es gibt ja auch immer wieder Fälle wo man sagt, dass Java auf der IBM i eine Katastrophe sei und super langsam.
Was auch stimmt, wenn man die Java Module in jedem Job extra aufruft anstatt einen vorgestarteten Job zu verwenden wo die JVM bei jedem Call nicht immer erneut gestartet werden muss.
Und gerade was die Speichernutzung betrifft kann man einiges Einstellen und das ist auch sinnvoll bei Web Anwendungen.

[Fuerchau]

Soweit ich weiß, wird eine JVM für einen Job nur 1x gestartet und endet, wenn der Hauptjob endet.
Das einzige Problem ist halt, dass dies je Job passiert, der Java benötigt.
Je nach Anwendung sind aber vorgestartet Jobs auch nicht das gelbe vom Ei, da ich damit ggf. nicht beliebige Aufrufe durchführen kann und/oder Parallelisierung verliere.
Aber D*B kann das sicher am Besten beurteilen;-).

[andreaspr@aon.at]

Genau, pro Job 1 JVM. Und das ist ja das "Haupt-Problem" wenn man es außer acht lässt. Deshalb die Lösung mit vorgestarteten Jobs.
Gerade mit vorgestarteten Jobs die über DTAQ angesteuert werden hab ich die beste Möglichkeit zur Laufzeit die Parallelisierung zu ändern ohne auch nur die Anwendung selbst anpassen oder neustarten zu müssen.

Das gleiche ist dann auch bei PHP (wenn ich PHP Skripten aus anderen Umgebungen als den Web Server aufrufen will). Ich kann PHP via QSH aufrufen, was aber extrem langsam ist da auch hier wie bei Java die Umgebung erst aufgebaut werden muss.
Wobei es bei PHP sogar noch schlimmer ist, da ein QSH-Job gestartet wird und dadurch die Umgebung IMMER neu aufgebaut werden muss und nicht nur wie bei Java beim ersten aufruf.
(Einfach zu testen in der QSH mal php -version eingeben und die Sekunden zählen)
Deshalb sollte man statt der QSH die Aufrufe via HTTP-Request am Web Server durchführen.
Die HTTP-Jobs sind schon vorgestartet und haben dadurch eine sehr schnelle Verarbeitung.
Dort habe ich eben auch die Parallelisierung vom Web Server.

[BenderD]

<OT>

Genau, pro Job 1 JVM. Und das ist ja das "Haupt-Problem" wenn man es außer acht lässt. Deshalb die Lösung mit vorgestarteten Jobs.
Gerade mit vorgestarteten Jobs die über DTAQ angesteuert werden hab ich die beste Möglichkeit zur Laufzeit die Parallelisierung zu ändern ohne auch nur die Anwendung selbst anpassen oder neustarten zu müssen.


... in Java ist Multithreading sehr einfach zu implementieren, statt mehrere DtaQ Listener hat man da einen einzigen, der einen Thread Pool benutzt. Dann kann man auch sehr einfach für alle native (RPG o.ä.) Clients Status Informationen pro Session halten. Wenn die DtaQs zum Flaschenhals werden, die sind bei weitem nicht so schnell wie ihr Ruf, dann wechselt man auf Sockets. Alles in allem gehört diese ganze Funktionalität in eine eigene Komponente (= Anwendung) gekapselt.
Abschied nehmen muss man bei diesem Design von den synchronen RPG Java Calls per JNI, aber auch das ist ein Gewinn, die sind eh' instabil.

D*B,

der das seit 10 Jahren so macht!
</OT>

[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