starten Group Job in einer Interaktiven Session "vom aussen"

[BenderD]

... 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???

[Fuerchau]

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?

[Pikachu]

Wenn man die betreffende Nachrichtenwarteschlange beim CHGGRPA im Parameter MSGQ() angibt, müßte sie immer dem aktiven Job dieser Gruppe zugeordnet sein.

[OMi]

@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.

[Fuerchau]

Da ja wohl CA installiert ist, kannst du doch jederzeit individuelle Sitzungen außerhalb der Anwendung starten. Wo also liegt da das Problem?

[OMi]

Das Problem liegt an Fremdsoftware. Diese stellt MS Word Macros zur Verfügung, welche dann per ClientAccess emulation APIs bestimmte Bisdschirmbereiche aus einer Sitzung auslesen und in ein Word Dokument einfügen.

In Grunde passiert also das, was Pikachu beschieben hat: es wird eine Verbindug mit Sitzung A aufgebaut und dort u.a. ESC emuliert. Bei vorhandensein von mehreren Sitzungen geht allerdings das ganzes durcheinander.

Und ich muss mich irgendwie dort einklinken...