Trigger auf Record Lock

[Fuerchau]

Du kannst die Satzwartezeit auf 0 reduzieren !
Hierzu einfach einen OVRDBF FILE(MYFILE) WAITRCD(*IMMED) vor Programmstart (bzw. Open) im Job durchführen (habe ich oben schon mal erwähnt).
Dann brauchst du den ganzen anderen Kram nicht da du nicht wartest und sofort über die Satzsperre bescheidweißt.

Diesen ganzen anderen Schmonz brauchst du nicht!!!

Was die Locktabelle angeht, so kann man diese nur per API abgreifen.
Und nicht jede Datenbank hat eine Locktabelle als TABLE in der DB sondern arbeitet vernünftigerweise mit Semaphore oder ähnlichen sog. Atom-Funktionen.

[BenderD]

... so fangen Altlasten an:
- man mixe alle Schlagworte, die gerade aktuell sind miteinander
- man gehe allen Standards aus dem Weg
- man übernehme alle Schwächen aus Altsystemen
- erst programmieren, dann überlegen
- wenn man auf Probleme stößt, schlägt man den kompliziertesten Wege ein, um sein Knowhow unter Beweis zu stellen

D*B

[Fuerchau]

Nun ja, anders kann ich mich bei meinen Kunden auch nicht
a) profilieren
b) unabkömmlich machen
c) das große Geld machen

[AS400.lehrling]

Weshalb wird versucht den Gaul von hinten zu Satteln

1800 Anwendungen die wahrscheinlich schon seit 20 Jahren Arbeiten können nicht falsch liegen.

Bin mir ziemlich sicher das die Anwendungen unter CA oder WebShare genauso funktionieren wie auf einen GreenScreen

Probier doch mal aus wie es unter TN5250 oder Holgers Version funktioniert.

Holgers Version dürftest du hier finden Rechenzentrum Kreuznach - die AS/400-Profis

Es ist meiner Meinung nach ein Fehler in Browser Plugin bzw PGM das verwendet werden soll.

Bei Irrtum bitte korrigieren

Gruß AS400.lehrling

[bofrost]

Du kannst die Satzwartezeit auf 0 reduzieren !

Klar das muss ich sowieso, wenn der Client sofort antworten muss... aber das ändert am Ablauf trotzdem nichts... entweder ich lass den Ablauf gleich und sperr die Sätze während der eingabe oder ich bring beim Speichern die Meldung "hallo lieber User deine Arbeit war um sonst!"

1800 Anwendungen die wahrscheinlich schon seit 20 Jahren Arbeiten können nicht falsch liegen.

Bin mir ziemlich sicher das die Anwendungen unter CA oder WebShare genauso funktionieren wie auf einen GreenScreen

Ja so langsam bin ich auch am Zweifeln ob es so schlimm ist, wenn ein Prozess etwas länger die Satzsperre hält... das funktioniert sogar schon seit über 20 Jahren so

[Wuntvor]

Klar das muss ich sowieso, wenn der Client sofort antworten muss... aber das ändert am Ablauf trotzdem nichts... entweder ich lass den Ablauf gleich und sperr die Sätze während der eingabe oder ich bring beim Speichern die Meldung "hallo lieber User deine Arbeit war um sonst!"

Nein. Prüfe die Satzsperre vor Arbeitsbeginn und dann braucht der User auch nicht erst nach getaner Arbeit benachrichtigt werden. Alles andere verbietet sich sofern die Satzsperre durch interaktiver User-Arbeit erzeugt wird. Da ist die Wartezeit nämlich unbekannt und kann durch zwischenzeitliches Mittagessen auch gerne ausgedehnt werden.

Ja so langsam bin ich auch am Zweifeln ob es so schlimm ist, wenn ein Prozess etwas länger die Satzsperre hält... das funktioniert sogar schon seit über 20 Jahren so

Vor 20 Jahren war das nicht weiter wild, da nahezu alle Applikationen so verfuhren. Heutzutage ist dies nicht mehr State-of-the-Art und du solltest Dich mit der Analyse bezüglich einer Änderung beschäftigen.

Um es klar zu sagen, jede hier angesprochene Zwischenlösung ist Gurke.
Ein Batch-Job der eine interaktive Änderung in einem zeitlich unbestimmten Rahmen durchführt ist .... naja.... suboptimal. Der Verlust der Synchronität sollte vermieden werden. Denke immer daran, daß dem ändernden User ja mitgeteilt werden muss, daß die Daten geändert wurden oder geändert werden können. In beiden Fällen muss er dies überprüfen/arbeiten, da dem User nicht bekannt ist, inwiefern er die letzte Änderung durchführte oder ob evtl. seine Änderung erneut überschrieben wurde.

Deine wirkliche Altlast sind die anhaltenden Satzsperren. Diese Logik behältst Du bei oder Du änderst die Altlast. Alle Tricks um dieses Problem zu umgehen wird zu - und da stimme ich Herrn Bender zu - vergrößerten Problemen führen. Da Du ja aber zeitliche Probleme hast, 1800 proggis anzupassen-sofern dies überhaupt möglich ist- mag eine "Zwischenlösung" sinnvoll sein.

Da die aktuelle Applikation Wartezeiten vorweist stellt sich mir die Frage warum das Browserprogramm dies nicht dürfen sollte. Dies wäre dann nämlich keine Zwischenlösung sondern der Applikation angepasst.

[bofrost]

Da die aktuelle Applikation Wartezeiten vorweist stellt sich mir die Frage warum das Browserprogramm dies nicht dürfen sollte. Dies wäre dann nämlich keine Zwischenlösung sondern der Applikation angepasst.

Die alten Anwendungen waren auf Grund von Einschränkungen wie z.B. die Begrenzung des Platzes durch die Emulation von den Abläufen sehr einfach und synchron. Alle Prozesse sind nach einer strikten Reihenfolge abgelaufen. Es wurde auf dem Bildschirm entweder eine Tabelle zum Blätter angezeigt oder ein Satz zum Editieren. Deswegen war es auch möglich, dass das ganze Programm auf den Datensatz wartet.

In den neuen Anwendungen können mehrere UI-Elemente gleichzeitig angezeigt werden. Diese müssen auch ständig mit Daten versorgt werden. Würde ich im Programm auf eine Satzsperre warten müssen, würde der User die anderen UI-Elemente eventuell nicht mehr bedienen können.

[AS400.lehrling]

In den neuen Anwendungen können mehrere UI-Elemente gleichzeitig angezeigt werden. Diese müssen auch ständig mit Daten versorgt werden. Würde ich im Programm auf eine Satzsperre warten müssen, würde der User die anderen UI-Elemente eventuell nicht mehr bedienen können.

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

[Fuerchau]

Dann musst du dir eben dein Design wohl noch mal überlegen.
Wie funktioniert denn deine neue Anwendung wenn gar keine Satzsperren vorliegen würden ?
Was machst du dann mit konkurierenden Updates (letzter gewinnt) ?
Wenn du dieses Problem mal durchdacht und dann gelöst hast, ist die Satzsperre kein Problem mehr, da eine Sperre beim Update (bzw. dem vorherigen Lesen) ja die selbe Situation auftritt als hätte ein anderer User den Satz gerade vorher geändert.
In diesem Fall gilt die Satzsperre für den aktuellen User genauso als wenn der Satz gerade geändert wurde.

[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