Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

[Fuerchau]

Dann wäre die interne DS mit dem angepassten Datumformat die Lösung.

[BenderD]

Wir überlegen aber, alle DDS beschriebenen Dateien auf DDL umzustellen.

... was soll das für einen Sinn machen? Das Problem ist nicht DDS oder DDL, das Problem ist RLA oder SQL!!!

D*B

[Fuerchau]

Da muss ich Dieter auch zustimmen. Das Datumformat ist leider ein kritischer KO-Punkt für solche Vorhaben. Und was ist denn tatsächlich damit gewonnen?
Außer der Indexblockung von 64-KB statt 4KB gibt es keinen Unterschied und von der Performance her gibt es auch eher marginale wenn überhaupt messbare Unterschiede. REUSEDLT(*YES) kann man auch schon bei DDS einsetzen.
Da ist es schon gravierender VARLEN-Felder in den Satz zu definieren an Stelle dies dem Zufall zu überlassen, denn im Satzaufbau ändert sich dadurch nichts, aber man spart echte IO's.
Oder bei SQL-Zugriffen vernünftige Indexanalyse oder Statementanalyse zu betreiben.

[BenderD]

... das was viele nicht wahrhaben wollen: ein Datentyp ist ein Datentyp und ändert sich nie!!! Ein Record Format ist ein Datentyp und ändert sich nie!!! (only fools are recommending such things) Mit anderen Worten:
Wenn ich eine Datei habe, die gegenwärtig mit DDS erstellt ist und ich will das auf DDL umstellen, dann kriegt die DDL Variante einen anderen Namen und dann kann ich darauf eine View bauen, die den alten Namen trägt und auch wieder mit DDS erstellt wird. (An dieser Stelle muss ich Dich korrigieren: "Man hört ja in jedem Kurs..." ist definitiv falsch: so einen Unsinn würde ich nie propagieren...)

Was jetzt Schnittstellen angeht: Eine Parameterschnittstelle ändert sich nie (only fools...) In euerm Fall kommt jetzt in den Modulen eine zusätzliche Procedure hinzu (das Thema mit ein Modul = eine procedure hatten wir beide ja schon), in RPG muss die anders heißen, da es kein overloading gibt, die alte Welt verwendet die bisherige, die neue Welt die neue, intern wird umgesetzt und die Implementierung gibt es nur einmal. Ziel ist dabei die DDS Welt komplett zurückzubauen (darf Jahre dauern) und irgendwann kann man die toten Äste beseitigen.

D*B

[B.Hauser]

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

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

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