RPG-Pgm innerhalb CL-Pgm wird aus Java nicht aufgerufen

[hartmuth]

Das Problem ist durchaus noch knifflig.
Ich grüble und grüble und komme nicht drau.
Sieht alles richtig aus.

Die Variable für PMode wird in Java mit dem vorgesehenen Befehl übergeben.
Lt. Debug aus CL-pgm heraus steht auch T drinnnen.

(Mit SQL habe ich zuwenig Erfahrung, um dahin asuzuweichen)

[BenderD]

...also mal ganz der Reihe nach:

erst rufst du aus Java ein RPG Programm auf, das nichts tut, weil es seine Daten nicht findet (siehe Thread im Java Forum).
(Ursache ist, dass die ProgrammCall Klasse in einem prestarted AS400 Server Job läuft, mit INLLIBL *NONE)

Dann baust Du ein CL um das RPG Programm und rufst das aus Java auf und postest einen Teil des CLs (ohne den vorsorglichen MONMSG CPF0000, wahrscheinlich).
Das funzt freilich auch nicht, weil der ADDLIBLE in den Wind geht, da die Referenzbibliothek des *AFTER nicht im LIBL des Serverjobs ist.

Das der ADDLIBLE nicht geht, macht nix, das ist ohnehin Murks, weil die Serverjobs wieder verwendet werdem und dann die Umgebung für die nächste Verwendung verschraubt ist. (BTW: Bei der SQL Variante hast Du dasselbe Problem mit dem LIBL).

Am saubersten ist hier (wenns denn unbedingt dieser wilde Mix dreier Programmiersprachen in zwei Jobs sein soll) OVRDBF OVRSCOPE(*CALLLVL).

D*B

[Fuerchau]

Bei SQL muss ich da wiedersprechen.
Jeder Connect ruft im Serverjob QZDASOINIT einen CHGLIBL.
Gebe ich keine Libs an (was wenig sinn macht) steht QUSRLIBL wieder drin.
Zusätzlich kann ich in der Verbindungsfolge meine benötigte LIBL komplett angeben.
Selbst bei Wiederverwendung von Jobs habe ich also eine korrekte LIBL.

[BenderD]

... auf das Umgebungs Receycling bei Rückgabe würde ich mich nicht verlassen wollen; und schau Dir mal die Kette bis zur LIBL eines prestarted Jobs an...

Bei SQL muss ich da wiedersprechen.
Jeder Connect ruft im Serverjob QZDASOINIT einen CHGLIBL.
Gebe ich keine Libs an (was wenig sinn macht) steht QUSRLIBL wieder drin.
Zusätzlich kann ich in der Verbindungsfolge meine benötigte LIBL komplett angeben.
Selbst bei Wiederverwendung von Jobs habe ich also eine korrekte LIBL.

[Fuerchau]

Bisher habe ich bei meiner Arbeit im ODBC zur AS/400 bzgl. LIBL keine Schwierigkeiten.

Das einzige Problem hat hier das OS selber bei Mehrsprachumgebung.
Es wird automatisch ein CHGSYSLIBL QSYS29xx gemacht.
Wenn dann die Stammsprache zum Zuge kommt schlägt dieser dann fehl da die Lib ja meist fehlt. Eine leere Lib dieses Namens tuts dann aber auch.

Wie lange der Connect dann dauert ist mir auch egal, der liegt meist unter 1 Sekunde und wird ja nur bei App-Start (oder reconnect bei Fehlern) gemacht.

Da sind dann falsche Queries schon eher ein Problem .

[hartmuth]

Ich finde den Gedanken mit der Bibl.Liste von Hrn. Bender schon hilfreich für meinen Fall, da ich auch einen Fehler bei "CHGSYSLIBL QSYS29xx" im Joblog gefunden habe.

Ich werde am Montag - leider vorher keine Gelegenheit - das RPG-Programm an einen separaten Job übergeben. Dort wird die Libl geändert und das RPG-Pgm aufgerufen (muss zuerst in einer Test-Umgebung die Aktionen ausführen, erst später in der Produktiv-Umgebung mit der Standard-Bibl.liste)
Ich denke, das wird dann funktionieren.

Danke für die zahlreichen, kompetenten Ratschläge.
Ich habe etwas dazugelernt. Anfangs dachte ich wirklich , ich "träume" und konnte es mir überhaupt nicht erklären.

Warum mache ich es über Java?
Ein angekauftes Programm stellt Schnittstellen-Datei in einer Text-Datei am Server bereit. Diese hole ich mit Java ab. Bei der Verarbeitung greife ich dann aber auf ein bereits vorhandenes RPG-Programm zurück . DAher der Mischmasch.

[BenderD]

... wenn ich das richtig verstehe, kann das RPG Programm dann asynchron weiterlaufen, dann tut es ein SBMJOB per CommandCall Object, dem kann man per JOBD oder Parameter direkt eine LIBL mitgeben; da braucht man kein weiteres CL.

Wenns programm technisch kompliziert wird, gibt es oft einen einfacheren Weg und da ist es hilfreich, wenn man zumindest kurz skizziert was man vor hat, eh' man dann von einem Loch ins nächste stolpert - vielleicht hat dann jemand einen einfacheren Weg vorzuschlagen.

D*B

[hartmuth]

Ja, Sie haben natürlich Recht.
Ich war überrascht, wie schnell es kompetente Antworten zu meinem Problem gab. Ich habe etwas dazugelernt. Die Problematik mit der Job-Übergabe an QUSER war mir nicht bekannt/bewußt. Danke allen, die sich fruchtbar beteilgt haben.