View Full Version : Jason Java aufräumen
... scheint mir Galgenhumor zu sein.
wenn ich vor dem Json job ein
ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit') LEVEL(*JOB) REPLACE(*YES)
absetze, kann ich anschl. die Standardanwendung ausführen.
@lustig und Galgenhumor
Da würde ich mir schon mal Gedanken machen, ob nicht eine DTAQ-Verteilung von Aufgaben effektiver gestaltet werden kann. Man muss nicht ständig irgendwelche Arbeitsobjekte in QTEMP neu erstellen wo ggf. ein CLRxxx reicht.
Per PJE gibt es auch die Möglichkeit parallele Jobs einzurichten.
Klingt als ob Ihr die Anwendung kennt.
Tut ihr aber nicht!
Daher spreche ich Euch ab, es beurteilen zu können!
Und ich schrieb nirgends, das dort ständig irgendwelche Arbeitsobjekte in qtemp erstellt werden
oder wir dort keine Dataq's oder PJE jobs benutzen!
Die Anwendung, die Fälle, die nötigen Jobs und die Datenbank ist einfach nur richtig fett.
Nicht, das es dort kein Optimierungspotential gibt, aber Wunsch und Wirlichkeit sind halt 2 paar Schuhe.
Daher spreche ich Euch ab, es beurteilen zu können!
... Entschuldigung, dass ich mich mit Deinem Problem beschäftigt habe.
D*B
Nun ja, seine Lösung hat er ja bereits kundgetan:
"Vorübergehende Lösung:
Beide Jobs werden separat submittet, dann läufts."
Aber vielleicht probiert ers ja doch mal mit deinem Tool:
http://www.bender-dv.de/AppServer4RPG.html
Moin zusammen,
die eigendliche Lösung ist das setzen des Java_Home vor dem JSON Aufruf.
Dadurch wird die Java/Sql kombination, die das JSON holt in die 64Bit Schiene gelenkt, die später von dem Standardprogramm verwendet wird.
holgerscherer
26-11-19, 00:25
Wieder ein Job mehr. Auf einer Kiste, die alle 4-5-Wochen die Jobnr, wiederholt.
Hatten wir nicht schon vor tausend Jahren mal gesagt, daß das Erstellen (und Aufräumen) eines Job recht teuer ist? Unbedingt weg davon!
Hatten wir nicht schon vor tausend Jahren mal gesagt, daß das Erstellen (und Aufräumen) eines Job recht teuer ist? Unbedingt weg davon!
... was zu KiloHertz CISC-Zeiten richtig war, muss zu GigaHertz RISC-Zeiten nicht mehr universell stimmen. Nichtsdestotrotz ist das Vielfach-starten von JVMs ein Kunstfehler und es wäre schon lange an der Zeit, dass IBM die Jobnummer auf BigInt aufbohrt.
D*B
Hatten wir nicht schon vor tausend Jahren mal gesagt, daß das Erstellen (und Aufräumen) eines Job recht teuer ist?
nun Rate mal, warum ich die Lösung der 2 Submit NICHT so toll fand.
Unbedingt weg davon!
Alle Jobs werden, wenn es eine Anpassung gibt, auf optimierung untersucht. Das es dabei zu diskepanzen zwischen 'Machern' und 'Bezahlern' kommt ist hoffendlich jedem klar.
Nichtsdestotrotz ist das Vielfach-starten von JVMs ein Kunstfehler
Liebe Hersteller von Standardsoftware. Aus o.g. Gründen bitten wir Euch, eure Software so zu gestallten, das Sie die laufenden JVM's aus IBM Jobs erkennt und keine neue aufmacht.
Das liegt in der Art der Implementierung durch die IBM.
Eine JVM ist dem aufrufendem Job zugeordnet, da ja jeder seine eigene Umgebung aufbauen kann.
Wenn mann dann auch noch Java aus QSH aufruft hat man schon einen weiteren Job am Hals.
Aber wer macht sich da schon Gedanken drüber;-), es geht ja alles so schön fix.
Das Erstellen und Aufräumen eines Jobs ist recht zeitaufwändig. Dies kann schon durchaus 1-2 Sekunden dauern. Wenn dann die eigentliche Aufgabe bereits kürzer als 2 Sekunden ist, ist bestimmt eine Optimierung mit z.B. DTAQ möglich, da kann man den eigentlichen Call (denn mehr enthält ein SBMJOB ja nicht) auch schön in eine Datei mit ID-Spalte schreiben und die ID per DTAQ routen.
Falls abweichende User benötigt werden, kann man auch dies per API lösen.
Je Umgebung (LIBL) hat man seine DTAQ und per PJE n-fache Parallelisierung.
300.000 Jobs pro Tag sind in meinen Augen immer unnötig.
Und mit den JVM's kann man es durchaus ebenso sehen. Hier kann man die aufkommenden Arbeiten sogar via Thread parallelisieren.
holgerscherer
26-11-19, 22:47
... was zu KiloHertz CISC-Zeiten richtig war, muss zu GigaHertz RISC-Zeiten nicht mehr universell stimmen. Nichtsdestotrotz ist das Vielfach-starten von JVMs ein Kunstfehler und es wäre schon lange an der Zeit, dass IBM die Jobnummer auf BigInt aufbohrt.
Das stimmt immer noch, weil die Jobstrukturen nicht schlanker werden - und es gibt genug I/O, den man damit vermeiden kann. Gerade, wenn der Hauptspeicher zufällig etwas knapp ist.
Das mit der Jobnummer hatte ich schon mal. Bin krank daheim, könnte also noch RFEs schreiben. Aber ich schätze, da knallts wieder an diversen Parameter-Ecken.