Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

[BenderD]

Ich habe den Thread jetzt nicht weiter verfolgt, aber ich habe heute Nachmittag mit Barbara Morris und Scott Forstie gesprochen.

Akutell gibt es keine Möglichkeit Datums-oder Zeit-Formate für eine extern beschriebene Datenstruktur vorzugeben. Bei der Übertragung der Daten wird das DDS-Datums-Format übernommen und das Datum entsprechend aufbereitet in den Buffer übernommen. Sofern kein Datums-Format vorhanden ist (wie bei DDL-Tabellen) wird das Datum im ISO-Format aufbereitet.

Die einzige Möglichkeit, die es aktuell gibt, ist das/die Datums-Feld(er) in der (Referenz-)Datenstruktur/Template umzubenennen und anschließend erneut mit dem Original-Feld, jedoch mit geänderten Datums-Format zu überlagern.

Etwa so (nicht schön dafür selten):

dcl-ds YourDS extname('YOURFILE') qualified;    
   date_x extfld('YOURDATE');                              
   YOURDATE date(*EUR) overlay(date_x);                    
end-ds;

Empfehlung von Barbara Morris und Scott Forstie ist einen RFE (Request for Enhancement - https://www.ibm.com/developerworks/rfe/ zu eröffnen.

Birgitta

... natürlich kann man das Datumsformat eines Feldes einer externen DS festlegen: mit einer DDS. View!!! Ausgangspunkt des hier beschriebenen Problems war die kurzschlüssige Empfehlung DDS beschriebene Dateien durch DDL beschriebene Tables zu ersetzen!!!

D*B

[Fuerchau]

"Sofern kein Datums-Format vorhanden ist (wie bei DDL-Tabellen)..."
Und wenn man mal per DSPFFD eine DDL-Tabelle ansieht, dann wird dort explizit das Datumformat *ISO festgelegt, denn aus dieser Information holt sich der Compiler das Feldformat. Dies ist insofern wichtig, als dass man eben eine DDL-Tabelle auch ohne SQL (z.B. CPYF) bearbeiten kann.
Die Überschreibung des Datumfeldes in der Struktur ist fatal, denn nach jedem Read und vor jedem Write/Update ist der Inhalt dann zu konvertieren.
Allein der Vorschlag vergrößert die Huddelei und erhöht die Gefahr, insbesonders wenn man die Konvertierung vergisst und auf das Feld dann zugreift.
Daher ab damit in die tiefste Tonne.

Die Idee mit der 1:1-View und Anpassung des Datumformates halte ich für (fast) genial!
Das "fast" bezieht sich leider auf eine neuere Möglichkeit der Read/Write-Befehle mit Angabe von Strukturen "read file struct", "write file struct". Dies bietet sich häufig mit Qualified an.
Hier verlangt der Compiler, dass die Struktur von der richtigen Datei mit *likerec definiert wird.
Da habe ich nur die Vermutung, dass der Move dann nicht feldweise erfolgt sondern direkt aus dem/vom Puffer.

Da man Qualified aber auch auf F-Bestimmungen angeben kann, könnte man eben nach dem Read bzw. vor dem Write mit einem eval-corr übertragen. Beim Einsatz von File-Handlern die leichteste Übung.

[BenderD]

... vielleicht sollte man verpflichtend machen, dass man Pascal lernen muss, bevor man die erste Zeile RPG schreiben darf (ich habe dieses Glück gehabt).

Eine Datenstruktur ist reine Speicherbeschreibung und hat den Typ Binärdaten unbekannter Länge - das muss man immer im Hinterkopf haben (eine feinsinnige Ironie der Entwickler des RPG Compilers das Datenstruktur zu nennen, binary huddle wäre angemessener gewesen). Überlagert ist diese dann mit einzelnen Typ-behafteten Feldern. Verwendet man im SQL eine Datenstruktur als Hostvariable wird diese vom Precompiler (!!!) in einzelne Felder aufgelöst, womit implizite casts von Feldern ermöglicht werden.

Kompliziert wird es immer, wenn man Datenstrukturen als ganzes verwendet (Zuweisungen, Parameter, Vergleiche, etc) dann ist jede Änderung an einer DS das verstecken einer Büchse der Pandorra, das kann hier und heute gut gehen und knallt irgendwann, irgendwo.

Mit der einfachen Grundregel, dass eine Datenstruktur sich über die gesamte Lebensdauer einer Anwendung nie ändert, hält man sich alle Büchse der Pandorra Effekte zuverlässig vom Hals.

Bei externen Datenstrukturen basierend auf Dateien ist das durch ein View Layer, das sich aus Entkoppelungsgründen eh empfiehlt, (fast) vollständig sicher zu stellen.

Lässt sich das View Layer bei Änderungen in der Datenbank nicht konsistent halten (z. B.: bei Vergrößerung der Dimension von Schlüselfeldern) ist das ein größerer Redesign Schritt, der umfassend verifiziert werden muss - wer da empfiehlt, das mit einer Anpassung der Feldreferenz Datei und einem recompile abwickeln zu können, dem wünsche ich von Herzen "Viel Glück"!.

Eine komplizierte Sollbruchstelle ergibt sich aus der Unsitte Felder in DSPF und PF/LF gleich zu nennen, da kann es dann ein gleichnamiges Feld mit zwei inkompatiblen Datentypen geben, wovon dann eine Definition Vorrang hat. Dummerweise die im DSPF, was bei der Modernisierung (Guifizierung gefällt mir besser, weil mir das Wort weniger gefällt) zu netten Effekten führt, wenn man die F-Karte des DSPF rausnimmt...

D*B

[Fuerchau]

Noch ein Nachtrag zur View als DS.
Hier hat man leider doch beim Datum ein Problem.
Da ein Feld vom Typ DATE generell in *ISO ist, kann man nur per cast CHAR(Mydate, EUR) umformatieren.
Dabei verliert allerdings das Feld für RPG dei Ausprägung DATE und bei sämtlichen Zugriffen auf das Feld, die ein DATE erwarten, fällt man zur Compilezeit auf die Nase.
Unproblematisch ist das dann, wenn die Struktur übergeben wird, das Zielprogramm aber noch nicht umgewandelt ist.

Da ist es vom Grundsatz halt besser, Schnittstellen zu/von Programmen nie als externe DS zu definieren. Hätte man dies von Anfang an berücksichtigt, wären diese Probleme jetzt gar keine.

Vielleicht baut ihr euch halt einen Generator, der jede Datei als interne DS in einer Copystrecke ablegt und dabei dann ebenso ggf. vorhandene Datumformate anpasst.

[dschroeder]

Mit der Struktur als ganzes haben wir eigentlich kein Problem. Probleme gibt es, wenn wir ein Einzel-Datumsfeld der Struktur per Referenz übergeben. Wir werden als erstes mal versuchen, solche Programmstellen zu finden. Wenn wir den Call prototyped machen, merken wir zumindest beim Compile sofort, ob die Parameterübergabe klappt. Das Problem sind die vielen älteren fixed format Programme, die per CALL-Befehl aufgerufen werden.

[dschroeder]

Empfehlung von Barbara Morris und Scott Forstie ist einen RFE (Request for Enhancement - https://www.ibm.com/developerworks/rfe/ zu eröffnen.
Birgitta

Erstmal danke für die Info. Aber ich muss zugeben, dass ich im Moment noch gar keine Idee habe, wie IBM das Problem lösen sollte. Ich würde sicherlich nicht vorschlagen, im DDL die Möglichkeit einzubauen, Datumsformate mitzugeben. Oder etwa doch?

Ich weiß nicht, ob Barbara Morris und ihr Team in der Lage wären, eine Lösung zu bauen, bei der sie auch bei Parameterübergaben per Referenz immer die korrekte Datumskonvertierung durchzuführen.

[Fuerchau]

Ich weiß gar nicht, warum man für ein lösbares Problem einen RFE machen sollte?
Dann könnte man ja für allen möglichen Unsinn einen RFE machen.

Definiere doch einfach interne Strukturen statt externe und du hast das Problem dann gar nicht mehr.

[dschroeder]

Aber dann müssten wir bei jeder Dateierweiterung 2 Strukturen anpassen. Ich glaube, das
würden meine Kollegen für nervig halten. Redundanz führt ja oft dazu, dass etwas auseinderläuft.

[Fuerchau]

Das ist keine Redundanz sondern der Ersatz.
Ersetze externe Struktur mit interner Struktur!
Solange man dann Felder in der internen Struktur immer am Ende erweitert, und Strukturen "by Reference" durchleitet, muss man auch nicht alle Programme wandeln, sondern nur die, die auf die neuen Felder zugreifen.
Somit man kann man dann sogar alle Quellen mit Suchen und Ersetzen von "DMyDs E DS" auf "/Copy MyIntDS" umstellen und einfach umwandeln ohne das was passiert.

[BenderD]

Noch ein Nachtrag zur View als DS.
Hier hat man leider doch beim Datum ein Problem.

... muss ich auf meine alten Tage nochmal in den längst überwundenen Huddel eintauchen...


A R RECORD
A DATEUR L DATFMT(*EUR)
A DATJUL L DATFMT(*JUL)
A DATISO L DATFMT(*ISO)
A DATSTD L
************************************************** *****
d dates e ds extname(dates)
*---------------------------------------------------------
* Datenstruktur . . . . . . : DATES
* Externes Format . . . . . : RECORD : DSTERNB1/DATES
*---------------------------------------------------------
D DATEUR 10D DATFMT (*EUR.)
D DATJUL 6D DATFMT (*JUL-)
D DATISO 10D DATFMT (*ISO-)
D DATSTD 10D DATFMT (*ISO-)


jetzt nochmal Klartext, so von Dieter zu Dieter:

Tut mir leid, richtig leid tun tut ihr mir nicht wirklich, das was ihr da habt, ist der Fluch der bösen Tat.

- da werden ohne große Not Programme gleich im Paket geändert und dabei werden Deklarationen, von denen man nicht einmal genau weiß, wo sie alle drinstecken geändert. Da werden unter gleichem Namen aus Äpfeln Birnen. Dann lässt man das ohne große Verifikation mal in Produktion fliegen und ändert dabei fleißig weiter. Wenn ich das richtig verstanden habe, hat man selbstverständlich nicht einmal alles betreffende neu gewandelt, geschweige denn neu gebunden, sondern sich vermutlich auf handgesetzte Signaturen und Binder language verlassen (hätte man nämlich neu gewandelt und gebunden, wäre der Murks zumindest bei den SRVPGMs aufgefallen).

Mildernde Umstände sehe ich einzig darin, dass es da "Experten" gibt (in größerer Zahl und durchaus rennomierte) die genau diesen Unfug in Schulungen erzählen, in Artikeln verbreiten und in Foren empfehlen. Mir wäre dies nicht passiert, da bin ich absolut sicher - auch wenn ich mir selber nur selten wirklich traue!!!

Um das Kind wieder aus dem sprichwörtlichen Brunnen zu holen empfehle ich:
- als erstes alles komplett neu binden, dann sollten euch schon mal die SRVPGMs um die Ohren flliegen und dann kennt ihr erst mal das erste Paket an betroffenen Dateien.
- alle Programme mit Parameterschnittstellen ohne Verwendung von Prototypen, die externe Datenstrukturen beinhalten und früher als die Dateien gewandelt wurden abgleichen. Das lässt sich ein wenig automatisieren mit DSPPGMREF und DSPOBJD, sowie DSPFFD.

D*B

[Fuerchau]

"Mildernde Umstände sehe ich einzig darin, dass es da "Experten" gibt (in größerer Zahl und durchaus rennomierte) die genau diesen Unfug in Schulungen erzählen, in Artikeln verbreiten und in Foren empfehlen."
Dem kann ich nur zustimmen (auch wenn da nun wieder jemand sauer wird und sich in R... beschwert).

[andreaspr@aon.at]

Im Forum gibt es viele Leser und und ihr sollt wissen, dass viele hier, die Art und Weise wie ihr zwei über andere herzieht nicht OK finden!
Ich dachte, das hättet ihr auch schon in den früheren Beiträgen schon erkannt. Dem scheint nicht so.
Was mich bei dem ganzen am meisten stört, ist dass die Qualität des Forums auch sehr darunter leidet.
Wir können ja gern mal eine Abstimmung machen (z.B. "Umgang mit anderen"), falls euch die bisherigen Feedbacks zu wenige sind.