Spoolfiles erstellen ohne QNPSERVS-Jobs?

[Christian.Hesse]

Hallo!

Ich habe ein kleines Problem:
Ich erzeuge mittels Java Spoolfiles in eine OutQueue auf der iSeries. Das läuft soweit auch sehr gut und schnell, allerdings zeigt sich auf der iSeries selber ein kleines Problem: Für jedes Spoolfile das ich erzeiuge wird ein QNPSERVS-Job erzeugt, der dann bis zum bitteren Ende da steht und anscheinend nie wieder verwendet wird. Das würde mich nicht weiter stören, wenn es nicht alleine für diese Woche 1425 Jobs wären und die Anzahl wöchentlich ungefähr um die selbe Menge steigen wird.

Um mal ein bisschen aus dem Code zu plaudern:

SpooledFileOutputStream out = new SpooledFileOutputStream(system,
paramList, null, null);

writer = new SCS5256Writer(out, ccsid, system);


In einer Schleife wird folgender Code zum Schreiben des Inhaltes verwendet:
writer.write(lines[i]);
writer.carriageReturn();
writer.lineFeed();

Und zum Schluß kommt:
writer.flush();
writer.close();

Ich habe ja schon relativ hart lernen müssen, daß Java in der QUSRWRK jede Menge Jobs verbricht (Egal ob QZDASOINIT oder QZRCSRVS) aber so extrem hatte ich das noch nie und vorallem konnte ich dem bisher immer mit dem gezielten aufrufen von Closes Herr werden.

Hat irgendwer eine Lösung?

Vielen herzlichen Dank!

Gruß

Christian

[BenderD]

was ist denn mit deinen system und writer Objekten? hat da noch jemand Referenzen drauf?

D*B

PS: Java verbricht keine Jobs, dafür ist der Toolbox Spielkram verantwortlich.

Hallo!

Ich habe ein kleines Problem:
Ich erzeuge mittels Java Spoolfiles in eine OutQueue auf der iSeries. Das läuft soweit auch sehr gut und schnell, allerdings zeigt sich auf der iSeries selber ein kleines Problem: Für jedes Spoolfile das ich erzeiuge wird ein QNPSERVS-Job erzeugt, der dann bis zum bitteren Ende da steht und anscheinend nie wieder verwendet wird. Das würde mich nicht weiter stören, wenn es nicht alleine für diese Woche 1425 Jobs wären und die Anzahl wöchentlich ungefähr um die selbe Menge steigen wird.

Um mal ein bisschen aus dem Code zu plaudern:

SpooledFileOutputStream out = new SpooledFileOutputStream(system,
paramList, null, null);

writer = new SCS5256Writer(out, ccsid, system);


In einer Schleife wird folgender Code zum Schreiben des Inhaltes verwendet:
writer.write(lines[i]);
writer.carriageReturn();
writer.lineFeed();

Und zum Schluß kommt:
writer.flush();
writer.close();

Ich habe ja schon relativ hart lernen müssen, daß Java in der QUSRWRK jede Menge Jobs verbricht (Egal ob QZDASOINIT oder QZRCSRVS) aber so extrem hatte ich das noch nie und vorallem konnte ich dem bisher immer mit dem gezielten aufrufen von Closes Herr werden.

Hat irgendwer eine Lösung?

Vielen herzlichen Dank!

Gruß

Christian

[Christian.Hesse]

Hallo!

system und writer werden für jede Seite neu erzeugt und danach nie wieder verwendet.

Ich weiß, daß das die Toolbox verabschiedet, allerdings bin ich leider selbst mit einem RPG-Programm und dem Aufruf dessen aus Java auf die Toolbox angewiesen. Order gibts da Alternativen?

Gruß

Christian

was ist denn mit deinen system und writer Objekten? hat da noch jemand Referenzen drauf?

D*B

PS: Java verbricht keine Jobs, dafür ist der Toolbox Spielkram verantwortlich.

[BenderD]

ad 1:
wenn denn erzeugt und nie wieder verwendet heißt, dass das im RPG so passiert, dann wird wohl die RPG Runtime eine Referenz auf diese Objekte halten und damit leben die wohl weiter. Es sollte ab er auch möglich sein sich die Referenzen selber zu merken und dann weiterzuverwenden, dann sollte dieser Effekt weg sein.
ad 2:
Aus Java RPG aufrufen: stored Procedures unter Verwendung eines Connection Pools.
Aus RPG Java aufrufen: bleiben lassen, komplett in Java schreiben, oder (wenns denn unbedingt sein muss)
- entkoppeln über DataQ und Java Command Server für RPG (muss man selber programmieren).

Aus Java SCS drucken, warum denn sowas??? Das ist ja wie ein Auto schieben, um Sprit zu sparen.

D*B

Hallo!

system und writer werden für jede Seite neu erzeugt und danach nie wieder verwendet.

Ich weiß, daß das die Toolbox verabschiedet, allerdings bin ich leider selbst mit einem RPG-Programm und dem Aufruf dessen aus Java auf die Toolbox angewiesen. Order gibts da Alternativen?

Gruß

Christian

[Christian.Hesse]

Hallo!

Ich habe mein Problem offensichtlich inzwischen gefunden: Jedes AS400-Objekt hat bei Benutzung mindestens einen Job auf der iSeries hintendran hängen.
Nachdem das Objekt keine close() besitzt, hatte ich es bisher leider immer für einen Container, der die Connect-Daten herumträgt gehalten. Inzwischen habe ich neben der disconnectAllServices() auch den AS400ConnectionPool entdeckt und nach dessen Implementierung komme ich plötzlich mit einem QNPSERVS und zwei QZRCSRVS Jobs auf der iSeries, bzw. mit drei System-Objekten im Pool aus.

Vielen herzlichen Dank für die Hilfe.

ad 1:
wenn denn erzeugt und nie wieder verwendet heißt, dass das im RPG so passiert, dann wird wohl die RPG Runtime eine Referenz auf diese Objekte halten und damit leben die wohl weiter. Es sollte ab er auch möglich sein sich die Referenzen selber zu merken und dann weiterzuverwenden, dann sollte dieser Effekt weg sein.

Der Garbage Collector der JVM auf der iSeries fühlte sich offensichtlich überhaupt nicht motiviert, die nicht mehr benötigten AS400-Instanzen wegzuräumen, denn beim Stoppen des WAS (in dem die Applikation läuft) sind die Jobs alle über den Status EOJ verschollen. (Und seit der Implementation des ConnectionPools nie wieder in größerer Zahl aufgetaucht.

ad 2:
Aus Java RPG aufrufen: stored Procedures unter Verwendung eines Connection Pools.

Du meinst die auszuführenden Kommandos dann in RPG/CL zusammenfassen und das als Stored Procedure über JDBC ausführen?

Aus Java SCS drucken, warum denn sowas??? Das ist ja wie ein Auto schieben, um Sprit zu sparen.

D*B

Ich schiebe das Auto nicht einmal, ich lasse es stehen. ;-)

Der Grund für SCS-Druck aus Java ist das Erzeugen von Spool-Files, die mit Interform dann gemapped werden. Ich weiß, daß es zig API's unter Java gibt, die formatieren und Barcodes erzeugen und was weiß ich noch alles können, aber es war nunmal die Vorgabe... ;-)

Vielen herzlichen Dank nochmal!

Gruß

Christian

[BenderD]

solange jemand Referenzen auf Objekte hält, kann der Garbage Collector nix ausrichten. Wenn stoppen des WAS heißen soll beenden (komplett runterfahren), dann haben die Server Jobs einen Schuss, wenn sie dann nicht runterfallen, da würde ich mal nach PTFs suchen.

Stored Procedures heißt einfach nur AS/400 Programme, die man aus Java aufurfen will als externe stored Procedures registrieren und dann über JDBC aufrufen.

Wenn Vorgaben technische Wege als Randbedingung enthalten, und Murks sind, dann ist der Murks halt gewollt, aber immer noch Murks.

D*B

Der Garbage Collector der JVM auf der iSeries fühlte sich offensichtlich überhaupt nicht motiviert, die nicht mehr benötigten AS400-Instanzen wegzuräumen, denn beim Stoppen des WAS (in dem die Applikation läuft) sind die Jobs alle über den Status EOJ verschollen. (Und seit der Implementation des ConnectionPools nie wieder in größerer Zahl aufgetaucht.



Du meinst die auszuführenden Kommandos dann in RPG/CL zusammenfassen und das als Stored Procedure über JDBC ausführen?




Ich schiebe das Auto nicht einmal, ich lasse es stehen. ;-)

Der Grund für SCS-Druck aus Java ist das Erzeugen von Spool-Files, die mit Interform dann gemapped werden. Ich weiß, daß es zig API's unter Java gibt, die formatieren und Barcodes erzeugen und was weiß ich noch alles können, aber es war nunmal die Vorgabe... ;-)

Vielen herzlichen Dank nochmal!

Gruß

Christian