Jason Java aufräumen

[Robi]

Wir haben vermutet, das es am unterschied 32 Bit Java (json?) und 64 bit Java Standardanwendung liegt und ein

ADDENVVAR ENVVAR(JAVA_HOME) VALUE('/QOpenSys/QIBM/ProdData/JavaVM/jdk80/64bit') LEVEL(*JOB) REPLACE(*YES)

dazwischen gebaut.

Funktioniert auch nicht

Vorübergehnde Lösung:
Beide Jobs werden separat submittet, dann läufts.
Wieder ein Job mehr. Auf einer Kiste, die alle 4-5-Wochen die Jobnr, wiederholt.

[BenderD]

Ein Unterschied zwischen interaktiv und SBMJOB ist, dass der interaktive Job den Speicher der JVM nicht freigibt, der Speicherfraß also größer ist. Wenn das JSON Gedöns von vielen interaktiven Jobs gemacht wird, dann könnte das der Grund für das unterschiedliche Verhalten sein.
Ich würde das allerdings keinesfalls so lassen: der Effekt holt euch ein!!!

D*B

[Fuerchau]

"alle 4-5-Wochen die Jobnr wiederholt"
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.
Die Gesamtlast des Systems sinkt damit z.T. nicht unerheblich und schafft Reserven für Neues.
Dies gilt auch z.B. für Java-Aufgaben (Siehe D*B-Tools auf seiner Seite).

[Robi]

"alle 4-5-Wochen die Jobnr wiederholt"
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.
Die Gesamtlast des Systems sinkt damit z.T. nicht unerheblich und schafft Reserven für Neues.
Dies gilt auch z.B. für Java-Aufgaben (Siehe D*B-Tools auf seiner Seite).

Hahaha ...
netter Versuch ...

[Fuerchau]

Ich fand es nun nicht lustig. Das habe ich bereits mehrfach erfolgreich durchgeführt;-).

[BenderD]

... scheint mir Galgenhumor zu sein.

[Robi]

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.

[BenderD]

Daher spreche ich Euch ab, es beurteilen zu können!

... Entschuldigung, dass ich mich mit Deinem Problem beschäftigt habe.

D*B

[Fuerchau]

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

[Robi]

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]

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!

[BenderD]

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