View Full Version : Jason Java aufräumen
Moin zusammen
ein SQLRPGLE Pgm liest mit SQL ein JSON, das funktioniert auch gut.
Anschl. submittet der Job ein Pgm in dem Java verwendet wird.
Diese Standardanwendung funktioniert nicht mehr, vermutlich weil irgendwelche Java Variablen / Umgebungsvariablen gesetzt sind.
Eine LIBPATH variable haben wir schon als Täter erkannt und nemhmen diese zurück
Trotzdem bekommt der 2. job diesen Fehler
JVMJ9VM015W Initialisierungsfehler für Bibliothek j9gc29(2): Instanziieren des Heapspeichers ist fehlgeschlagen; 32G erforderlich
Unable to create Java Virtual Machine.
Weitere ENVVar, die offensichtlich was mit Java zutun haben, haben wir nicht entdeckt.
Weis einer was ich bereinigen muß, oder mit welchem Befehl ich die Json-Java Umgebung aufräumen kann?
Danke
Robi
(alternativ: ALLE ENVVAR der funktionierenden Umgebung merken, alle der Json Umgebung löschen und alle funktionierenden setzen.
Das ist aber ziemlich mühselig.)
Ggf. gibt es im Java-Verzeichnis der JVM noch eine .Config-Datei.
Moin zusammen
ein SQLRPGLE Pgm liest mit SQL ein JSON, das funktioniert auch gut.
Anschl. submittet der Job ein Pgm in dem Java verwendet wird.
Diese Standartanwendung funktioniert nicht mehr, vermutlich weil irgendwelche Java Variablen / Umgebungsvariablen gesetzt sind.
Eine LIBPATH variable haben wir schon als Täter erkannt und nemhmen diese zurück
Trotzdem bekommt der 2. job diesen Fehler
JVMJ9VM015W Initialisierungsfehler für Bibliothek j9gc29(2): Instanziieren des Heapspeichers ist fehlgeschlagen; 32G erforderlich
Unable to create Java Virtual Machine.
Weitere ENVVar, die offensichtlich was mit Java zutun haben, haben wir nicht entdeckt.
Weis einer was ich bereinigen muß, oder mit welchem Befehl ich die Json-Java Umgebung aufräumen kann?
Danke
Robi
(alternativ: ALLE ENVVAR der funktionierenden Umgebung merken, alle der Json Umgebung löschen und alle funktionierenden setzen.
Das ist aber ziemlich mühselig.)
... eigentlich leiste ich ungern Beihilfe zum Murks. Beim SBMJOB ist der default CPYENVVAR(*NO) und damit ist das doch entkoppelt?!.
D*B
Beim SBMJOB ist der default CPYENVVAR(*NO) und damit ist das doch entkoppelt?!.
Der Java Job, gestartet mit einem einfachen
CHGVAR VAR(&QCMD) VALUE('cd ' *BCAT &PATH *TCAT +
';./bin/run.sh ' *BCAT &DTAQ *BCAT &DLIB)
SBMJOB CMD(QSH CMD(&QCMD)) JOB(&Job) + ...
braucht eine Liblist.
Der submittete Job hat diese, aber die Java eingenen Q... Jobs haben die nicht.
Die holen sich die Liblist aus einer envvar.
Robi
... der Fehler sieht aber eher nach einem Bug in der Java Runtime aus, die allwissende Müllhalde, Tante Google findet den bei OpenJ9.
D*B
Nachtrag: Kann auch sein, dass euer Einsatz von Java stored procedures (das JSON Gedöns) den Zweck erreicht hat: Hauptspeicher alle => neuen bei IBM bestellen.
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.
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
"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).
"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 ...:rolleyes:
Ich fand es nun nicht lustig. Das habe ich bereits mehrfach erfolgreich durchgeführt;-).