Trigger auf Record Lock

[bofrost]

Könnte da nicht übel zwischen hacken und jeden usr mehrere Virtuelle unter usr zuordnen

Dann ließe sich jeder Anzeigebereich quasi als eingen ständige 5250 emu einrichten.

Wie gesagt übler hack

AS400.lehrling

Hm... das erinnert mich an die Anwendung die ich dem Letzt im Reisebüro gesehen habe Die arme Frau hinter dem Bildschirm hat sich damit ganz schon schwer getan

Naja "übel" und "hack" hören sich für mich nicht ganz so überzeugend an
aber bei mir geht die Kommunikation ja eh nicht mehr über 5250 sondern über websockets und json Daten. Man kann natürlich weiter JOB's starten, nur dass stell ich mir schwierig vor die alle zu verwalten und miteinander kommunizieren zu lassen. Und Threads gehen leider auch wegen dem JobAccounting nicht

Wie funktioniert denn deine neue Anwendung wenn gar keine Satzsperren vorliegen würden ?
Was machst du dann mit konkurierenden Updates (letzter gewinnt) ?

Naja letzter gewinnt ist ja wohl keine Lösung, sondern nur das was passiert, wenn man sich gar nicht drum kümmert...

Also am Anfang wollte ich den Satz auch sperren lasse, wenn ein User in editiert.

Nehmen wir an wir haben eine Tabelle mit Sätzen und daneben ein Formular, dass die Details anzeigt und die Möglichkeit bietet den Satz zu editieren. Markiert der User einen Satz in der Tabelle soll er gelesen werden und im Formular angezeigt werden, durch einen Button gelangt der User in den bearbeiten Modus.
Klickt ein anderer User auf denselben Satz wird dieser auch angezeigt klickt er auf den Bearbeiten-Button soll über dem Formular die Information angezeigt werden, dass der Satz gesperrt ist und darauf gewartet wird bis der Satz wieder frei ist. Möchte der User aber nicht warten und mit einem anderen Satz weiter machen kann er den einfach in der Tabelle anklicken.

Das geht aber nicht, wenn das Programm auf den LOCK wartet! Weil der Prozess blockiert wird und die GUI nicht mehr reagiert...

Also müsste ich die Wartezeit auf den Recordlock heruntersetzen wie du mir ja schon des Öfteren vorgeschlagen hast.

Dann würde es aber nicht mehr funktionieren auf Satz zu warten...

Also anscheinend gibt es hier keine Universallösung die wirklich komfortabel für die User ist.

Vlt sollte ich für dateien, die nur von neuen Anwendungen verwendet werden eine komfortable Lösung bauen und beim zugriff auf eine nach der alten Methode gesperrten Datei bekommt man einfach die Fehlermeldung: "Satz wird von Hans Jürgen gesperrt, bitte versuchen sie es später nocheinmal."

[Fuerchau]

Wenn der User ja die Entscheidung trifft auf den Satz zu warten, kannst du doch über eine Schleife mit kleinem Delay (läuft doch auf dem Web-Client?) z.B. alle 100ms versuchen die Satzsperre (bei *immed) zu erhalten bis es klappt. Hier hat der User sogar noch die Eingriffmöglichkeit den Wartevorgang abzubrechen.

Ein Batchjob oder Thread hilft da ggf. auch nicht, da ein anderer Job trotzdem den Satz vorher erhalten könnte (Job A Wartezeit abgelaufen, Job B noch wartend, Job A macht neuen Chain und liegt nun hinter Job B in der Lock-Queue).

[AS400.lehrling]

Hm... das erinnert mich an die Anwendung die ich dem Letzt im Reisebüro gesehen habe Die arme Frau hinter dem Bildschirm hat sich damit ganz schon schwer getan

Naja "übel" und "hack" hören sich für mich nicht ganz so überzeugend an
aber bei mir geht die Kommunikation ja eh nicht mehr über 5250 sondern über websockets und json Daten.

Wenn du eh schon Javascript benutzen möchtest weshalb nicht gleich komplett in Java & Client seitig mit Standard WebPlugin Arbeiten ?

Quasi das weiterführen was IBM mit WebShare probiert hat

Java läuft auf der i ja Serverseitig, müsste man nur schauen wie man sql Abfragen ins Java bekommt.

Oder liege ich jetzt völlig falsch

Gruß AS400.lehrling

[camouflage]

Vielleicht versuchst du es mal mit dem hier...
Midrange Guru - OS/400 Edition

[bofrost]

Wenn der User ja die Entscheidung trifft auf den Satz zu warten, kannst du doch über eine Schleife mit kleinem Delay (läuft doch auf dem Web-Client?) z.B. alle 100ms versuchen die Satzsperre (bei *immed) zu erhalten bis es klappt. Hier hat der User sogar noch die Eingriffmöglichkeit den Wartevorgang abzubrechen.

Ja werd ich wohl so machen müssen, halte zwar nichts von lösungen bei denen der client immer nachschauen muss ob ein Status eingetreten ist.. aber wenns nicht ander geht...
Das würde dann im RPG-Client-Programm laufen, der Webpart ist nur reine Anzeige "ohne" Logik.

Wenn du eh schon Javascript benutzen möchtest weshalb nicht gleich komplett in Java & Client seitig mit Standard WebPlugin Arbeiten ?

Quasi das weiterführen was IBM mit WebShare probiert hat

Klar könnte man alles in Java schreiben, wir haben uns auf grund der großen know-hows in rpg allerdings dafür entschieden weiter RPG zu programmieren.

Vielleicht versuchst du es mal mit dem hier...
Midrange Guru - OS/400 Edition

Ja so ähnlich würde ich's dann machen den Recordlock abzufragen.

Danke noch mal an alle für die Hilfe und die Geduld!

[BenderD]

... wenn ich das alles zusammen richtig verstehe, habt ihr ein Web basiertes User Interface, das über Java Script Teile eine Event driven Anwendung darstellen soll.
Dahinter hängt dann ein (in Zahlen 1 ?) RPG Programm, mit dem dann die Kommunikation über DataQ erfolgt und das Problem besteht jetzt darin, dass das UI autistisch wird, wenn das RPG Programm in eine Wartebedingung geht?
Das ist aber dann doch auch so, wenn das RPG Programm für etwas ein wenig länger braucht.
D*B

[bofrost]

... wenn ich das alles zusammen richtig verstehe, habt ihr ein Web basiertes User Interface, das über Java Script Teile eine Event driven Anwendung darstellen soll.
Dahinter hängt dann ein (in Zahlen 1 ?) RPG Programm, mit dem dann die Kommunikation über DataQ erfolgt und das Problem besteht jetzt darin, dass das UI autistisch wird, wenn das RPG Programm in eine Wartebedingung geht?
Das ist aber dann doch auch so, wenn das RPG Programm für etwas ein wenig länger braucht.

Das verstehst du genau richtig... alles was länger dauert blockiert die View und muss als sbmjob ausgelagert werden der dann per Event (DataQ eintrag) das Programm wieder informiert.
Für Ideen und Verbesserungsvorschläge bin ich gerne offen... Allerdings eventuell in einem anderen Forumbeitrag, weil wir von Thema ja schon etwas abgekommen sind

[BenderD]

... oder beim Thema angekommen. Das bedeutet doch nichts anderes, als das sich die Events in der DataQ stauen, wenn der Benutzer schneller als das Backend ist.
Normalerweise werden die Events jeder für sich in einem separaten Thread abgearbeitet und das geht hier auch nicht anders, ansonsten stirbst du immer wieder diesen Tod, dass das UI einfriert.
Wenn die RPG Komponenten zustandslos sind (ich fürchte sie sind es nicht), dann könnte man das relativ schnell abmildern, indem man mehrere Listener auf die DataQ setzt, die dann parallel abarbeiten, aber dann muss die gesamte Synchronisation im "Frontend" stattfinden.
Was für eine Komponente macht denn die Darstellung und schreibt und liest die DataQ? Ist das Java in einem Tomcat? oder .NET in einem IIS, oder so ein Zauberkasten (wenn ja welcher)?

D*B

[bofrost]

Normalerweise werden die Events jeder für sich in einem separaten Thread abgearbeitet und das geht hier auch nicht anders, ansonsten stirbst du immer wieder diesen Tod, dass das UI einfriert.

Ok also ist mein Problem eigendlich, dass Threads nicht mit CHGACGCDE funktionieren

Wenn die RPG Komponenten zustandslos sind (ich fürchte sie sind es nicht), dann könnte man das relativ schnell abmildern, indem man mehrere Listener auf die DataQ setzt, die dann parallel abarbeiten, aber dann muss die gesamte Synchronisation im "Frontend" stattfinden.

Naja wenn ich ein zustandsloses Backend wollen würde könnte ich auch gleich CGIDEV nehmen...

Was für eine Komponente macht denn die Darstellung und schreibt und liest die DataQ? Ist das Java in einem Tomcat? oder .NET in einem IIS, oder so ein Zauberkasten (wenn ja welcher)?

Der Client verbindet sich per Websocket auf einem Jetty Web-Server auf der AS400, der wiederum RPG-Jobs startet und mit diesen per DTAQ kommuniziert.

Beim Starten wird eine Portal-App gestartet, aus der man weiter Programme Starten kann. Zwischen den einzelnen View's und den Jobs besteht dann immer eine 1 zu 1 verbindung.

Jobs Untereinander können aber auch an andere Jobs über die DTAQ nachrichten schicken.

Über die DTAQ können nicht nur Events verschickt werden sondern auch Prozeduren aufgerufen werden. Hier wird eine Rückantwort verlangt, die dann eine callBack prozedur auslösen kann.

Die geschwindigkeit der VIEW ist bei den bis jetzt umgesetzten Anwendungen recht gut. Aber klar wenn im Programm eine Verarbeitung länger dauert stauen sich die Events auf und werden erst verarbeiten wenn die Verarbeitung gemacht ist.

Vlt sollte ich bei jedem event ein rotes X unten anzeigen und warten bis eine Antwort zurückkommt?

[BenderD]

Ok also ist mein Problem eigendlich, dass Threads nicht mit CHGACGCDE funktionieren

Beim Starten wird eine Portal-App gestartet, aus der man weiter Programme Starten kann. Zwischen den einzelnen View's und den Jobs besteht dann immer eine 1 zu 1 verbindung.

Über die DTAQ können nicht nur Events verschickt werden sondern auch Prozeduren aufgerufen werden. Hier wird eine Rückantwort verlangt, die dann eine callBack prozedur auslösen kann.

Vlt sollte ich bei jedem event ein rotes X unten anzeigen und warten bis eine Antwort zurückkommt?

... der CHGACGCDE scheint mir nicht das Problem zu sein, der könnte ja im initial thread erfolgen, wenn ich das auf die Schnelle richtig gelesen habe --- aber --- die RPG runtime ist natürlich nicht so wirklich für multithreaded geeignet. Thread(*serialize) könnte Klemmer produzieren, bei Thread(*concurrent) gibt's Probleme mit shared Memory (da hat man keinen) und mit der Synchronisation muss man eh alles zu Fuß machen.
Man könnte allerdings auch darüber nachdenken einen eigenen Scheduler auf die Q zu setzen und Workerprozesse selber zu starten und denen den Zustand als globale Sessioninfo (evt. Userspace) zu vererben.

Das mit der PortalApp und den callback Prozeduren hört sich für micht etwas home grown an und das skizzierte Threading ist das auch - warum habt ihr euch hier für soviel Exotik entschieden, ich wäre da näher an den Mainstream gegangen...

Das mit dem X hätte ich fast vergessen, das ändert eigentlich nur, dass der Benutzer früher merkt, dass da was klemmt.

D*B

[bofrost]

... der CHGACGCDE scheint mir nicht das Problem zu sein, der könnte ja im initial thread erfolgen, wenn ich das auf die Schnelle richtig gelesen habe

1. This command is conditionally thread safe. Access will be denied if the job being changed has secondary threads active. This command may be issued from either the initial thread or a secondary thread of a multi-threaded job if the target job is single threaded.

Stimmt, hört sich so an, als dürfte der Job zum Zeitpunkt des Aufrufs nur keine Threads haben.

die RPG runtime ist natürlich nicht so wirklich für multithreaded geeignet. Thread(*serialize) könnte Klemmer produzieren, bei Thread(*concurrent) gibt's Probleme mit shared Memory (da hat man keinen) und mit der Synchronisation muss man eh alles zu Fuß machen.

Naja wenn ich's auf *serialize stell kann ich's gleich lassen, weil dann läuft ja trotzdem alles nacheinander ab. Mit den pthread funktionen und den shared memory Funktionen sollte es doch kein Problem sein die Anwendung multithreading fähig zu machen?

Man könnte allerdings auch darüber nachdenken einen eigenen Scheduler auf die Q zu setzen und Workerprozesse selber zu starten und denen den Zustand als globale Sessioninfo (evt. Userspace) zu vererben.

Hm... gut das wäre dann Threading nachgebaut... dann lieber richtiges threading...

Das mit der PortalApp und den callback Prozeduren hört sich für micht etwas home grown an und das skizzierte Threading ist das auch - warum habt ihr euch hier für soviel Exotik entschieden, ich wäre da näher an den Mainstream gegangen...

Naja wir verwenden am Client ExtJS, hier gibt es ExtDirect Funktionen die einen Zugriff auf den Server erlauben hier wird auch oft mit solchen Callback-Funktionen gearbeitet... Was für Mainstream Lösungen gibt es den in dem Bereich für RPG die empfehlenswert sind?

[BenderD]

Naja wenn ich's auf *serialize stell kann ich's gleich lassen, weil dann läuft ja trotzdem alles nacheinander ab. Mit den pthread funktionen und den shared memory Funktionen sollte es doch kein Problem sein die Anwendung multithreading fähig zu machen?
Hm... gut das wäre dann Threading nachgebaut... dann lieber richtiges threading...

Naja wir verwenden am Client ExtJS, hier gibt es ExtDirect Funktionen die einen Zugriff auf den Server erlauben hier wird auch oft mit solchen Callback-Funktionen gearbeitet... Was für Mainstream Lösungen gibt es den in dem Bereich für RPG die empfehlenswert sind?

RPG und Multithreading, da ist man dann Beta Tester! Ich weiß von niemandem, der das wirklich nutzt und dass es da wirklich Support gibt, bezweifele ich heftigst.

*serialize serialisiert auf Module Ebene, das geht vom Ansatz schon, man muss nur sicher sein, dass man keine rekursiven Modul Aufrufhierarchien bekommt.

*concurrent hat den Haken, dass der komplette static storage für jeden Thread dupliziert wird, da muss man sich was einfallen lassen, damit man doch wieder shared memory hat.

wandelt man einfach ohne eine der beiden Optionen, weß man nicht, welche Kontrollbereiche der runtime ungeschützt im shared memory liegen.

Alternativen zu der ExtJS - RPG Architektur, da fühle ich mich aus dem Bauch überfragt und da ist auch der Informationsstand hier im Forum zu dünn. Was mich gefühlsmäßig stört (und meist stimmt sowas bei mir) ist die Erhöhung des Komplexitätsgrades im RPG Teil im Vergleich zur Altanwendung - und das sollte bei Neudesign unter Verwendung vorhandener Komponenten genau umgekehrt sein.

mfg

Dieter Bender