Satzsperre

[programmer]

Kann mir jemand eine Lösung für das Problem "Satzsperren" bei interaktiven bzw. Batchjobs verraten.

Den File-Parameter waitrcd möchte ich aber nicht auf *nomax setzen.

[Fuerchau]

Da gibt es keine generelle Lösung, sondern das hängt vom Anwendungsdesign ab.
Normalerweise sollte keine Satzsperre über Dialoggrenzen gehalten werden (sprich: Satz sperren und auf die Rückkehr des Bedieners von der Mittagspause warten).

Ansonsten gilt:
Fehler abfragen (Bezugszahl oder %error()) !
*NOMAX sollte man tunlichst vermeiden, denn das gibt die typischen Deadlocks.

[BenderD]

Hallo,

optimistic locking ist angesagt. ein einfacher Weg ist:
- Feld Version in Datei aufnehmen und bei jedem Update eins hochsetzen
- UPDATE ... SET ... WHERE Key = Key and Version = Version
bei SQLCOD = 100, ist der Satz seit dem lesen verändert worden, funzt ohne jede Satzsperre

Dieter Bender

[mk]

Hallo programmer,

ich weiß nicht wo das Problem liegt, aber manchmal
werden Satzsperren von (tollen) Dialogprogrammen verursacht.

Kleines Beispiel:
Der Pgmer schraubt mal schnell ein Subfile Pgm zusammen.
Nur leider hat er durch Copy/Paste vergessen
die Datei nur Input zu öffnen.
Also ist die Datei mit Update definiert.
Jetzt liest das Pgm die Daten. Und was passiert ? ......


Vielleicht gibt es ja solche Fälle

Gruss Michael

[Wuntvor]

Das ist grundsätzlich ein Riesenthema.

1. Kann man natürlich programmintern den Datensatz ewig lesen, also auf die Satzsperre reagieren, aber das ist ja keine wirklich Lösung.

Grundsätzlich ist die Thematik Satzsperre im gesamten Paket zu konzipieren, was natürlich im Nachwege kaum noch zu machen ist.

Als Lösung hat sich bei mir folgendes bewährt.
1. Updates nur auf die Physische Datei
2. Logische Dateien werden nur Input eröffnet.
2. Physische Datei hat keinen Key sondern wird über die relative Satznummer gepflegt. Also sind Updates "aus versehen" nicht möglich.

Diese Logik führt dazu, daß Satzsperren nur extrem kurze Zeiten auftreten. Natürlich muss man dies koppeln mit einem Updatezähler, damit man letztlich den letzten Zugreifenden ermitteln kann und selbiges programmtechnisch abarbeiten. Im Dialog kann mann dann auf diese Satzsperre hinweisen, welche aber eben nur für Milli-Sekunden auftritt.

Unklar genug ?????

[Fuerchau]

@Wuntvor
Wenn die PF keinen Key hat, wie verwaltest du die Satznummer ?
Wie siehts aus mit REUSEDLT(*YES) oder must du immer einen RGZPFM machen (was lästig ist).
Wie sieht das ganze dann per SQL aus ?

[Wuntvor]

Beim Lesen einer logischen Datei erhält man über die INFDS die relative Satznummer der physischen Datei. Die Satznummern sind dir dann vollkommen egal.

[BenderD]

Hallo,

noch ein paar grundsätzliche Anmerkungen zu den Satzsperren:

Default für den record Wait sind 60 sec. das sind deutlich zuviel!!! was nach einigen Millisekunden nicht freigegeben ist, kann stundenlang gesperrt sein.

Default für den Datei Wait ist *immed, was absoluter Schwachsinn ist!!! auf eine Datei sollte man mindestens solange warten, wie auf einen Satz. Dieser Unfug verhindert die Benutzung von serialize als Sperrlevel im SQL.

Das größte Problem sind immer lang andauernde Sperren und Deadlocks (dafür braucht man den Satz Wait).

Hängende Sätze an der Benutzer Transaktionsgrenze (EXFMT) verhindert man am einfachsten mit Commitment Controll, da gibt der Commit, bzw. Rollback alles frei.

Von den Keylosen Dateien ist dringendst abzuraten, damit verhindert man Normalisierung der Daten, da man ja ohne Key nix verknüpfen kann und man nagelt sich alle Türen für Modernisierung der Anwendung zu. Fazit: so programmiert man Altlasten, die nicht sanierbar sind. (BTW hier werden Zufalls Operationen nicht verhindert, sondeern geradezu herbei programmiert).

mfg

Dieter Bender

Dieter Bender

[B.Hauser]

Hallo,

Hängende Sätze an der Benutzer Transaktionsgrenze (EXFMT) verhindert man am einfachsten mit Commitment Controll, da gibt der Commit, bzw. Rollback alles frei.

Von den Keylosen Dateien ist dringendst abzuraten, damit verhindert man Normalisierung der Daten, da man ja ohne Key nix verknüpfen kann und man nagelt sich alle Türen für Modernisierung der Anwendung zu. Fazit: so programmiert man Altlasten, die nicht sanierbar sind. (BTW hier werden Zufalls Operationen nicht verhindert, sondeern geradezu herbei programmiert).

Noch ein paar weitere zusätzliche Anmerkungen:
Wenn man mit Commitment Control und RPG arbeitet, muss man wissen, das ein UNLOCK bzw. die Erweiterung (N) beim Chain oder Read einen Satz nicht freigibt, sondern immer nur ein Commit oder Rollback.

So schön die Commitment Control auch sein mag, sie erfordert ein zusätzliches Mass an Überlegung, nämlich wann und wo die Commits gesetzt werden. Da sind Programme schon Stunden gelaufen, haben alles blockiert, wurden abgebrochen und liefen nochmal solange bis sie beendet waren und haben dabei auch noch die Platte vollgeschrieben.
Und nur weil an irgend einer Stelle ein kleiner unschuldiger COMMIT vergessen wurde.

Der ganze Zauber mit Zugriff über relative Satz-Nr. ist spätestenfalls dann passé, wenn die Dateien mit SQL angelegt werden. SQL kennt kein REUSEDLT(*NO)! Allerdings kennt SQL (seit Release V5R2M0) ROWID oder IDENTITY COLUMNS über die eindeutige "Zähler" generiert werden können. Über beides kann ein Index gelegt werden, wodurch der Zugriff über "Relative Satz-Nr." simuliert werden kann.

Birgitta

[BenderD]

Hallo,

einiges ist mir so selbstverständlich, dass ich nix dazu geschrieben habe. Commit Verwendung macht eigentlich nur mit embedded SQL und Schichtentrennung Spass und dann wird immer Committed bevor die Steuerung aus der Datenbank-Zugriffs Schicht nach oben geht und das war's.

Dieter

Noch ein paar weitere zusätzliche Anmerkungen:
Wenn man mit Commitment Control und RPG arbeitet, muss man wissen, das ein UNLOCK bzw. die Erweiterung (N) beim Chain oder Read einen Satz nicht freigibt, sondern immer nur ein Commit oder Rollback.

So schön die Commitment Control auch sein mag, sie erfordert ein zusätzliches Mass an Überlegung, nämlich wann und wo die Commits gesetzt werden. Da sind Programme schon Stunden gelaufen, haben alles blockiert, wurden abgebrochen und liefen nochmal solange bis sie beendet waren und haben dabei auch noch die Platte vollgeschrieben.
Und nur weil an irgend einer Stelle ein kleiner unschuldiger COMMIT vergessen wurde.

Der ganze Zauber mit Zugriff über relative Satz-Nr. ist spätestenfalls dann passé, wenn die Dateien mit SQL angelegt werden. SQL kennt kein REUSEDLT(*NO)! Allerdings kennt SQL (seit Release V5R2M0) ROWID oder IDENTITY COLUMNS über die eindeutige "Zähler" generiert werden können. Über beides kann ein Index gelegt werden, wodurch der Zugriff über "Relative Satz-Nr." simuliert werden kann.

Birgitta

[Wuntvor]

@Bender
Sorry aber sehe ich gänzlich anders.
Es ist beabsichtigt, daß die PF ohne Key ist. Und bei entsprechender Disziplin, die über ein keylose Datei eingefordert wird, werden in keinster Weise "Ferkeleien" herbeigeführt.
Solch eine Logik führt letztlich zu einer homogenen Entwicklungsumgebung und das ist im Sinne eines jeden Unternehmens. Natürlich wird die Arbeit mit einigen Tools erschwert.
BTW : Diese Logik läuft bei bei 2 meiner ehemaligen Kunden seit ca. 15 Jahren. Es ist keine Satzsperre bekannt. Beide Pakete sind innerhalb dieser 15 Jahre stetig gewachsen und sind auch heute noch gut pfleg- und lesbar.

[BenderD]

Hallo,

das habe ich nie bezweifelt, dass wir das verschieden sehen. Ich weiss allerdings Herrn Codd auf meiner Seite, der vor gut 30 Jahren die theoretischen Grundlagen für relationale Datenbanksysteme gelegt hat und da ist die Existenz von primary Keys erste Grundvoraussetzung. Die Verarbeitung nach relativer Satznummer ist im Grunde genommen sequentielle Datenhaltung, das geht auch - früher hatte man nichts besseres, aber einer Datenbankmaschine, wie der AS400 ist das nicht angemessen.

mfg

Dieter Bender

@Bender
Sorry aber sehe ich gänzlich anders.
Es ist beabsichtigt, daß die PF ohne Key ist. Und bei entsprechender Disziplin, die über ein keylose Datei eingefordert wird, werden in keinster Weise "Ferkeleien" herbeigeführt.
Solch eine Logik führt letztlich zu einer homogenen Entwicklungsumgebung und das ist im Sinne eines jeden Unternehmens. Natürlich wird die Arbeit mit einigen Tools erschwert.
BTW : Diese Logik läuft bei bei 2 meiner ehemaligen Kunden seit ca. 15 Jahren. Es ist keine Satzsperre bekannt. Beide Pakete sind innerhalb dieser 15 Jahre stetig gewachsen und sind auch heute noch gut pfleg- und lesbar.