das eigentliche Problem ist ja der RPG oder COBOL Schinken mit dem 5250, der kein Multithreading kann und entweder an der DataQ wartet, oder den Benutzer weiter arbeiten lässt. Wenn es nur um den Trappatoni geht, dann kann man das auch ganz aus dem Java draußen lassen. Sprich:
- dein interaktiver Job startet einen Job per Submit und greift sich die Jobnummer aus der Start Message, erstellt dann eine MSGQ Qxxxxxx (wobei xxxxxx Jobnummer des Tochterjobs) und hängt einen Breakhandler an diese Q (gelöscht wird diese Q dann am Besten aus einem ILE Exithandler, CEE4RAGE ist dein Freund).
- der Tochterjob startet den Javaprozess und holt sich nach Completion desselben seine eigene Jobnummer und stellt "Ich habe fertig" in die Qxxxxxx
- der Breakhandler macht daraus, was immer er will

D*B

Zitat Zitat von Fuerchau Beitrag anzeigen
Stimmt genau, Dieter.
Per BREAK-Handler wird die Nachricht nun aus einer MSGQ gelesen und als Statusnachricht ausgegeben. Das funktioniert auch so weit ganz gut.

Das kleine Problem hier ist noch (aber das interressiert erst mal nicht mehr weiter), dass man leider keine MSGQ in der QTEMP verwenden kann.
Man benötigt also bei Parallel-Betrieb je Job eine eigene MSGQ, da eine MSGQ nur von einem Job in *BREAK überwacht werden kann.
Diese MSGQ muss dann noch als zusätzlicher Parameter an das Java-Programm übergeben werden.

Wenn man ansonsten noch sieht, was die AS/400 da so treibt:
1 QSH-Job
1 Java-Job
1 QZDA-Job (ODBC-Zugriffe)

Der Umweg über die QSH ist nötig, da ich noch diverse Aufgabe als Script mit ausführe (geht auch sicherlich einfacher).

Mal sehen, vielleicht mache ich da doch noch mal eine RPGLE/Java-Mischung um über eine Keyed-DTAQ zu gehen.
Das Transferprogramm läuft dann als Thread und das Hauptprogramm wartet über die DTAQ auf Ende.

Ich weiß allerdings nicht, ob ich aus RPGLE zwar eine Klasse aufrufen kann, diese eine Thread startet und das RPGLE dann auch zurückkomt.

Ich werde da noch einiges ausprobieren.