-
 Zitat von 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.
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.
 Zitat von AS400.lehrling
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.
 Zitat von camouflage
Ja so ähnlich würde ich's dann machen den Recordlock abzufragen.
Danke noch mal an alle für die Hilfe und die Geduld!
-
... 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
-
 Zitat von 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.
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
-
... 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
-
 Zitat von BenderD
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
 Zitat von BenderD
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...
 Zitat von BenderD
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?
-
 Zitat von bofrost
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
-
 Zitat von BenderD
... 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
- 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.
 Zitat von BenderD
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?
 Zitat von BenderD
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...
 Zitat von BenderD
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?
-
 Zitat von bofrost
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
Similar Threads
-
By cassi in forum NEWSboard Drucker
Antworten: 5
Letzter Beitrag: 11-02-09, 14:10
-
By jo400 in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 21-10-06, 17:57
-
By Flo4711 in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 29-09-06, 17:31
-
By kruxelwuz in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 18-02-05, 07:16
-
By CZE425 in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 10-02-05, 12:35
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks