View Full Version : Satzsperre
*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)
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
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
"Ö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 ? ;)
Fuerchau
Es gibt auch irgendwo eine Einstellung, dass das Blocken im RPG verhindert.
Schlüssel-Wort Block(*NO) in den F-Bestimmungen.
Birgitta
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.
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.
dass es sowas noch gibt, 115 Jahre nach Erfindung der Lochkarte
... da wandte er sich ab mit Grausen und weinte bitterlich
Dieter
@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 !