Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

[dschroeder]

Vielen Dank für die vielen und ausführlichen Antworten. Sowie ich es verstehe, habe ich ein Problem und es gibt keine einfache und schöne Lösung. Ich weiß, dass Dieter Bender die Lösung mit den Views favorisiert. Aber so richtig kann ich mich noch nicht damit anfreunden. Aber ich verspreche, darüber nachzudenken und das mit meinen Kollegen zu diskutieren!

Nochmal zu Baldurs erster Antwort, in der er schreibt, dass es kein Problem gäbe, da ja sowieso jedes Programm umgewandelt werden müsse: Zum einen sehe ich es wie Birgitta. Eigentlich müsste man gar nicht neu kompilieren. Zum anderen hätte ich leider immer noch ein Problem, selbst wenn ich alles umwandle: Wir übergeben das Datumfeld per Parameter (und zwar per Referenz) an ein weiteres Tool. Das Tool empfängt nicht die gesamte Datenstruktur, sondern nur ein Datumsfeld. (Das Tool weiß gar nicht, dass das Datumsfeld aus einer Datenstruktur stammt). Und dabei knallt es, da das Tool einen Eingangsparameter von Typ *EUR erwartet.

Meine Tests haben ergeben, dass nur diese per Referenz empfangenen Parameter ein Problem machen. Wenn ich einen Parameter per CONST empfange, wird scheinbar eine Konvertierung des Datums durchgeführt.

Und zu Birgitta (schön, mal wieder etwas von dir zu lesen): Wir haben explizite H-Bestimmung nur in Serviceprogrammen. Dort steht *EUR drin. Unabhängig von den H-Bestimmungen haben wir alle Datumsfelder aber auch nochmal bei den dcl-Anweisungen mit datfmt(*eur) deklariert (klar ist das unnötig, aber von 25 Jahren haben wir uns wahrscheinlich gedacht "Doppelt hält besser").

Dieter

[BenderD]

Wir übergeben das Datumfeld per Parameter (und zwar per Referenz) an ein weiteres Tool. Das Tool empfängt nicht die gesamte Datenstruktur, sondern nur ein Datumsfeld. (Das Tool weiß gar nicht, dass das Datumsfeld aus einer Datenstruktur stammt). Und dabei knallt es, da das Tool einen Eingangsparameter von Typ *EUR erwartet.

... mal blöd gefragt, warum schreibt ihr nicht einfach einen Wrapper, der das passend macht und an das Tool übergibt? oder verstehe ich das was falsch?

D*B

[Fuerchau]

Was die Umwandlung angeht, so sieht Birgitta dies leider auf auf Grund des Datumformates falsch.
Wie ich oben schon beschrieben habe, errechnet sich die Satzformat-ID leider nur über die Feldtypen und nicht zusätzlich über das Datumformat. Wenn man ein Datumformat *DMY hinterlegt hat, ist das Feld in der Struktur nur CHAR(6)!
Wenn sich also das Datumformat der Datei ändert, ändert sich leider die Satzformat-ID nicht und wenn man dann nicht alles umwandelt, knallt es dann an irgendeinder Stelle mit der man ggf. nicht gerechnet hat.

Die Definition für die Übergabe als CONST incl. Datumformat führt genau zu der Lösung, dass die Runtime bei der Übergabe das Datum umformatiert.

Was die H-Bestimmung angeht, so definiert diese nur das Datumformat für die Felder, die nicht explizit ein eigenes Datumformat aufweisen (wie eben extern definierte Felder). Somit ist die H-Bestimmung letztlich egal wenn sie denn für alle Programme identisch ist.
Auch hier gilt leider:
Ist die H-Bestimmung nicht besetzt, wird das Datumformat
a) über die Default-DTAARA für H-Bestimmung
b) über das Job-Datumformat zur Compile-Zeit
bestimmt. Somit verliert man u.U. in mehrsprachigen Entwicklungen die Einheitlichkeit.

Übrigens was auch geht:
Ich habe mal die externe DS als interne DS mit allen Felder und Anpassung des Datumformates durchgeführt. Die Schreiblese-Routinen berücksichtigen nun das definierte Datumformat.
Vielleicht ist das ja eine Lösung in dem ihr alle Schnittstellen statt als "E DS" als DS anlegt und per COPY einbindet. Der Aufwand ist ggf. geringer da man die DS ja aus einer Umwandlungsliste herauskopieren kann.
Bei Ergänzungen mit neuen Feldern muss man dann halt die DS anpassen.

[dschroeder]

Übrigens was auch geht:
Ich habe mal die externe DS als interne DS mit allen Felder und Anpassung des Datumformates durchgeführt. Die Schreiblese-Routinen berücksichtigen nun das definierte Datumformat.
Vielleicht ist das ja eine Lösung in dem ihr alle Schnittstellen statt als "E DS" als DS anlegt und per COPY einbindet. Der Aufwand ist ggf. geringer da man die DS ja aus einer Umwandlungsliste herauskopieren kann.
Bei Ergänzungen mit neuen Feldern muss man dann halt die DS anpassen.

Das ginge wahrscheinlich, aber es würde zu hohen Aufwand bedeutet. Wir suchen ja nach einer allgemeingültigen Lösung für tausende Dateien. Ggf. müssten wir alle Datumsparameter aller Programme prüfen und sie auf const umstellen. Wäre natürlich auch ein Heidenaufwand. Außerdem ist das natürlich leichter gesagt als getan. Man müsste dann an manchen Stellen auch die Logik verändern.

[Fuerchau]

Dann gibts für euch auch nur die Lösung bei DDS zu bleiben.
Wenn ihr vernünftig mit Copystrecken gearbeitet habt und auch Prototypen entsprechend in Copy's stehen sehe ich da nur ein geringeres Problem. Ansonsten wird hier wirklich Chaos ausbrechen.

Vielleicht könnt ihr euch ja auch für die interne DS als Copy einen Generator bauen.

[dschroeder]

... mal blöd gefragt, warum schreibt ihr nicht einfach einen Wrapper, der das passend macht und an das Tool übergibt? oder verstehe ich das was falsch?
D*B

Das Problem liegt nicht in dem einen Beispiel, das ich beschrieben habe. Wenn es nur um eine Datei ginge, wäre das alles kein Problem. Ich habe das Problem nur so beschrieben, dass es einfach zu verstehen ist. Wir haben ein paar tausend Dateien, die DDS beschrieben sind. Und wir haben inzwischen wahrscheinlich 100 Dateien, die DDL beschrieben sind. Jetzt ist uns das Datumsproblem zum ersten mal aufgefallen. Die (neueren) DDL beschriebenen Dateien haben oft einen "neueren" Aufbau, das heißt sie nutzen Timestamp Felder anstatt Datum und Uhrzeit. Wahrscheinlich ist das Problem bei uns deshalb noch nicht sehr verbreitet. Wir überlegen aber, alle DDS beschriebenen Dateien auf DDL umzustellen. In diesem Fall müssten wir aber jede Programmstelle finden, bei der irgendein Datumsfeld unserer externen Strukturen per Referenz (ohne const) übergeben wird. Das lässt sich kaum machen. Vielleicht haben wir nicht nur 1 Tool, sondern 250, bei denen das Problem auftritt. Das kann ich so gar nicht sagen.

Dieter

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

[dschroeder]

Im Moment sehe ich für uns auch keine Möglichkeit der totalen Umstellung. Zur Zeit fahren wir die Strategie, neue Tabellen mit DDL zu beschreiben. Wir nutzen dann z.B. autogenerated Keys. Unsere Dateizugriffe machen wir seit längerem bei neuen Programmen nur noch per SQL. Bei Programmänderungen werden oft auch alte Programme auf embedded SQL umgestellt. Es ist eben nur so, dass ein Datumsfeld der neuen DDL beschriebenen Tabellen ja vielleicht auch mal an ein "altes" Programm per Referenz übergeben wird. Dann knallt es. Es ist sehr unschön, dass jeder Programmierer jetzt im Hinterkopf haben muss, wie die Tabellenstruktur beschrieben ist (DDS oder DDL). Bisher habe ich nicht gedacht, dass das einen Unterschied macht.

Wir setzen häufig Tools ein, um Datensätze (also extern beschriebene Datenstrukturen) zu lesen und zu schreiben. Durch die Namenskonventionen weiß ich genau, wie ein bestimmtes Tool für eine Datei heißt, bzw. ich kann mir den Toolnamen aus unserem Repository heraussuchen. Die Dateien gucken wir uns oft mit SQL an, oder mit einem Browsertool, das uns die Strukturen auflistet oder wir nutzem einfach die Kontexthilfe mit Rdi (Strg + Space), um die Felder einer Datenstruktur angezeigt zu bekommen. Diese Information reichts jetzt eigentlich nicht mehr. Eigentlich müsste ich immer, wenn ich mit einem Datumsfeld hantiere, konkret in die Dateibeschreibung schauen, um nachzusehen, ob die Datei mit DDS oder mit DDL beschrieben ist.

Das finde ich so unschön.

[Fuerchau]

Wenn du mit SQL umgehst, ist das nicht relevant wie die Datei definiert ist, sondern wie du die Hostvariablen deklarierst. Wenn du allerdings Hostvariablen wiederum als externe DS definierst stehst du vor dem selben Problem.

Das selbe gilt auch für die schönen Prototypen, die ausschließlich zur Compilezeit geprüft werden. Eine Laufzeitprüfung, die ggf. Typsicher wäre, erfolgt nun mal nicht.

Anscheinend erfolgt auch keine Prüfung des Prototyps bei abweichendem Datumformat. Hier erfolgt generell ein ausschließlicher Felddefinitionsvergleich ohne Datumsformat.
Da kann man sich dann gar nicht sicher sein, dass sowas dann gutgeht.

Auch finde ich es (persönlich) seltsam, Schnittstellen auf Basis EUR-Date zu definieren wo man doch schon seit Jahrzehnten weiß, dass nur ein ISO-Date immer und überall kompatibel ist.

Da hilft auch alles Jammern nicht. Du musst halt den schweren Weg der Vorabanalyse gehen und zumindest was die externen (unbeeinflussbaren) Schnittstellen angeht, hier die Prototypen auf CONST umzustellen.

[BenderD]

Zur Zeit fahren wir die Strategie, neue Tabellen mit DDL zu beschreiben. Wir nutzen dann z.B. autogenerated Keys. Unsere Dateizugriffe machen wir seit längerem bei neuen Programmen nur noch per SQL. Bei Programmänderungen werden oft auch alte Programme auf embedded SQL umgestellt.

Bis dahin bin ich ja völlig bei Dir. Was mir fehlt ist:
- neue Funktionen Parameter nur noch per VALUE (oder CONST, falls Programm oder als Implementierung einer externen SQL Function.
- Bei Änderung von Funktionen neue Schnittstelle (VALUE) zufügen.
- bei Änderung von Verwendung in Programmen auf VALUE umhängen.
- bei partiellem Redesign Datenbank: View Layer zur Entkoppelung einziehen
- bei Neuverwendung oder Änderung keine Zugriffe mehr auf das physical Layer.
-- jetzt kann man das physical Layer auf SQL DDL umstellen

Strategie hierbei, alte Welt zurückdrängen, um Freiheitsgrade im Datenbank Redesign durch Entkoppelung zu gewinnen. Wenn für eine Datei/Funktion die alte Welt nur noch marginal gebraucht wird, kann man (muss man aber nicht) rückbauen.

D*B,

der sich alle Probleme, die man nicht haben muss, gerne vom Hals hält!

PS: @Baldur: Datums Parameter per value oder const werden immer passend gemacht - und Übergabe per Reference ist in > 95% aller Fälle ein Kunstfehler.