Extfile macht Dateibeschreibung kaputt

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

[Robi]

Hallo Dieter,
meist du das unfgefär so:

Lieber Kunde,
du hast hier zwar 1500 Programme die funktionieren, aber sie sind unmodern und nutzen Techniken die normalerweise zu Problemen führen. Da ich kein Codierknecht bin und mein Wissen, meine Ideen und Verbesserungen einbringen soll möchte ich zur Qualitätsverbesserung den CMDDFT vom crtpf von share(*yes) in share(*no) ändern.
Die Programme die ich grade entwickele werden dadurch 'besser' (= moderner) Auch ein Zugriffspfad wird gespart.
Die alten Programme werden bei einer Dateiänderung nach und nach Fehler erzeugen - oder auch nicht, je nachdem ob der Effekt von share zufällig oder sogar absichtlich verwendet wurde oder nicht.
Wie gesagt : Es hier nicht um das flächendeckende ausbauen(im Sinne von rausprogrammieren) unschöner Konstrukte, sondern um die Qualitätsverbesserung von den Programmen, die ICH grade NEU schreibe.

alternativ kann ich diese eine neue Datei mit abweichenden Parametern erstellen und hoffen, das alle Entwickler die für euch tätig sind zukünftig diese eine Datei mit abweichenden Parametern erstellen. Sicher reicht dafür eine mail an alle Betroffenen, am besten mit der Wichtigkeit 'hoch'

Gruß
Robi
(letzer post meinerseits)