View Full Version : Extfile macht Dateibeschreibung kaputt
Hi *all
ich habe hier folgende Definition
FAKTVEL01 IF E K DISK
FAKTVEP IF E K DISK RENAME(AKTVER:AKTVERZ) PREFIX(Z_)
FAKTVEP2 UF A E DISK EXTFILE('AKTVEP')
F RENAME(AKTVER:AKTVERW) PREFIX(W_)
Ein LF und ein quasi 2 mal definiertes PF (hat einen Key)
Wenn ich das Pgm rufe ist
1. nur die LF und 1 PF offen
und ich bekomme beim Chain auf die AKTVEP einen CPF5129
Alle sieht so aus, als ob die AKTVEP2 Definition die AKTVEP kaputt macht
Da ich sowas selten mache ...
Was muß ich tun, um die Datei 'echt' 3 mal am Pgm zu haben
(ohne CL / OVRDBF) bei V5R4
Danke
Robi
Sieht mir ganz danach aus, dass die Datei mit SHARE(*YES) definiert ist.
Dann funktioniert der 2. Open auf die selbe Datei nicht und wird in Input geändert.
Hierfür gibts bestimmt einen Hinweis im Joblog.
SHARE(*YES)-Dateien lassen sich zwar mehrfach öffnen verwenden aber nur einen ODP!
Entweder auf SHARE(*NO) ändern oder jeweils eine LF anlegen.
Huch, danke!
Ja, tatsächlich.
Der CRTPF steht hier mit dem DFT share(*yes).
Ich kann mich dunkel erinnern, das bei unser eigenen Software während der Umstellung von 'Ein Pgm macht alles' auf 'Jede Aufgabe ein Pgm' Probleme durch Share(*yes) auftraten.
Seit dem (ca. 15 Jahre?) habe ich mich nie wieder mit share befasst.
Wenn ich drüber nachdenke, was das in verschachtelten gewachsenen Architekturen alles anrichtet ...
Hat share(yes) auch Vorteile?
Gruß
Robi
Das hängt immer von der Anwendung ab.
Share(Yes) kann sich selbst nicht blocken (Deadlock), allerdings entscheidet immer der 1. Open für alle folgenden.
Ausserdem kann ein Unterprogramm jederzeit den Dateizeiger verändern, was ggf. das übergeordnete Programm nicht erwartet.
Oder was ich auch schon erlebt habe:
Das Hauptprogramm liest für Update und irgendein Unterprogramm macht dann den Update mit zuvor aus einer anderen LF mit anderen Schlüsseln gelesenen Informationen.
Oder es verschiebt den Satzzeiger so dass das Hauptprogramm den falschen Satz updatet oder auf die Nase fällt, weil der Satz nicht zum Update gesperrt wurde.
Und, und, und...
ja, das meinte ich
Habe in deiner Aufzählung KEINEN Vorteil erkannt.
(kann sich selbst nicht Blocken ist für schlechtes Design m.e. eher schädlich als nützlich)
Gruß
Robi
Nunja, wenn das Design stimmt, dann hat man für jede Datei ein Filehandler-Programm, dass die jeweilige Aktion durchführt (wobei man dann auch kein Share benötigt).
Übrigens:
SQL ignoriert Share.
Wenn ich drüber nachdenke, was das in verschachtelten gewachsenen Architekturen alles anrichtet ...
Software und deren Architektur wächst nicht, die schrumpft!
Hat share(yes) auch Vorteile?
- wurde während des kalten Krieges gerne "just to fool the russians" eingesetzt
- immer wieder gerne verwendet von Softwarehäusern, die Fehlerbehebungen der eigenen Software dem Kunden nach Aufwand berechnen
- absolutes Muss für alle, die alles ausprobieren müssen was es da so gibt (das sind dann die, die im RZ mal ausprobieren wozu dieser große rote Knopf da ist)
D*B
Hi Dieter
Software und deren Architektur wächst nicht, die schrumpft!
Leben wir auf demselben Planeten?
Redesign lässt Software und Architektur (vielleicht) schrumpfen.
Munteres
weiter so, und mach ne Kopie, vielleicht brauchen wir es später nochmal bläd Software und deren Architektur
endlos (und zum Nachteil) auf.
Ansonsten finde ich deine Ansicht über Share(*yes), wie so häufig, recht amüsant.
Gruß
Robi
Leben wir auf demselben Planeten?
... historisch gewachsen ist eine beliebte Ausrede für schlechte Programme und schrumpfen meint hier nicht Lines of Code, sondern Abnahme an Qualität und damit Funktionalität...
D*B
Und wie man an SQL sieht, der interressiert sich überhaupt nicht für Share(*yes) und macht durchaus mehrere ODP's für eine PF auf.
Welchen Vorteil hat dann Share ausser Dieters Begründung, eigene Fehler nicht suchen zu müssen ?