JVM beenden

[BenderD]

nochmal ein paar Grundlegende Zusammenhänge zum Verständnis:
- RPG verwendet für seine Java Einbindung das Java native Interface (JNI), das ist eine Java Standardschnittstelle für C Programme, die auch auf einer AS/400 wie auf jeder anderen Plattform funktioniert, wird das nicht so implementiert, gibt es keine Kaffeetasse.
- JNI Anwendungen laufen (skizziert) wie folgt:
-- erzeugen der Java VM mit JNI_CreateJavaVM, hier wird die JVM geladen und man bekommt ein array of pointer, mit dem man auf Funktionen der JVM zugreifen kann
-- Aufruf von Java Funktionen über die erhaltenen Pointer
-- beenden der JVM mit DestroyJavaVM (macht man das nicht, stirbt die VM spätestens bei Ende des Prozesses = Job)

Bei der Verwendung von Java in RPG Programmen über die Unterstützung des Compilers macht man selber keinen JNI_CreateJavaVM (das versucht der Compiler implizit), mit einer Palette an Nebenwirkungen, man kann nicht steuern wie man die JVM gestartet haben will und man kann das beenden aus RPG nicht steuern (da man an die Pointerstruktur nicht drankommt!!!).

Im vorliegenden Fall wird ein RPG Programm mit RCLACTGRP rausgefenstert, mit der Folge, dass die Werte der Pointer, die die Verbindung zur JVM darstellen futsch sind.

Wird jetzt das RPG Programm aufgerufen, hat das Pointerfehler zur Folge, da die RPG Runtime den Connect zur noch existierenden JVM nicht mehr bekommt (zeitweilig wurde da einfach eine weitere gestartet, was mit neueren Releases nicht mehr geht).

Problem ist hier in keinem Fall das "ordentliche" beenden der JVM, das geht in jedem C Programm ohne jedes Problem. Problem ist hier, dass man (so wie es aussieht) ein RPG Programm mit RCLACTGRP rausfeuern kann und dasselbe Programm anschließende keinen connect zur JVM mehr findet.

Wenn das aus dem Kaffeesatz raus soll, dann muss hier mehr Information auf den Tisch.

D*B

Weitere schlechte Nachrichten
das mit dem destroy geht, wie von KM beschrieben, auch nicht.
Und die Umstellung auf einen Server Job ist nicht möglich, das es in dem Pgm einen kleinen Dialog Teil gibt, der natürlich so nicht mehr funktioniert. Da der Dialog mit Dateien die vom Java erzeugt werden arbeitet, (Qtemp ) ist das auch nicht ohne weiteres zu trennen.
Bleibt das Prob. die JVM 'ordentlich' zu beenden.

Robi

[Robi]

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

[BenderD]

"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

[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

[KM]

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

[BenderD]

... 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???????

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[BenderD]

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

[Robi]

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

[Fuerchau]

Vielleicht hilft die folgendes API weiter:
Open List of Activation Attributes (QWVOLACT) API

Dann kannst du gezielt Aktivierungsgruppen zurücksetzen.
Die *DFTACTGRP wird mit RCLRSC weitgehend bereinigt.