Trigger auf Record Lock

[Wuntvor]

Im Grunde kannst Du tatsächlich nur verfahren wie die Altanwendung es macht, so bedauerlich es auch sein mag.
Bei jeder anderen Lösung ist dem Anwender nämlich garnicht bekannt was er eigentlich ändert. Der Record Lock bedeutet, daß der eingelesene Datenbestand bei Auflösung der Sperre nicht mehr dem ursprünglich eingelesenen entsprechen muss.
Hier hilft nur Sperren und Lesen um diesem Problem aus dem Wege zu gehen.

Sollte dieses Problem nicht von Interesse sein, so besteht natürlich bei Auftreten der Satzsperre die Möglichkeit der Auslagerung der Speicherung in eine externe Batchfunktion. Dies verschärft die oben beschriebene Problematik jedoch noch und ist daher eigentlich grundsätzlich abzulehnen.

Natürlich könnte dein "Browser" Proggie auch auf die Satzfreigabe warten und durch erneutes Lesen des Datensatzes und Abgleich mit den editierten Daten auftretende Probleme kenntlich machen. Dies ist natürlich abhängig von der Wartezeit, wäre aber wenigstens argumentativ zu vertreten.

Wie bereits erwähnt wirst Du über kurz oder lang dieses Problem grundsätzlich beheben müssen. Ich bin mir sicher, daß die User dir dies des öfteren präsentieren.

[bofrost]

Natürlich könnte dein "Browser" Proggie auch auf die Satzfreigabe warten und durch erneutes Lesen des Datensatzes und Abgleich mit den editierten Daten auftretende Probleme kenntlich machen. Dies ist natürlich abhängig von der Wartezeit, wäre aber wenigstens argumentativ zu vertreten.

Das ist eine super Idee ich könnte nach dem klicken auf Speichern auf die Satzsperre warten und prüfen ob der Satz verändert wurde und dann dem User nochmals entscheiden lassen, was er wie ändern möchte.
Allerdings möchte ich nicht, dass das Programm solange stillsteht. Somit bin ich wieder am Problem vom Anfang, wie bekomm ich einen RecordLock per Trigger o.ä.

Ich hab bis jetzt 3 Lösungsansätze:
1.)Einen zweiten Thread auf machen, welcher auf die Satzsperre wartet. Hier Stellt sich mir allerdings das Problem, das das Job-Accounting nicht mehr funktioniert. (CHGACGCDE)
2.)Einen zweiten JOB submitten der den Record-Lock wartet und dann über die DTAQ dem Ursprungsjob mitteilt, dass der Record gerade frei war... Hier könnte aber jemand schneller sein und man müsste neu anfangen oder man würde es irgendwie schaffen den RecordLock so von einen Job zum anderen zu bringen, dass er dazwischen nicht abhanden kommt. Ich bin mir nicht sicher ob man das mit Lock-Spaces lösen kann.
3.)Über eine art Trigger, Exit-Point-Programm meinen Programm mitteilen, dass der Record-Lock aufgehoben wurde. (Ich hab eine ähnliche Umsetzung, dass bei Dateiänderung automatisch die View aktualisiert wird, funktioniert ohne Probleme) Hier hab ich allerdings noch keine Möglichkeit gefunden wo man so einen Trigger-Programm ansetzen könnte. (Gibt es eine Tabelle in der alle Locks gespeichert werden wie bei andern DB2 Systemen?)

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

[Wuntvor]

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.

Die "alte" Anwendung stellt durch seinen Ablauf/Satzsperren Datenintegrität sicher. Der User der an einem Datensatz arbeitet kann sicher sein, daß seine Tätigkeiten auch den Zustand der Daten verändern, evtl. Nachfolgearbeiten bekommen dementsprechend stets korrekte Daten zur Verfügung gestellt.

Während die Applikation in dieser Art und Weise verfährt, soll dein Browserprogramm nun die Regeln verändern, womit du automatisch Probleme erhältst, die die "alte" Applikation nie hatte.

Wenn dein Browserprogramm auf Satzfreigaben wartet oder besser gesagt ebenfalls Satzsperren durchführt - sich also der Applikationslogik anpasst - kannst Du sicherstellen, daß die erfassten Daten auch tatsächlich gespeichert werden, da es ja keine konkurierenden Updates geben kann.

Sofern du dem User die Erfassung der Daten gestatten willst und diese dann, aufgrund einer Satzsperre, notgedrungen asynchron speichern willst, wirst du entscheiden müssen welche Datensatzänderung denn nun gespeichert werden soll. Bedenke hierbei, daß dies beliebig viele Änderungen sein könnten.

Herr Fuerchau hat mit seiner Analyse vollkommen recht.

PS : Mich würde auch interessieren was dein Browserproggi macht, sofern überhaupt keine Satzsperren vorhanden sind.