Dateierweiterung ohne Umwandeln

[BenderD]

Hallo,

mit ein wenig Überlegung im Vorfeld ist das eigentlich recht einfach:
- Grundsätzlich nur logische Dateien verwenden
- bei Änderung der physischen Datei zusätzliche logische mit den neuen Feldern erstellen
- gegebenen Falls logische Dateien anpassen, sodass sie die identischen Daten liefern wie vorher
- anpassen der Programme, die erweiteret Daten brauchen

Finger weg von solchem Krampf wie level check abschalten, oder blindem umwandeln etc.

mfg

Dieter Bender

Hallo,

ich möchte eine DB2-Datei um n paar Felder erweitern. Ich weiß, das es da eine Möglichkeit gibt, die Datei so erweitern, das man nicht alle Programme nochmal umwandeln, nur leider nicht mehr, wie das funktioniert.

Hat jemand einen Tip für mich ??

Danke

Stefan

[Fuerchau]

Aber ACHTUNG:

Verweist die LF mit ihrem Satzformat auf die PF (DDS hat keine eigene Feldliste), so ändert der CHGPF auch alle LF's die so definiert werden.
Das gilt auch für LF's in anderen Bibliotheken (DSPDBR zeigt dies).
Es kann also durchaus sein, dass Programme die gar nicht mit der PF arbeiten, plötzlich abschmieren, da die LF nicht mehr stimmt.
Das Abschalten von LVLCHK auf der PF hat übrigens keine Auswirkung auf den LVLCHK der LF !

Also VORSICHT bei änderung von DB-Strukturen, wenn man nicht mit SQL zugreift.

[BenderD]

Hallo,

dieser Effekt wird mit meinem dritten Punkt vermieden (deshalb steht der auch in meinem Posting): Anpassung logischer Dateien, sprich Feldliste (alter Stand) aufnehmen.
Was LFs in anderen Bibliotheken angeht: auch diesen Unfug würde ich vermeiden, da gibt es Dutzende Möglichkeiten einfach was falsch zu machen, was man schwer findet.

mfg

Dieter Bender

Aber ACHTUNG:

Verweist die LF mit ihrem Satzformat auf die PF (DDS hat keine eigene Feldliste), so ändert der CHGPF auch alle LF's die so definiert werden.
Das gilt auch für LF's in anderen Bibliotheken (DSPDBR zeigt dies).
Es kann also durchaus sein, dass Programme die gar nicht mit der PF arbeiten, plötzlich abschmieren, da die LF nicht mehr stimmt.
Das Abschalten von LVLCHK auf der PF hat übrigens keine Auswirkung auf den LVLCHK der LF !

Also VORSICHT bei änderung von DB-Strukturen, wenn man nicht mit SQL zugreift.

[holgerscherer]

Was LFs in anderen Bibliotheken angeht: auch diesen Unfug würde ich vermeiden, da gibt es Dutzende Möglichkeiten einfach was falsch zu machen, was man schwer findet.

Moin Dieter,
da fällt mir immer wieder die beliebteste Möglichkeit ein: SAVE21, RESTORE21. Das gibt immer wieder Probleme, wenn die LFs in LIBRARYA und die PFs in LIBRARYB sind ;-/

Hast Recht, wer sowas tut, gehört mit einem RPG nicht unter 80 Bezugszahlen gestraft.

-h

[loeweadolf]

Das ganze Gewurschtel mit den logischen Dateien und prüfen, welche davon auch wieder zu erweitern sind, ist doch ein bißchen hintenrum.

Es ist doch kein Zeitaufwand, einmal alle relevanten Programme einmal zum Umwandeln aufzurufen.

mfg Ludger

[BenderD]

Hallo Ludger,

ich kann da kein Gewurschtel erblicken; wenn man von vorneherein alles richtig macht, gibt es keinerlei Handlungsbedarf. Es geht um die Entkoppelung von Datenbank Design und Anwendung; wenn ich mir ansehe wie oft das Datenbankdesign in mancher RPG Anwendung vernagelt ist, dann kommt mir das kalte Grausen.

mfg

Dieter Bender

Das ganze Gewurschtel mit den logischen Dateien und prüfen, welche davon auch wieder zu erweitern sind, ist doch ein bißchen hintenrum.

Es ist doch kein Zeitaufwand, einmal alle relevanten Programme einmal zum Umwandeln aufzurufen.

mfg Ludger

[Unregistriert]

Hallo,

genau zu diesem Thema habe ich einen Beitrag im Forum "Software" geschrieben. Hier der Link.
http://www.rlpforen.de/showthread.php?t=5819

Mfg

Frank Hildebrandt

[Fuerchau]

Klar kann ich solche Problem immer mit einem anständigen Source-Control-System verfolgen (da gibts auch mehrere).
Aber leider hilft auch dies nicht immer, insbesonders wenn noch zusätzliche Fremdprodukte auf gemeinsame Dateien zugreifen, die ich in mein SCS nicht unterkriege.

Ich kann da nur Dieter zustimmen:
Vorher Gedanken über die Datenbank machen und bei der Programmierung darauf achten.
Verwendet man kein SQL muss man eben neue Felder in eigenen Tabellen unterbringen (früher nannte man das Rucksack-Dateien) wenn man nicht ALLE betroffenen Programm neu erstellen kann.

Übrigens:
Bis V4R5 hatte auch Query/400 LVLCHK-Fehler bei geänderten Dateien.
Seit V5 prüft Query/400 nun mit SQL und meldet nur noch dann Fehler, wenn er Felder nicht mehr findet bzw. die Attribute nicht mehr kompatibel sind.

[BenderD]

Hallo,

es geht um zwei Dinge:
die sogenannten technischen Umwandlungen sind mit oder ohne Source Control ein einziger Wackelhaufen. Nur mal ein Beispiel (aus leidvoller Praxis) herausgegriffen - ein hinzugefügtes Feld ist gleichnamig mit einem in einem der Programme verwendeten Feld; das hat zur Folge, dass die Umwandlung gelingt und Inhalte im Programm ungewollt überknüppelt werden. Sowas tun sich nur wahnwitzige an; mal ganz abgesehen davon, dass eine Erweiterung einer wichtigen Stammdatei fast die gesamte Anwendung hinterherzieht, das ist vom Aufwand alles andere als trivial, selbst wenn ich nur eine Installation habe.

Der zweite Punkt ist, dass die phyische Form der Speicherung in den Programmen nix verloren hat, deshalb verwendet man nämlich gerade ein relationales Datenbanksystem!

Nebenbei bemerkt gibt es auch mit Rekord Löffel Exzess keinen Grund die physische Datei in irgendeinem Programm zu verwenden und DDS erzwingt keineswegs komplette Satzformate einer physischen Datei zu verwenden und bei dieser Vorgehensweise merkt kein einziges Programm wenn ich einer PF ein Feld hinzufüge, da brauchts keine Rucksäcke!

Die angeführte Query Problematik wird ebenfalls ausgeschlossen, wenn man in den Queries ausschließlich LFs verwendet.

mfg

Dieter Bender

Klar kann ich solche Problem immer mit einem anständigen Source-Control-System verfolgen (da gibts auch mehrere).
Aber leider hilft auch dies nicht immer, insbesonders wenn noch zusätzliche Fremdprodukte auf gemeinsame Dateien zugreifen, die ich in mein SCS nicht unterkriege.

Ich kann da nur Dieter zustimmen:
Vorher Gedanken über die Datenbank machen und bei der Programmierung darauf achten.
Verwendet man kein SQL muss man eben neue Felder in eigenen Tabellen unterbringen (früher nannte man das Rucksack-Dateien) wenn man nicht ALLE betroffenen Programm neu erstellen kann.

Übrigens:
Bis V4R5 hatte auch Query/400 LVLCHK-Fehler bei geänderten Dateien.
Seit V5 prüft Query/400 nun mit SQL und meldet nur noch dann Fehler, wenn er Felder nicht mehr findet bzw. die Attribute nicht mehr kompatibel sind.

[Unregistriert]

H,

ich kann auch nur zu einer schönen Software raten die einem das alles wandelt.

Ich hab so ne Dateierweiterung mit allen Programmen immer unter 1 Stunde durchgewandelt.(Mit OVRDBF und anderem Schmu den man so kennt)

Wenn andere noch mit Find String PDM alle Sourcen durchwühlen tipp ich kurz und habe alle Abhängigkeiten (auch Dynamischer SQLs) im Blick.

LVLCHK *NO hat mich lang genug aufgeregt, nu kann ich endlich wieder alles sauber wandeln nach ner Erweiterung.

Schönen Gruss

Rince

[Fuerchau]

Wie geagt, dies setzt voraus, sämtliche benötigte Quellen zur Verfügung zu haben, was leider im echten Leben (beim Anwender) nicht immer der Fall ist.

[RobertPic]

Die Umstellung einer Datei in 3GL-Programmen (mit Record-Level-Access) bedeutet immer Arbeit.

Ich muss mindestens die Programme, welche neue Sätze schreiben, überarbeiten - die schreiben sonst nur Müll in die neuen Felder.

Bei Feldänderungen gibt es noch viel üblere Sachen wie interne Arbeitsfelder, MOVE CORR's im Cobol (der Feldname kommt im Source dann nicht vor!) usw.

Ein Tool kann bei der Suche und beim parallen weiterentwicklen helfen, aber um eine Analyse des Sourcecodes kommt man nicht herum.

Außerdem ist der anstrengenste Teil von solchen Aktionen meistens das Testen bzw. die Vorbereitung dafür.

Bevor ich ein paar gute Ratschläge verpasst bekomme: Natürlich weiß ich, wie man "wartungsfreundliche" Progamme entwickelt, aber die Altlasten kann man sich ja nicht aussuchen.


Robert P.