Satzsperre

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

[Wuntvor]

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

Herrn Codd wird nicht wiedersprochen und es wird auch nicht gegen ihn gearbeitet, es wird lediglich der Zugriff auf eine physische Datei erschwert. Damit existiert im Maximum eine zusätzliche logische Datei(wahrscheinlich gäbe es sie sowieso). Wir sind uns sicherlich darüber einig, das der qualifizierte Zugriff über die relative Satznummer nichts mit sequentieller Datenhaltung zu tun hat. Ein fehlender Key sagt über die Art der Datenhaltung nicht wirklich etwas aus weder über die Art noch über den Grad der Normalisierung.

Zäumen wir das Pferd von hinten auf. Das Ziel wird erreicht.

[BenderD]

@Birgitta,

ich habe einen wesentlichen Vorteil: ich kann mich als OneManShow auf Aufträge konzentirieren, wo man technologisch nach vorne will und nicht die Vergangenheit zurück holen will.

Das Thema mit den Funktionalitäten in die Datenbank verlagern wäre vielleicht irgendwann mal eine interessante Diskussion wert, das läuft gegenwärtig wieder in die umgekehrte Richtung (Stichwort Enterprise Java Beans) und auch das kann auch seinen Charme haben.

@Wuntvor
Codd's 2. Regel:
2. The guaranteed access rule
This rule is essentially a restatement of the fundamental requirement for primary keys.
It says that every individual scalar value in the database must be logically addressable
by specifying the mane of the containing table, the name of the containing column and the
primary key value of the containing row.
(nach: http://www.databaseanswers.com/codds_rules.htm)
Ob man das jetzt als Access Path für das PF oder als Key einer logical anlegt ist eine andere Frage. Ich würde das eh' mit SQL machen und als Constraint anlegen.


Zugriffe auf das PF Objekt würde ich generell nicht machen, sondern grundsätzlich mit SQL auf SQL erstellte Views zugreifen, das entkoppelt die Anwendung von der Datenbank.

Der Zugriff über relative Satznummer hat durchaus mit sequentileer Verarbeitung zu tun, das sieht sogar der Query Optimizer des Datenbanksystems so und produziert full Table scans, wenn man die SQL Funktion RRN verwendet.

Normalisierung setzt die Existenz von Keys voraus, wenn eine Kundendatei keinen Key hat, dann kann ich schließlich keinen Kunden über seinen Key in dr Auftragsdatei kennzeichnen, nach meinem Verständnis zumindest.

mfg

Dieter Bender

[Wuntvor]

@Birgitta,

ich habe einen wesentlichen Vorteil: ich kann mich als OneManShow auf Aufträge konzentirieren, wo man technologisch nach vorne will und nicht die Vergangenheit zurück holen will.

Das Thema mit den Funktionalitäten in die Datenbank verlagern wäre vielleicht irgendwann mal eine interessante Diskussion wert, das läuft gegenwärtig wieder in die umgekehrte Richtung (Stichwort Enterprise Java Beans) und auch das kann auch seinen Charme haben.

@Wuntvor
Codd's 2. Regel:
2. The guaranteed access rule
This rule is essentially a restatement of the fundamental requirement for primary keys.
It says that every individual scalar value in the database must be logically addressable
by specifying the mane of the containing table, the name of the containing column and the
primary key value of the containing row.
(nach: http://www.databaseanswers.com/codds_rules.htm)
Ob man das jetzt als Access Path für das PF oder als Key einer logical anlegt ist eine andere Frage. Ich würde das eh' mit SQL machen und als Constraint anlegen.


Zugriffe auf das PF Objekt würde ich generell nicht machen, sondern grundsätzlich mit SQL auf SQL erstellte Views zugreifen, das entkoppelt die Anwendung von der Datenbank.

Der Zugriff über relative Satznummer hat durchaus mit sequentileer Verarbeitung zu tun, das sieht sogar der Query Optimizer des Datenbanksystems so und produziert full Table scans, wenn man die SQL Funktion RRN verwendet.

Normalisierung setzt die Existenz von Keys voraus, wenn eine Kundendatei keinen Key hat, dann kann ich schließlich keinen Kunden über seinen Key in dr Auftragsdatei kennzeichnen, nach meinem Verständnis zumindest.

mfg

Dieter Bender

Sowohl die relative Satznummer einer PF als auch der Key des LF ist ein eindeutiger Key und entspricht der Definition Codds eines primary Keys(My 2 cents). Eine "Schwäche" des Query Optimizers ist kein Argument dagegen. In RPG kann ich durchaus direkt einen Zugriff auf einen qualifizierten Datensatz nehmen. Der einzige Unterschied zu dem Begriff liegt darin, daß ich die RRN nicht selber verwalte, was aber auch garnicht in meinem Interesse liegt.
Ich Stimme dir zu, daß zu einer Normalisierung auch Schlüsselbegriffe gehören, aber selbige existieren ja auch in unserem Diskussionsbeispiel.

Deiner Aussage, daß man/du keine Zugriffe auf eine PF machen sollte stimme ich voll und ganz zu.

Ich glaube wir haben nur eine unterschiedliche Betrachtungsweise. Bei einem Paket, welches in RPG repsektive ILE codiert wurde nutze ich die Datenbank der AS/400 und eben nur RPG; sagen wir ADTS. Tools die extern den, ändernden, Zugriff auf diese Datenbank erlauben möchte ich als weit als möglich vermeiden, da dies der Definition einer homogenen Entwicklungs-/Laufumgebung wiederspricht.
Solch eine heterogene Umgebung kann ich meiner Meinung nach, nur auf einer "grünen Wiese" konzepieren und umsetzen. Wohin der nachträgliche Einsatz führt, sehe ich gerade auf meiner aktuellen Arbeiststelle.

Unter diesen Betrachtungspunkten erreicht man, mit der vor ca. 8000 Worten beschriebenen Lösung, direkt das Ziel.

[Rincewind]

*einmisch*

und natürlich *vom thema mal wegführ*

Physische Dateien ohne Schlüssel machen Sinn.
Bei Häufigen Plattenfehlern kann man die nämlich leichter wieder zusammenkopieren (so sie denn sequentiell fortgeschrieben werden).

Der Erste logische Zugriffsschlüssel ist dann der UNIQUE Zugriffskey
So wird auch alles Eindeutig zuordbar.


Rince

P.S. Zum Thema Satzsperre: Wir haben den ganz normalen 60 Sekunden Warten und dann auf die Nachricht reagieren (so wie man es damals halt machte..)
Neuerdings bin ich aber Fan der Satzsperrenabfrage im Programm (und dann einen Bildschirm ausgeben wer hier wen sperrt)
Dann klären die User das Per Telefon selbst (Stundenlanges Blockieren weil man vor der Besprechung nicht aus dem PGM geht und so... Alles schön dem User überlassen, da werden die Leute von selbst vorsichtiger)