View Full Version : JVM beenden
"funktioniert nicht", "geht nicht", sind etwas generische Angaben, es ist auch schön, wenn ihr wisst was das Programm macht und warum der RCLACTGRP erforderlich ist, oder ein RRTJOB nicht geht, aber davon weiß es der geneigte Leser hier nicht; ein wenig konkreter müsste das schon sein (wenn das denn per Ferndiagnose im Forum überhaupt lösbar ist.
D*B
Danke Dieter,
ich versuch 's mal ...
da ich weis, wann das Pgm verlassen wird, könnte ich unmittelbar vorher ein 'beende' aufrufen.
leider gehen die Beispiele nicht
(oder ich mach was falsch)
Das Destroy war ja ein srvpgm.
Da mein rufendes pgm ein RPG ist habe ich es in ein separates LE pgm gepackt, das ich rufe mit actgrp(*caller)
Robi
Die Frage nach dem warum ist "SubOptimal"
Das ist keine Verarschung, das ist wirklich so !!
Es war einmal das Problem das ???? nicht funktionierte.
... und zur Lösung des Problems wurde vorgeschlagen die Umgebung aufzuräumen. Seit dem ist in dem Menu als Abschluß ein RCLRSC und RCLACTGRP und es gab nie wieder das (Keiner weiss mehr welches!!) Problem.
Die Software funktionierte glücklich und zufrieden bis eines Tages eine Fremdsoftware eingeführt wurde die auch mit Java arbeitet.
Ich rufe nun VOR dem rclactgrp die versionen des "endjava"
(egal ob destroy oder das aus dem englischen Forum) bekomme ich nach erneutem Java Aufruf (Fremdsoftware!)
(immernoch) diesen Fehler:
Weitere Nachrichteninformationen
Nachrichten-ID . . . . : JVAB55C Bewertung . . . . . . : 40
Nachrichtenart . . . . : Diagnose
Sendedatum . . . . . . : 25.03.10 Sendezeit . . . . . . : 11:02:3
Nachricht . . . : Java Virtual Machine kann nicht erstellt werden.
Ursache . . . . : Wegen Ursachencode 5 konnte Java Virtual Machine (JVM)
nicht erstellt werden. Die Ursachencodes sind wie folgt definiert:
4 - Der Thread ist einer anderen JVM zugeordnet.
5 - JVM bereits in in Bearbeitung.
7 - Der Prozess muss Multithread-fähig sein.
8 - Der Klassenpfad ist nicht gültig.
9 - Informationen für die Garbage Collection sind nicht gültig.
13 - Empfangene Eigenschaften sind nicht gültig.
15 - Zweite JVM kann für einen einzelnen Prozess nicht erstellt werden.
18 - JVM_OnLoad-Verarbeitung für -Xrun-Option konnte nicht zu Ende
durchgeführt werden.
Weitere .
Das würde ich gerne ändern
Eine analyse, warum der RCLACTGRP läuft
und eine individuelles aufrufen nur wenn wirklich nötig
kommt (fast) nicht in Frage, da die SW permannent weiter gepflegt wird und sich somit immer die Bedingungen ändern.
Ich weiß, unbefriedigende Antwort (auch für mich) aber
...
Gruß
Robi
beenden der JVM mit DestroyJavaVM (macht man das nicht, stirbt die VM spätestens bei Ende des Prozesses = Job)
Hört mir hier eigentlich irgendjemand auch mal zu??? Wie oft soll ich eigentlich noch schreiben, dass man eine JVM innerhalb eines Jobs nicht mehr manuell beenden kann? Das mag vielleicht bis V5R1 noch möglich gewesen sein mit der erwähnten Prozedur, aber danach nicht mehr!!!
neuere Doku als V6R1 kenne ich nicht!
Da bin ich ganz Deiner Meinung. Aber was willst Du mir damit sagen???????
@Robi:
Es bleibt Dir aus meiner Sicht wirklich nur übrig den RCLACTGRP wegzulassen, so wie vom Hersteller der Software empfohlen. Probier es doch mal aus, um festzustellen, ob der ursprüngliche Fehler wieder auftritt. Vielleicht kann man den ja dann anderweitig beheben. Oder handelt es sich evtl. um benannte ACTGRPs, die Du gezielt beenden kannst?
Gruß,
KM
... wenn du mal dem link folgen würdest, dann stösst du auf die offizielle Doku von DestroyJavaVM V6R1 und die sagt was anderes als du - ergo: einer erzählt Quatsch, du oder die Doku.
D*B
Da bin ich ganz Deiner Meinung. Aber was willst Du mir damit sagen???????
RCLACTGRP ist die Ursache, das haben wir getestet.
Es wegzulassen ist nicht möglich, da div. ILE uns SQL Ile pgmme in abh. vom Benutzerverhalten gerufen werden.
Die Actgrp's sind nicht benannt (jedenfalls nicht alle)
Wir haben nun ein Prob. bei IBM aufgemacht.
mal sehn was wird
Gruß
Robi
Hat denn diese neue Software keine eigene benannte ACTGRP ?
Dann lass diese doch aktiv und beende nur deine eigenen ACTGRP's.
Ein nachträgliche Änderung der ACTGRP ist nicht möglich.
Wenn das Programm die ACTGRP *CALLER verwendet (DSPPGM), dann erstelle ein Aufrufprogramm mit benannter ACTGRP die das neue Proggi aufruft. Dann musst du diese ACTGRP auch nicht auflösen. Das neue Programm müsste doch damit leben können, wenn die ACTGRP bestehen bleibt, ansonsten würde ich bei dem Lieferanten einen Fehler melden.
Allerdings darfst du RCLACTGRP ACTGRP(*ELIGIBLE) dann nicht mehr verwenden.
Jain,
das geht leider nicht, da manche Aufrufe in dem Pgm ile mit *new rufen, (das sind dann Pgmme die auch aus dem Menü gerufen werden können)
Es werden u.a. 2 QJV* actgrp's geschlossen.
Wenn ich die ausschließen könnte ..
Ich hab leider nicht nur feste zu schließende Namen
Robi
new ist nicht persistent, die fliegt selber weg
D*B
Jain,
das geht leider nicht, da manche Aufrufe in dem Pgm ile mit *new rufen, (das sind dann Pgmme die auch aus dem Menü gerufen werden können)
Es werden u.a. 2 QJV* actgrp's geschlossen.
Wenn ich die ausschließen könnte ..
Ich hab leider nicht nur feste zu schließende Namen
Robi
Vielleicht hilft die folgendes API weiter:
Open List of Activation Attributes (QWVOLACT) API (http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qwvolact.htm)
Dann kannst du gezielt Aktivierungsgruppen zurücksetzen.
Die *DFTACTGRP wird mit RCLRSC weitgehend bereinigt.
sicher ????
das könnte helfen,
Ich mach ein cl, in dem alle benannten ACTGRP's aufgelistet werden die mit monmsg zu gemacht werden
Ist zwar nicht besonders elegant ...
Das werd ich hier mal vorschlagen
Gruß
Robi