Satzsperre

[B.Hauser]

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.

Das Problem, dass viele von uns wahrscheinlich haben, ist, dass wir mit gewachsenen Anwendungen und Datenbanken, natürlich DDS-beschrieben, kämpfen müssen. SQL hat erst in den letzten paar Releasen wirklich an Bedeutung gewonnen. Das Haupt-Problem, was viele nicht sehen wollen, ist i.d.R., dass sich in der Datenbank über die Jahre jede Menge "Müll" (Redundanzen, überflüssige Zugriffswege) angesammelt hat. Bevor man allerdings daran etwas dreht, überlegt man zuerst, ob die RPG-Programm in JAVA umgestrickt werden sollten, und wundert sich dann, dass die Performance noch bescheidener ist.

Dem Einsatz von Embedded SQL steht man noch eher skeptisch gegenüber. (Ich musste schon Programme von Embedded SQL auf RPG umstellen, obwohl die SQL-Variante nachweislich schneller war). Ausserdem ist embedded SQL ist nur auf den ersten Blick einfach! Man muss schon wissen was man tut, bzw. man muss jedes SQL-Statement analysieren, und kann dann, wenn man das ganze auf eine andere Maschine mit anderem Release und andere Datenkonstellation transferiert, ein böses Erwachen erleben.
Da ist es doch einfacher eine vorhandene logische Datei in den F-Bestimmungen zu definieren, da weiss man was man hat! (Das ist nicht unbedingt meine Meinung, aber eine allgemein sehr verbreitete)

Es ist allerdings nicht so einfach, zu behaupten, erst dann wenn man aus der Datenbank-Schicht kommt, den Commit zu setzen. Es ist z.B. unverantworlich, einen kompletten Auslagerungs-Lauf, mit hunderten von Aufträgen unter einem einzigen Commit laufen zu lassen. Da muss schon mehr differenziert werden.

Birgitta

[Fuerchau]

Tja ja, Anwendungsdesign wurde schon immer sträflich vernachlässigt (zugegeben mache ich das auch).
Meine erste Applikation auf AS/400 war V2R1 mit COBOL, Journalisierung und Commit/Rollback ! Was wir da an Design im Voraus entwickelten, hat uns bei der Realisierung erheblich geholfen.
Klar stieß man damals an die Commit-Grenze von 32766 Sätzen (jetzt ca. 0,5 Mio). Aber wer benötigt denn schon so große Transaktionen ?!

Allein was wir an Recovery-Programmen gespart haben, da per Rollback ja jederzeit ein konsistenter Stand gewährleistet wurde.
Sinnvolle Transaktionsdefinition und schon klappts mit der Performance.

Naja, und mit Java und SQL soll ja eh alles automatisch gehen, woll ?

[BenderD]

Hallo Birgitta,

ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).

Dieter

[B.Hauser]

Hallo Birgitta,

ich habe auch mal RPG II programmiert (und COBOL auf Mainframe und das ist noch übler).
Zu dem SQL und dem einfach:
90 Prozent der Programme (und alle typischen Dialogprogramme sind mit SQL einfacher abzubilden. Begründung: 2/3 der Logik beschäftigen sich mit Daten zusammen grabschen und das kann durch ein SQL Statement ersetzt werden.
30 Prozent der Programme fallen bei der Umstellung auf SQL weg, da sie sich nur in der Sortierfolge, oder ähnlichem von einem anderen Programm unterscheiden.
Es bleibt ein kleiner Rest, der sauberes umgehen mit SQL erfordert - in diese Ecke gehört auch Transaktions Sicherheit (was die meisten RPG Rekord Löffel Exzess Programme nicht sind).
Ein Satz noch zu Schichtentrennung:
Die Steuerung eines Batch Jobs ist Business Logik, die Datenbankzugriffsschicht sagt nach der Verarbeitung jedes Satzes Commit, wo ist da das Problem? Gerade durch saubere Schichtentrennung wird das einfacher (bis auf den Krampf mit den Activation Groups, weil man nur einmal Connecten darf- aber das ist ein völlig anderes Thema).

Dieter

Hallo Dieter,

ich habe ja auch nichts gegen embedded SQL gesagt! Und mit einfach habe ich eigentlich nur gemeint, dass man einigermaßen wissen sollte, wie SQL funktionniert, auch wenn die Entscheidungen des Optimizers nicht immer nachvollziehbar sind.

Wenn es nach mir ginge, gäbe es keine F-Bestimmungen mehr in den RPG-Programmen. Durch geschickte Views könnten selbst etwas weniger versionierte RPG-Programmierer embedded SQL einsetzen. Vermutlich würden hunderte von Zugriffs-Wegen (bzw. logische Dateien) überflüssig werden, die heute alle mit Zugriffs-Pfadwartung *IMMED erstellt sind, da ein Unique Key auf der Datei liegt. Nur leider kann man nicht von heute auf morgen hunderte Programme (die problemlos laufen) auf embedded SQL umstellen. Performance hin oder her.

Ich würde noch viel weiter gehen und viel mehr Funktionalität, z.B. über Referentielle Integritäten und Trigger in die Datenbank packen. Am liebsten würde ich die komplette Datei-Verarbeitung direkt in SQL programmieren und als Stored Procedures aufrufen. Das RPG (oder was auch immer)-Programm würde nur noch steuern, also nur noch aus Programm- und Prozedur-Aufrufen bestehen.

Aber man gerät leider immer noch sehr oft an recht konservative Ansichten, die teilweise sogar soweit gehen, warum RPGIV in RPGIII geht doch alles.

Birgitta

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

[BenderD]

Hallo Wuntvor,

Die RRN ist Bestandteil der Art physischen Speicherung, sie ist zwar eindeutig, aber eben kein Key. Wenn ich sie als "Pseudo" Key verwende, um Referenzen auf Satzebene abzubilden (Foreign Key), dann darf ich weder Reuse Deleted records verwenden, noch RGZPFM machen, da sich dann ja der Pseudo Key ändern würde und genau das ist sequentielle Datenhaltung.

Der einzige Unterschied zu dem Begriff liegt darin, daß ich die RRN nicht selber verwalte, was aber auch garnicht in meinem Interesse liegt.

Ich glaube wir haben nur eine unterschiedliche Betrachtungsweise.

Das ist in der Tat der Kernpunkt. Du hast eine Applikation im Hinterkopf, wie sie vor Jahren programmiert wurde. Ich betrachte das Ganze tatsächlich von der "grünen Wiese" aus: wie würde man das machen, wenn man heute damit anfangen würde eine Applikation von Null an zu schreiben. Damit ist nichts darüber ausgesagt, ob es zweckmäßig ist jede vorhandene Anwendung dahin zu bringen und wenn ja wie, dazu würde ich mir in einem Forum ohne Kenntnis der konkreten Anwendung nie ein Urteil erlauben.

mfg

Dieter Bender

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

[BenderD]

Hallo Rince,

ersteres ist ein völlig anderes Thema, nämlich ein Datenbank internes Thema, wie eine primary Key constraint abgebildet wird.

*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)

Zum PS: greift m.E. zu kurz. Wenn solche Sperren auftreten, dann sind davon auch nicht interaktive Jobs betroffen und es hilft einem (Beispiel) Batch oder Server Job wenig, wenn ich ihm sage welcher interaktive Job einen Satz die nächsten 3 Stunden sperrt.

Dieter Bender

[Winnilein]

Wenn im RPG-Programm geschlüsselte Files nur als Output in den F-Bestimmungen definiert sind, kann es vorkommen, das das Programm, wenn es mehrfach aufgerufen wird(z.b eine Auftragserfassung oder eine Fakturierung) sich die Files gegenseitig lockt !!
Im Joblog steht dann immer wieder die Meldung :
Öffnen von Teildatei XXXXXX in SEQONLY(*NO) geändert.
Der Job macht dabei einen internen OVRDBF, und dieser braucht Exclusivrechte !
Also wartet der eine auf das Ende vom ANderen :-((.
Dies läßt sich äusserst einfach umgehen.
1. Im RPG-Programm die Definition des Output-Files auf UF ändern.
2. Eine Subroutine ins Programm einfügen, die nie Aufgerufen wird(und auch nicht aufgerufen werden darf).
etwa so:

Ffilep uf usw....

c maxopn begsr
c read filep
c delete files (files ist das Format von filep)
c write files
c update files
c endsr

Somit macht das Programm keinen internen OVRDBF mehr und lockt auch nix mehr !

Gruß
Winni Köhler

[Fuerchau]

"Öffnen von Teildatei XXXXXX in SEQONLY(*NO) geändert." hat nun überhaupt nichts mit der Satzsperre zu tun sondern liegt darin begründet, dass RPG bei O-Dateien versucht die Daten zu blocken. Blocken ist aber bei geschlüsselten Dateien (auch bei REUSEDLT(*YES)) nicht möglich !
Deine "Umgehung" hilft bei Mehrfachopen nun mal überhaupt nichts gegen Deadlocks, da jedes Programm seinen eigenen ODP bekommt.
Sperrt also ein Programm einen Satz und ein anderes Programm im gleichen Job versucht eine Sperre zu erhalten, kann es diese nie bekommen !!!

Die einzige Umgehung wird häufig mittels SHARE(*YES) verwendet, was aber den Satzzeiger der anderen Programme zerstört oder auch Satzsperren (die vielleicht benötigt werden) aufhebt !

Also:
Deine Lösung macht nichts weiter, als obige Meldung zu unterdrücken, da ja sowieso Einzelsatzverarbeitung verwendet wird.

Es gibt auch irgendwo eine Einstellung, dass das Blocken im RPG verhindert.

PS:
Oder hast du vielleicht Blocken mit Locken verwechselt ?