-
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.
-
... 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
-
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.
-
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
-
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.
Code:
****************************************************************
* 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
-
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.
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks