Extfile macht Dateibeschreibung kaputt

[Robi]

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

[Fuerchau]

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.

[Robi]

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

[Fuerchau]

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

[Robi]

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

[Fuerchau]

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.

[BenderD]

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

[Robi]

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

[BenderD]

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

[Fuerchau]

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 ?

[Robi]

Ich bin ja auch dagegen...
aber der Kunde hat das so, und will es auch nicht ändern
Der Aufwand ist ja auch nicht 'mal auf n Abend' erledigt.

[BenderD]

... da stellt sich die Frage ob ich Codierknecht bin oder ob ich Wissen, Ideen und Verbesserung einbringen soll. Wobei es hier nicht um das flächendeckende ausbauen unschöner Konstrukte, sondern um die Qualitätsverbesserung von Programmen, die zur Änderung anstehen, geht. Für letzteres müsste man die Diskussion allerdings noch ein wenig vertiefen...

D*B

Ich bin ja auch dagegen...