Satzsperre

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