View Full Version : starten Group Job in einer Interaktiven Session "vom aussen"
Hi *all,
ich suche nach Ideen, wie man einen interaktiven Job vom aussen steuern könnte. Also:
an einem Arbeitsplatz wird nur eine CA 5250 Session gestartet. Grund dafür ist, dass es eine Fremdsoftware unter Windoof läuft, welche über ClientAccess API eine Verbindung mit 5250 Session aufbaut und ein Gruppen Job darin startet. Diese Software kann nur mit single Session umgehen.
Nun suche ich eine Möglichkeit, eine weitere Software - Dokumentnenmanagement - einzubinden. Aus DMS muss eine bestehende Anwendung in 5250 gestartet werden, um z.B. Vertragsdaten zu erfassen. Dafür sollte ein Group Job gestartet werden.
Frage ist, wie kann ich das Starten von Group Job in einer interaktiven Session "remote" (z.B. aus einem Batchjob, welcher Requests per WebServices empfängt) bewirken und ob es überhaupt geht?
Danke für Ideen und Grüße
Oleg Mints
Mit etwas Mühe geht alles.
Beim Start des Dialogjobs wird ja nun sicherlich ein CLP aufgerufen, dass zu verändern ist.
Das Stichwort ist hier MSGBREAK-Handler.
Per "CHGMSGQ MSGQ(MYMSGQ) DLVRY(*BREAK) PGM(MYPGM)" kannst du ein Programm aufrufen lassen, dass bei einem SNDBRKMSG an diese MSGQ dann aufgerufen wird.
In der Nachricht gibts du dann die Aktionen an.
Hier kannst du dann Gruppenjobs initiieren oder eben sonstwas tun.
Ein CHGMSGQ DLVRY(*BREAK) ist jedoch nur einmal je MSGQ möglich (exclusive Sperre), bekannte Nachricht bei der 2. Dialoganmeldung.
Der Dialogjob muss aber auch in einem unterbrechbaren Status stehen.
Bei Gruppenjobs wirds schwierig, da du je Job eine MSGQ benötigst da nur der gerade aktive Gruppenjob unterbrechbar ist und eben nur ein *BREAK je MSGQ möglich ist.
Wird ein Gruppenjob dann gewechselt schlägt der BreakHandler mit noch ggf. ausstehenden Nachrichten zu.
Viel Spaß beim Entwickeln.
Besten Dank!
Auf Break-Message habe ich auch schon gedacht, allerdings längst nicht so tief - vor allem, dass es mehrere Queues benötigt werden etc. ;-)
Ich checke mal, ob diese Lösung überhaupt möglich ist: ich weiss momentan nicht, was bestehende Programmen mit MSGQueues einstellen (es laufen u.a. SYNON & Co). Doppelschläge von Handler kann ich z.B. dadurch vermeiden, dass die eigentliche Nachricht nicht über MSGQ, sondern z.B. über DTAQ zugestellt wird.
Mal sehen - eine dedizierte Anwendung in einer eigener Session wäre mir viel lieber.
Noch mal vielen Dank für deine Hilfe und schöne Grüße
Oleg
P.S. Alles ist möglich, es ist nur eine Frage des Aufwandes...
Da du für deine Anwendung sowieso spezialisierte MSGQ's benötigst, die in einer eigenen Lib stehen sollten, kommst du nicht in Verdrückung mit Anwendungskonflikten.
Für deinen Service muss sich ein Job "registrieren", MSGQ anlegen und einem "Servicejob" seinen Namen mitteilen.
Dies wird am Besten über eine eigene ACTGRP erledigt, so dass dies von der laufenden Anwendung getrennt ist.
Per Commitsteuerung lässt sich dann eine Commitressource registrieren, die beim Abmelden des Jobs, Abbruch oder ähnlichem Beenden für eine saubere "Deregistrierung" sowie löschen der MSGQ sorgt, da das System diese beim Rollback immer aufruft.
Wie läuft das mit dem ClientAccess API? Wird da eine 5250-Sitzung per Programm "bedient"? Falls ja, wäre vielleicht ein Abrufprogramm (setzen mittels SETATNPGM), das selber einen (eigenen) Befehl zum Auswählen des jeweiligen Gruppenjobs aufruft, eine Möglichkeit. Per 5250-Datenstrom müßte dann die "Abruftaste", der "Parameter für den gewünschten Gruppenjob" sowie "Datenfreigabe" an die 5250-Sitzung gesendet werden.
Dies würde ein Anpassung der "Fremdsoftware" voraussetzen, was wohl nicht so einfach sein wird.
... wenn ich das mit den Break Message Handlern noch richtig im Kopf habe, dann wird das Break Handling Programm in dem Job ausgeführt, der den Fokus für die MessageQ hat und auch nur dann, wenn dieser Job das Break Handling Programm nicht im Call Stack hat (<=> bereits ausführt). D.h. wenn ich das ganze Spiel in einem Gruppenjob Kontext spiele, dann muss ich den Fokus jeweils irgendiwe vererben auf den gerade aktiven Gruppenjob... ob das wohl geht???
Da der Gruppenjob-Wechsel programmtechnisch nicht bemerkt werden kann, kann man eine blockierte MSGQ DLVRY(*BREAK) nicht freigeben. Ein 2. CHGMSGQ geht daher nicht.
Jeder Gruppenjob ist ein eigener Job.
Man kann nur per Job-API feststellen, welcher Gruppenjob aktiv ist.
Der Status kann sich aber bereits nach Aufruf des API's geändert haben.
Solche Szenarien sind zwar irgendwo technisch machbar und interressant, aber man sollte sich überlegen ob es nicht was besseres gibt.
Warum kann man sich für die neue Anwendung nicht einfach eine neue Terminalsitzung außerhalb der anderen Anwendung aufmachen?
Wenn man die betreffende Nachrichtenwarteschlange beim CHGGRPA im Parameter MSGQ() angibt, müßte sie immer dem aktiven Job dieser Gruppe zugeordnet sein.
@Fuerchau: "Warum kann man sich für die neue Anwendung nicht einfach eine neue Terminalsitzung außerhalb der anderen Anwendung aufmachen?"
Liegt an "Fremdsoftware" & CA API. In CA API muss gesagt werden, mit welchen Session die Verbindung aufgebaut werden soll. Bei mehreren aktiven Sessions muss wie auch immer ausgewählt werden. Im aktuellen Fall bindet sich "Fremdsoftware" an Session 'A'. Dies heisst, dass die Reihenfolge des Startens von Sessions muss beachtet werden. Abgesehen davon möchte ich nicht wirklich ein Windoof's Programm schreiben welche dann CA voraussetzt.
@BenderD: "D.h. wenn ich das ganze Spiel in einem Gruppenjob Kontext spiele, dann muss ich den Fokus jeweils irgendiwe vererben auf den gerade aktiven Gruppenjob... ob das wohl geht???"
Ich bin grad am ausprobieren was geht, was nicht und warum. Mit dem Fokus sehe ich kein Problem, solange ich Vollmach bekomme bei jedem Jobstart ein Registrierrogramm ausführen, welches dann per je (Group)Job "Rollback"-Händler registrert, dedizierte MSGQ erstellt und CHGMSGQ mit DLVRY(*BREAK) für entsprechenden Händler ausführt. Fokusproblem bekomme ich erst dann, wenn dieses Registrierprogramm nicht ausgeführt wird. So 'ne Machbarkeitsstudie...
Ev. wird es doch ganz einfach gemacht: eine Alternative zu IBM i Access for Windows installieren (Mocha, IBM i Access Javabasierend etc.) - dann kann ich es doch in einer separaten Session laufen lassen ohne Fremdsoftware zu beeinträchtigen.