Felderweiterung in der DDS von 6,0 auf 8,0

[tarkusch]

Hallo,

ich habe diesbezüglich schon mal was gepostet, finde es aber leider nicht mehr in diesem Forum.

Bei uns steht eine Felderweiterung(Bestellnummern) an, da die Nummern ausgehen.
Dieses Feld ist zugleich auch das einzige Keyfeld in der Datei

Ich hätte mir überlegt 2 Feldrefernzdateien in unterschiedlichen Libarys zu erstellen.

Mit DSPFFD hätte ich mir in eine Datei erstellt wo ich nach Feldern(6, 0) suche die eventuell eine Bestellnummer sein könnten.

Im Pgm und den Displayfiles könnte ich dann mit der Refernzdatei arbeiten, aber wie löse ich das am geschicktesten in der DDS des PF-FIlES?

Irgendwie fehlt mir ein vernünftiger Plan.

Hättet ihr Tips wie ich das am sichersten angehe?
Tools wird es dafür sicher keine geben.

Dank im Voraus

Tarki

[Fuerchau]

Ich sag mal so: Wenn Ihr nach Plan vorgegangen seid, dann habt Ihr eine Feld-Referenzdatei (REFF) in jeder Tabelle verwendet.
Per DSPFFD wird ebenso der Name des Referenzfeldes ausgewiesen. Nun sollte das Referenzfeld auch ebenso eindeutig einer Funktion (z.B. Bestellnummer) zugewiesen sein.
Damit ließe sich dieses dann erweitern und alle betroffenen Dateien und dann die Programme sind neu zu erstellen, PF's einfach mit CHGPF und Angabe der Quelle.
Allerdings hört es da ja nicht auf:
Weiterverwendung in DSPF/PRTF's, ggf. mit Referenz, vielleicht eher aber auch nicht.
Erweiterung führt meist zu Verschiebungen des Layouts.
Wie siehts aus mit internen Variablen (Like kam erst mit ILE), einfachen Hilfsvariablen mal so eben verwendet (WKN060, o.ä.) um schnell zwischen Zeichen und Zahl zu wandeln (MOVE!).

Fazit:
Eigentlich kann man sowas vergessen.

Aber:
Nun kann ich mir nicht vorstellen, dass ihr tatsächlich 999.999 Bestellnummern im System verbraten habt bzw. verbraten werden.
Gedanklich bietet sich da eher eine Archivierungsfunktion an, in der man alle Daten, die zu einer Bestellung gehören (so viele sind das ggf. nicht) in einem 2. Set von Dateien archiviert und aus den Originalen entfernt.
Und Schwupps, sind die ganzen Nummern wieder frei.
Falls man an die "Altdaten" noch mal dranmuss, kann man dies über eine entsprechende Anzeigeumgebung (Libliste, nur Anzeigen) oder mittels BI-Tool.

Ein solcher Ansatz ist eher planbar, durchfürbar, sicherer und erheblich weniger kostenintensiv.

[tarkusch]

Ich sollte Kundennummern auch anheben(5,0 dzt.) und wollte mir daher die Erweiterung der Bestellnummer als erstes vornehmen.

Leider ist hier nicht nach Plan vorgegangen worden da die Datei 1989 erstellt wurde.
Niemand hat da an die Feldreferenzdatei gedacht(ändern wollte es auch niemand bis dato).

Weiter haben sich bei den Programmen Externe Mitarbeiter verwirklicht, dadurch hat es bei uns auch nie Programmrichtlinien gegeben.

Mir ist bewusst das das sehr Risikohaft und zeitraubend ist , aber es bleibt mir leider nicht erspart.

Wollte mir daher hier einige Tips bzw. Erfahrungswerte vom Forum holen.

[Fuerchau]

Da gibt es leider keine Erfahrungswerte meinerseits und ich habe schon viel mitgemacht.
Hier hilft nur, per DSPPGMREF die Objekte der PF-Dateiverwendung aufzulisten und sämtliche Quellen dann manuell durchzuforsten. Incl. Copystrecken und ggf. Unterprogramme (CALL!), die ggf. Strukturen mit den Felder als Parameter durchrouten.
Layout von DSPF/PRTF's anpassen usw. usf.
Wenn du im Schnitt 2 Tage/Programm ansetzt und ca. 100 Programme hast, weißt du ja was es bedeutet.
Und zum Schluss: testen, testen, ..., und noch mal testen.

[BenderD]

... ich würde jedenfalls versuchen die Implementierung nicht im Big Bang zu machen. Sprich mit den PRTFs und den DSPf und den daran hängenden Programmen anfangen. Ansonsten hängt die Vorgehensweise natürlcih stark davon ab, ob da mit RLA Daten zusammengeklappert werden, oder per SQL auf Views zugegriffen wird.

D*B

[Fuerchau]

Nun, ich würde da eher von Glück sprechen, wenn die Programme schon auf RPG umgestellt sind und nicht z.T. (das gibts immer noch) noch in RPT sind.
Von SQL mag ich da gar nicht reden.

[dschroeder]

Meine Idee wäre es, die Datei um ein neues 8-stelliges Bestellnummernfeld zu erweitern. Dann einen Trigger auf die Datei setzen, der die alte 6-stellige Nummer in das neue Feld kopiert.

Dann könnte man peu a peu die Programme anpassen. Es wäre dann erstmal egal, ob die Programme noch auf die alte oder schon auf die neue längere Nummer zugreifen. Es steht ja immer das gleiche drin.
Das Verfahren würde es ersparen, eine riesige Testumgebung für eine lange Zeit aufzubauen. Wenn die Datei erweitert ist und der Trigger läuft, könntet ihr das schon wieder in der Echtumgebung haben.
Am Gesamtaufwand ändert das natürlich nichts.


Dieter

[tarkusch]

In der alten Datei ist die KDNNR nicht referenziert.
Wenn jetzt REF_KDNNR auch 5, 0 ist, ändert sich ja die nach chgpf der
Level identifier nicht.
Nehme ich da richtig an das ich dann auch keine Programme kompelieren muss?

Mein Gedanke ist, das ich mal alle Kundennummern, die in anderen Files abspeichert werden, mal fürs erste referenziere.

 
****************************************************************  
*           K U N D E N S T A M M                              * 
 **************************************************************** 
A                                      UNIQUE                     
A          R T_KUND                    TEXT('KUNDENSTAMM')        
A*                                                                
A****        KDNNR          5  0       TEXT('Kundennummer')       
A****                                  COLHDG('KdnNr')            
A            KDNNR     R               REFFLD(REF_KDNNR GLOBALP)  
A            :                         TEXT('KUNDENNUMMER')       
A            :                         COLHDG('KdnNr')            
A*           :                                                     
A          K KDNNR

[Fuerchau]

Auch der Feldtyp darf sich nicht ändern. Man sollte nach Möglichkeit keine Defaults verwenden sondern den Typ immer genau angeben (P oder S), da sich dieser theoretisch auch mal ändern könnte.
Ob sich was ändert kann man mit einem DSPFD/DSPFFD prüfen.