View Full Version : Statusanzeige aus Java-Programm
Mal ein anderes Problem.
Ich starte Java per QSH im interaktiven Job.
Da dieses Java-Programm jedoch in einem eigenen Job/Thread läuft, kann ich leider keine Status-Nachricht (SNDPGMMSG ... *STATUS ...) über den Fortschritt ausgeben.
Der Call auf ein AS/400-Programm funktioniert zwar ohne Probleme, am Display wird aber leider nichts ausgegeben.
Hat irgendwer eine Idee, wie man aus dem interaktiven Javaprogramm eine Nachricht auf Zeile 24 ausgeben kann (eben analog zu SNDPGMMSG).
Das API QMHSNDPM funktioniert allerdings auch nicht.
Hallo,
ich hab es noch nicht exakt nachvollzogen aber es sollte möglich sein den CallStack des Programms auszulesen und damit die QSH-Ebene zu identifizieren. Dann sollte man die Message an den entsprechenden Job eine Ebene höher senden können. Probiers mal aus. Bei Problemen hier nochmal posten. Dann teste ich selbst mal.
Gruß
Michael
Hallo Baldur,
willkommen bei der Java Fraktion.
Wir regeln eine Art von Benachrichtigung mit einer DTAQ.
Das Javaprogramm wird in einem Service gestartet. Dem
Service wird eine DTAQ mitgegeben. Das aufrufende Programm
horcht auf die DTAQ und gibt die Information weiter.
Das Problem im Javaumfeld ist das mehrere Jobs im System
ausgeführt werden. Je nachdem was im Javaprogramm gestartet wird. QZDASO.. QZRC... etc.
Ein solcher Aufbau lohnt sich natürlich nur wenn etwas
mehr mit Java gemacht wird.
Gruß
Michael
Es geht nicht um Einträge ins Joblog sondern um eine Bildschirmausgabe.
Sicherlich kann ich den Java-Job auch als Batch starten, was die Sache allerdings verkompliziert (Ende des Job's, Abbruch des Job's u.v.m.). Darüber werde ich später mal nachdenken.
Zur Zeit verwende ich i.W. den Java-Transfer von Dieter Bender, also kopieren der Daten von einer Tabelle in die andere über JDBC.
Im Normalfall rennt der Job eh als Batch, wo eine Fortschrittsanzeige nicht interressiert.
Aber der Dialogaufruf kommt nun mal doch vor und damit der Anwender den Job nicht killt wäre eine Statusanzeige hilfreich.
5250 und Java in einem Job geht nicht, es geht dann also darum aus einem Job in einem (anderen) interaktiven Job eine Statusmessage am Bildschirm anzuzeigen...
klingt mir nach Break Messagehandler, aus selbigem müsste man eigentlich dann eine Statusmessage an den eigenen Job senden können.
D*B
Es geht nicht um Einträge ins Joblog sondern um eine Bildschirmausgabe.
Sicherlich kann ich den Java-Job auch als Batch starten, was die Sache allerdings verkompliziert (Ende des Job's, Abbruch des Job's u.v.m.). Darüber werde ich später mal nachdenken.
Zur Zeit verwende ich i.W. den Java-Transfer von Dieter Bender, also kopieren der Daten von einer Tabelle in die andere über JDBC.
Im Normalfall rennt der Job eh als Batch, wo eine Fortschrittsanzeige nicht interressiert.
Aber der Dialogaufruf kommt nun mal doch vor und damit der Anwender den Job nicht killt wäre eine Statusanzeige hilfreich.
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.
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
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.
Ob Batch oder Dialog spielt da keine Rolle, da ich immer eine MSGQ mit Job-Nummer benötige.
Da es immer wieder Gründe für unkontrollierte Job-Abbrüche gibt, klappts halt mit dem Aufräumen nicht immer.
Die Gefahr, dass dadurch Objekte verwaisen, ist mir zu groß.
Es geht hier auch nur um Test-Dialoge, da später die Pogramme immer in Batch laufen.
Daher reicht mir z.Zt. eine einzige MSGQ, da die Nachrichten dann angezeigt werden können.
Sieht i.Ü. ganz nett aus.
das mit den unkontrollierten Abbrüchen, das macht der ILE ConditionHandler, selbiger muss eine definierte Schnittstelle haben und wird per CEE4RAGE registriert; die Runtime ruft selbigen beim Ende der Activation Group selbst beim ENDSBS noch auf und genau dort programmiert man die Aufräumarbeiten (Beispiel auch auf meiner OpenSource Seite : Instream hat sowas und GenFrame generiert diese Dinger mit).
Beim Submit könnte man natürlich auch normal end / abnormal End per Escape message oder über System.exit(nnn) machen, nnn = 0 ist normal end ansonsten abnormal - müsste eigentlich auch in der Completion Message durchgereicht werden.
D*B
Ob Batch oder Dialog spielt da keine Rolle, da ich immer eine MSGQ mit Job-Nummer benötige.
Da es immer wieder Gründe für unkontrollierte Job-Abbrüche gibt, klappts halt mit dem Aufräumen nicht immer.
Die Gefahr, dass dadurch Objekte verwaisen, ist mir zu groß.
Es geht hier auch nur um Test-Dialoge, da später die Pogramme immer in Batch laufen.
Daher reicht mir z.Zt. eine einzige MSGQ, da die Nachrichten dann angezeigt werden können.
Sieht i.Ü. ganz nett aus.
System.exit() funktioniert nicht als Fehlerausgang, wenn man Java aus der QSH aufruft.
Hierzu ist das JAVA-Kommando nötig (man spart sich dann den QSH-Job).
Allerdings bietet mir die QSH noch ein bisschen drumherum, was ich mit dem Kommando nicht kann.
Ich müsste dann noch mit STMF-Befehlen rumwerkeln.
Zu Zeit baue ich den Java-Aufruf per CLP komplett zusammen. Beispiel:
"cd /MyHome;
echo "Somthing " >in.properties;
echo "Somthing else " >>in.properties;
:
java -Dxxx -Dyyy -classpath zzzz myclass;
rm in.properties;
"
Klar müsste ich jetzt den Return von Java auswerten (if ...;fi; ) aber in der STDERR ist ja dann alles was ich brauche.