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

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

[B.Hauser]

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

Schlüssel-Wort Block(*NO) in den F-Bestimmungen.

Birgitta

[Winnilein]

Dann Erkläre mir doch bitte, warum die Jobs auf LCKW stehen, wenn das Programm mit O-Files arbeitet. Die Lösung mit der maxopn Subroutine stammt im übrigen nicht von mir, sondern ist in der Brain bzw. MAS90 Umgebung Standard.
Und für diesen speziellen Fall hilft es so.

[Fuerchau]

Dazu müsste ich wissen, auf welchen Lock der Job wartet (über gesperrte Objekte nachzusehen).
Der reine O-Modus kann nicht der Grund sein, denn obige Meldung kann man ja durch Compiler-Anweisung unterdrücken.
Das System kennt keinen internen OVRDBF und schon kein Exclusiv-Recht für OVR ! Ich kann nähmlich beliebige OVR's definieren die erst dann wenn sie ein Objekt betreffen ggf. zu Zugriffsproblemen führen.

Und was die Brain/MAS90-Lösung angeht so ist der Grund meistens die SHARE-Option:
RPG öffnet eine Datei nach möglichkeit im angegebenen Modus, also Input, Output, I-O, I-O mit/ohne Append(A) / Delete(D).
Beim SHARE ist der ODP nun festgelegt.
Will nun ein anderes Programm einen höheren Modus eröffnen führt dies zu einem Fehler im Programm !
Beispiel:
PGM1 öffnet im Imput-Modus
PGM2 will I-O-Modus
Durch die Pseudo-Routine wird die Datei immer im IOAD-Modus geöffnet, so dass es zu keinen weiteren Fehlern kommt.

Da ich auch mit Brain arbeite mussten wir verschiedentlich bei den Dateien SHARE(*NO) einsetzen, da sich leider nicht alle Programme daran halten.

[BenderD]

dass es sowas noch gibt, 115 Jahre nach Erfindung der Lochkarte
... da wandte er sich ab mit Grausen und weinte bitterlich

Dieter

[Fuerchau]

@Dieter
Auf Grund der Trefferquote scheint dies ja ein brisantes Thema zu sein. Was mich allerdings wundert, da ich mit Satzsperren bereits 1976 konfrontiert wurde. Aber es scheint wohl immer noch keine eindeutige Lösung zu geben.
Selbst mit SQL (viele arbeiten da ohne Commit/Rollback oder Journalisierung) kriege ich die Probleme des Multiusings nicht vernünftig in den Griff. Es gibt immer wieder User (DAU's) die es nicht begreifen, dass vernünftige Rechner (e.g. AS/400, ähm i5), mit mehr als einem Benutzer GLEICHZEITIG arbeiten.
Auf dem PC habe ich die Problem meist nicht, kommt in WORD die Meldung "Dokument kann nicht für Änderung geöffnet werden", schließe ich halt die andere Sitzung und mach lustig weiter.
Wenn der User aber am anderen Ende der Welt sitzt und die Resource einfach nicht hergeben will (vielleicht gibts ja grad ein Schäferstündchen mit anschließendem Krankenhausaufenthalt nach Herzinsuffizienz) steht der DAU nun mal vor der nicht reagierenden Kiste.

Aber wie immer: Es gibt 1000+ Lösungen aber die einzig Richtige ist allein die Meinige !