Message von Serverjob auslesen und beantworten

[TSchuler]

Hallo,

ich habe eine Client/Server Anwendung, bei der der Client unter VB.NET geschrieben ist und via DataQueue mit diversen Server-Programmen auf der iSeries kommuniziert. Über diese Schiene kann der Client auch den Status des Server-Jobs abfragen. Allerdings kann sich der Client momentan nur selber beenden, falls der Server-Job nicht mehr läuft oder auf MSGW steht.
Ich würde nun gerne in dem Fall, dass der Server-Job auf MSGW steht, die Fehler-Message von einem iSeries-Programm (in einem separaten Job) auslesen und an den Client schicken lassen. Dort soll die Message dem User angezeigt werden und der User soll dann die Möglichkeit habe, die jeweilige Antwort einzugeben, welche der Client dann wieder an ein Server-Programm senden soll um die Nachricht zu beantworten.

Ich habe mich schon durch zig Foren gekämpft und im Internet gesucht, aber ich finde keine Möglichkeit um
a) die Fehlernachrichten eines anderen Jobs auszulesen
b) eine Antwort an einen anderen Job zu schicken

Geht so etwas überhaupt. Auch auf dem Umweg über die MSGQ QSYSOPR bin ich nicht fündig geworden. Dort würden die Nachrichten ja auch stehen.

Danke und Grüße
Thomas

[BenderD]

... das ist m.E. schräges Design. Ein Server Job muss Multithreaded sein, der darf nicht auf einer Message klemmen.

D*B

[TSchuler]

OK - über den Begriff "Client/Server" lässt sich diskutieren. Was ich versucht habe zu erklären ist Folgendes: Ich habe ein VB.NET-Programm, welches eine Benutzeroberfläche emuliert. Dieses Programm kommuniziert via DataQueue mit einem Batch-Job auf der iSeries, in welchem die Business-Logik abläuft. Auch wenn das ein "schräges Konzept" sein sollte - es funktioniert und wird bei uns fast schon weltweit eingesetzt.

Um das Design ging es mir aber gar nicht.

Da auch unsere Business-Logik nicht fehlerfrei ist, kann es vorkommen, dass der Batch-Job auf der iSeries mit MSGW hängen bleibt. In dem Fall wartet das VB.NET Programm vergeblich auf eine Rückmeldung. Nach einem Timeout wird bisher dann der Status des Batch-Jobs geprüft. Wenn dieser auf MSGW steht, erhält der User eine Mitteilung, dass "etwas" nicht stimmt und kann dann entscheiden, ob er weiter warten möchte (bis eventuell jemand die Message auf der iSeries beantwortet hat) oder ob er das VB.NET Programm abbrechen will.
Hier wäre es jetzt schön, wenn der User die tatsächliche Message angezeigt bekommen würde und ggf. auch beantworten könnte.

Deshalb nochmal konkret die Fragen:

- Ist es möglich, die Fehlermessage eines Job, der auf MSGW steht, von einem anderen Job aus auszulesen?
- Ist es möglich, die Fehlernachricht von einem anderen Job aus zu beantworten?

Grüße
Thomas

[jochen88250]

Hallo,
alternative, schreib ein kleines RPGLE Programm mit einer Schleife
Loop
DLYJOB
QUSLJOB und dann QUSRJOBI mit Format 0200 (alle Deine Jobs auslesen und dann auf *MSGW prüfen)
Wenn gefunden -> Nachricht an den JOB senden mit SNDMSG
Endloop

Im ClientJob -> Im Startpgm ein ATTN Pgm hinterlegen, dieses empfängt dann die Nachricht vom ServerJob

JS

[andreaspr@aon.at]

Deshalb nochmal konkret die Fragen:

- Ist es möglich, die Fehlermessage eines Job, der auf MSGW steht, von einem anderen Job aus auszulesen?
- Ist es möglich, die Fehlernachricht von einem anderen Job aus zu beantworten?

Klar geht das. Wenn du in einer 5250 Sitzung ein DSPMSG MSGQ(*SYSOPR) absetzt und die Nachricht beantwortest machst du ja auch nichts anderes.

lg Andreas

[Fuerchau]

Nun, das ist nicht ganz so trivial.
Allerdings gibt es eine bessere Alternative.
Mach einen CHGJOB INQMSGRPY(*DFT) im Start-CLP.
Dann werden keine Antworten erwartet sondern die Standardantwort (meist Abbruch) gesendet.
Nun noch per MONMSG den CALL des Serverjobs überwachen und entsprechend reagieren.

[Robi]

beschäftige dich mit STRWCH
Damit kannst du dein problem lösen
Warscheinlich mußt du noch das (ehemalige) wrkfrgnjob (heist heute anders, aber google oder das forum
hilft) verwenden um die Nachricht an den anderen Job zu bekommen

Robi

Nee, das mit dem wrkfrgnjob brauchst du warscheinlich doch nicht!

[TSchuler]

Hallo zusammen,

danke für alle Antworten. Ich habe es jetzt doch anders gelöst.

Der Serverjob bekommt jetzt eine eigene MSGQ zugewiesen (im SBMJOB => MSGQ). Dort drin wird zwar nicht die eigentliche Fehlernachricht abgelegt, aber wenigstens die Message CPI2404 - Antwort auf Nachricht in Nachrichtenwarteschlange QSYSOPR erwartet. Im Second-Level Text steht da dann auch die Fehlernachricht mit drin. Diese MSGQ kann ich problemlos überwachen und auslesen (weil sie im Gegensatz zur MSGQ QSYSOPR nicht gelockt ist).

Ich gebe jetzt einfach die komplette CPI2404 Meldung auf dem Client aus (mit Second-Level Text). Dann kann der User zwar nicht direkt auf die Nachricht antworten, aber er sieht zumindest detaillierter, welches Problem aufgetreten ist und dass eine Nachricht in QSYSOPR zu beantworten ist.

Grüße
Thomas

[TSchuler]

Danke für den Tipp. Über den Parameter INQMSGRPY bin ich zwar auch schon gestolpert, habe ihn aber nie konkret benutzt. Das werde ich mir auf jeden Fall merken.

Für mein aktuelles Problem ist das aber nicht ausreichend. Ich möchte ja eigentlich nicht unbedingt, dass der Serverjob abgebrochen wird. Manchmal ist es ja möglich, mit Retry oder Go zu antworten, nachdem ein Problem behoben ist.

Ich habe es jetzt ganz anders gelöst (siehe meine Antwort unten).

Grüße
Thomas

[TSchuler]

Hallo Robi,

danke für die Antwort. STRWCH kannte ich bisher noch nicht. Das werde ich mir mit Sicherheit noch genauer anschauen.

Mein aktuelles Problem habe ich jetzt aber doch simpler gelöst. Siehe meine Antwort unten.

Grüße
Thomas