Java SFTP Client mit stdin Fehler

[jaimosky]

Hallo,

Wir haben eine Java Klasse programmiert um eine SFTP Verbindung zu bauen und Dateien abzuholen(com.jcraft.jsch)

Diese wird durch RUNJVA ausgeführt (Command gebastelt und dann in ILE Programm qcmdexc gelaufen)

Das läuft in eine Schleife, die jede Minute die QCMDEXC ausführt.

Normaleweise läuft das ohne Problem, nur heute haben wir haben gesehen, wenn wir die QCMDEXC ausführen, bekommen wir den Fehler:


Weitere Nachrichteninformationen

Nachrichten-ID . . . . : JVAB546 Bewertung . . . . . . : 30
Nachrichtenart . . . . : Abbruch
Sendedatum . . . . . . : 08.03.18 Sendezeit . . . . . . : 10:02:12

Nachricht . . . : Fehler beim Ausführen von Java im Stapelmodus erkannt.
Ursache . . . . : Während Java im Stapelmodus ausgeführt wurde, wurde ein
Fehler erkannt. Der Ursachencode ist 2. Die Fehlernummer ist 3452. Die
Ursachencodes haben folgende Bedeutung:
1 -- Pipe für Ausgabe konnte nicht erstellt werden.
2 -- Stapel-STDIN-Nulldatei konnte nicht geöffnet werden.
3 -- Erstellung des Child-Prozesses fehlgeschlagen.
4 -- Lesepuffer konnte nicht zugeordnet werden.
Fehlerbeseitigung: Ist der Ursachencode 3, die maximal zulässige Anzahl Jobs
mit dem Befehl WRKSBSD ändern. Andernfalls den Fehler mit dem Befehl ANZPRB
(Problem analysieren) melden.



Wenn wir den SBS, wo den Job läuft, geendet wird und neu gestartet dann läuft wieder normal.

Irgendjemand hätte eine Idee, was wäre hier das Problem?

Danke für eure Hilfe.

[BenderD]

... habe ich das jetzt richtig verstanden, ihr startet im Minutentakt eine JVM? Wie kommt man denn auf so eine Idee? Habt ihr zuviel Hardware? Heizt ihr mit der Büchse? Hat euch IBM das empfohlen?

D*B

[jaimosky]

Nein, wir holen nicht alle Minuten. Wir schicken zwischen 5 und 10 Dateien am Tag, und wir sollten die Bearbeitungsbestätigung abholen. Diese ist normaleweise nach eine Minute zu haben, so am Tag rufen wir diese RUNJVA ca. 30 mal (höchstens). Aber die Schleife läuft weiter in Hintergrund.

[KM]

Hier würde ich empfehlen das Ganze auf einen externen Server auszulagern (z.B. Tomcat) und eine Kommunikation zwischen diesem und der AS/400 z.B. über Dataqueues herzustellen. Wir machen das seit vielen Jahren so und arbeiten auch mit SFTP-Verbindungen über com.jcraft.jsch. Und bis jetzt hatten wir nie Probleme damit. Es gab keine Fehler und auch die Performance ist optimal.

Gruß,
KM

[andreaspr@aon.at]

Hallo,

Für mich sieht es so aus als ob innerhalb der Java-Welt eine Exception geworfen wird die nicht abgefangen wurde.
Ich würde um genauere Infos zu erhalten:
* Exception Handling einbauen
* Logger verwenden
* Die STDOUT (Konsolenausgabe) vom Job ebenfalls irgendwohin protokollieren. Falls irgendwo eine nicht abgefangene Exception geworfen wird dann siehst du die da drinnen. (Sollte aber natürlich eigentlich nie passieren.)

Damit ist eine Analyse generell mit Java viel einfacher.
Die Probleme können an verschiedensten Stellen zu finden sein.

lg Andreas

[BenderD]

... da kennste aber diesen unsäglichen jt400 Krampf schlecht, die schmeißen an den unmöglichsten Ecken RuntimeExceptions.

D*B


Falls irgendwo eine nicht abgefangene Exception geworfen wird dann siehst du die da drinnen. (Sollte aber natürlich eigentlich nie passieren.)

lg Andreas

[andreaspr@aon.at]

Ja, aber und deshalb bedarf es auch ein Exception-Handling Konzept.
Man muss ja nicht jedes mal ein Try-Catch machen sondern kann auch mögliche Exceptions in der Funktion declarieren:

public void myMethod() throws Exception {
Irgendwann muss diese halt abgefangen werden (spätestens im main()).

[BenderD]

... das tückische an RuntimeExceptions ist, dass die eben nicht deklariert werden müssen. Wenn Dir nun aus den Tiefen des Toolbox Scharmonzes eine Runtime Exception entgegen kommt - hilft Dir der Compiler nicht weiter. Wer rechnet schon damit, dass er jeden Mist in eine packed verwandeln kann und ihm dann beim rückverwandeln des Wertes eine Runtime Exception um die Ohren fliegt.

D*B