Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

[dschroeder]

Hallo,
ich möchte euch mal kurz mein Leid klagen, auch wenn ich glaube, dass ihr mir nicht helfen könnt:

Wir haben von 25 Jahren beim Beginn der Programmierung unserer Anwendung wahrscheinlich einen Designfehler gemacht: Wir haben damals festgelegt, dass alle Datumsfelder in allen Dateien und Programmen das Format *EUR haben sollen. (Zeitfelder *HMS). Die Tabellen wurden damals mit DDS beschrieben.

Wir definieren sehr häufig auf den Tabellen basierende externe Datenstrukturen, mit denen wir einen gelesenen Datensatz an andere Programme weiterreichen. In diesen Datenstrukturen liegt ein Datumfeld natürlich im Fomat TT.MM.JJJJ vor. Seit einiger Zeit setzen wir aber verstärkt auf DDL. SQL kennt aber bei Tabellenbeschreibungen kein Datumsformat. Es ist immer *ISO. Wenn wir jetzt eine DDS-beschriebene Tabelle auf DDL umstellen, ist die darauf basierende externer Datenstruktur zwar weiterhin genau so groß, wie die alte auf DDS basierende Datenstruktur, aber das Datumsfeld hat jetzt die Form JJJJ-MM-TT. Wenn man so ein Datumsfeld jetzt per Referenz an ein anderes Programm weitergibt, knallt es. ("Datums-, Zeit- oder Zeitmarkenwert ist ungültig").

Hat vielleicht noch jemand dieses Problem festgestellt und eine praktikable Lösung parat? Man hört ja in jedem Kurs, dass es sinnvoll ist, seine Dateien auf DDL umzustellen bzw. neue Tabellen mit DDL zu erstellen. Aber die Problematik mit Altanwendungen wurde dabei bisher nicht deutlich.

Dieter

[Fuerchau]

Das ist dann tatsächlich ein Problem.
Durch die Festlegung des DATFMT's auf Feldebene der Tabelle erwarten die Schreibroutinen genau dieses Format und geben dieses eben auch aus.
Eine Konvertierung gibt es hier nicht (auch wenn Birgitta immer das Gegenteil behauptet hat).
Aber wo ist denn das Problem?
Wenn eine Datei von DDS in DDL umgestellt wird, müssen doch alle Programme sowieso umgewandelt werden. Dazu gehören eben nicht nur die Programme, die die Datei verwenden sondern auch alle, die die Dateistruktur als Parameter übergeben oder erwarten.
Somit arbeiten dann alle mit demselben Datumformat.

Wenn ein Datumvariable in eine andere mit anderem Format übertragen wird, erfolgt auch eine Umwandlung.
Wird allerdings eine DS als Ganzes kopiert, gibt es später einen Datenfehler, da die DS als Zeichenvariable verwendet wird. Dies wird dann ggf. das Hauptproblem sein.

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

Wenn eine Datei von DDS in DDL umgestellt wird, müssen doch alle Programme sowieso umgewandelt werden. Dazu gehören eben nicht nur die Programme, die die Datei verwenden sondern auch alle, die die Dateistruktur als Parameter übergeben oder erwarten.

Bei der Umstellung von DDS nach SQL müssen die Programme NICHT neu umgerwandelt werden, da sich das Format-Level nicht ändert!

Probier's diesmal aus aus bevor Du wieder behauptest, dass ich Schwachsinn verzapfe!
Und schau die außerdem, die Hex-Werte der gleichen "Datümmer" in unterschiedlichen Datums-Formaten in DDS-beschriebenen Dateien an. Die Konvertierung geschieht durch RPG oder Tools wie WRKF.

@Dieter: Das Problem ist die RPG-Datenstruktur bzw. die Konvertierung durch RPG.
Was für ein Datums-Format habt Ihr in den H-Bestimmgungen hinterlegt?

Birgitta

[Fuerchau]

Das Datumformat in den H-Bestimmungen bestimmt das Format für Datumsfelder ohne eigenes Datumsformat!
Bei einer SQL-Tabelle wird das Datumsformat mit *ISO festgelegt und es gibt keine Möglichkeit dies zu ändern.
Definiere ich eine "E DS" wird das Datumsformat aus der Datei übernommen.
Wenn ich das Datumsfeld umbenenne und versuche, das Format zu ändern, lehnt das bereits der Compiler ab.
Und ja, ich habe es ausprobiert und viel gesucht und gegoogelt. Du hast keine Chance mehr, das Datumsformat zu ändern.
Klar ändert sich die ID nicht, aber das ist ja das fatale.
Wenn du dann versuchst mit dem EUR-Format des nicht neu umgewandelten Programmes Daten mit dem ISO zu lesen oder zu schreiben gibt es wieder was um die Ohren.
Der Grund ist hier tatsächlich, dass die EA-Schnittstellen das Feld einfach durchroutet und die Datenbank dann versucht das definierte Datumsformat in das interne Format umzwandeln, was natürlich nicht geht.
Beim Lesen gibts wieder was auf die Finger, da dann die RPG-Runtime beim Zugriff auf das erwartete EUR-Format scheitert, da die DB dem Programm ISO übergeben hat.

Wenn deine DDS-Datei bereits vorher mit ISO gearbeitet hat, dann gebe ich dir recht, dass eine Totalumwandlung nicht erforderlich ist.

Fazit:
Das Datumformat ist für die Kommunikation zwischen Programm und DB bei native-Zugriffen von entscheidender Bedeutung.
Bei SQL hast du dann die Freiheit, mit einem anderen Datumsformat zu arbeiten, da die SQL-Schnittstelle zwischen Hostvariable und generierter Variable wandelt und ggf. noch bei der DB-Schnittstelle anpasst. Aber das kann dem Programmierer egal sein, solange in SQL und RPG konvertierbare Formate verwendet werden.

[BenderD]

@Dieter: Das Problem ist die RPG-Datenstruktur bzw. die Konvertierung durch RPG.
Was für ein Datums-Format habt Ihr in den H-Bestimmgungen hinterlegt?

Birgitta

... das Problem ist die Änderung von Parameterschnittstellen (das letztlich durch Schwächen des RPG Compilers ausgelöst ist - ähnliche Probleme gibt es auch bei like definitions auf Felder, die in einem Dsiplayfile und in einem Database File gleich heißen ). Stabil wird das ganze, wenn man die Bezüge auf externe Datenstrukturen aus Prototypen komplett rausnimmt, das über die H Bestimmungen bereinigen zu wollen, zieht nicht durch, die kommen nicht aus den Copystrecken mit den Prototypen.

D*B

PS: welcome back Birgittta

[Fuerchau]

Und noch mal für alle Technikbegeisterten:
Dateizugriffe erfolgen, egal mit welchen Methoden im Endeffekt mit den Routinen
QDBGETxxx (Leseroutinen)
QDBPUTxxx (Schreibroutinen)
Diese Methoden arbeiten bei der Parameterübergabe mit sog. Dateikontrollblöcken sowie einem Satzpuffer.
Dieser Satzpuffer entspricht genau dem Aufbau, den man sich per DSPFFD ansehen kann und die Feldausprägungen und Positionen im Satzpuffer sind genau so festgelegt.
Dazu gehört nun (leider) auch das Feld mit Datumsformat!
D.h., dass die Leseroutinen bereits im Satzpuffer das Datumformat so liefern, wie es beim Erstellen der Datei festgelegt wurde und im Gegenzug das Datum auch genau in diesem Format erwarten.
Die DB-Runtime speichert dann das Datum in der von Birgitta erwähnten "Scaliger Nummer".

Schaut man sich das Ganze dann in SQL an, so stellt man fest, dass SQL im Endeffekt genauso auf die QDBGET/QDBPUT-Funktionen zugreift.
In Folge dessen muss auch SQL genau mit dem Datumformat arbeiten, dass die Datenbank für das definierte Feld festlegt. SQL hat den Vorteil, dass Datumkonvertierungen, soweit möglich, automatisch durchgeführt werden können. Hierfür gibt es i.Ü. sogar MI-Befehle (CVTD, CVTT, CVTTS), die die diversen Umformatierungen vornehmen können.

Somit erklärt sich also der obige Sachverhalt eindeutig, dass das Datumformat eines Dateifeldes nicht geändert werden kann.
Dies gilt für OPM-Programme genauso wie für ILE-Programme, da die DB-Schnittstellen (QDBGET/QDBPUT) in allen Verwendungen identisch ist.

Quellen:
COBOL-Umwandlungliste mit MI-Output
RPG-Umwandlungsliste mit MI-Output
In diesen Listen kann man erkennen, dass die Aufrufe direkt die Datenpuffer mit dem benötigten Datenformat enthalten.
Hier kann man auch erkennen, dass COBOL mit den Satzpuffern direkt arbeitet, während bei RPG/LE nach dem Read Moves mit den Übertragungen aus dem Satzpuffer in die Felder und beim Write Moves aus den Feldern in den Satzpuffer erfolgen.

Über TRCJOB kann man die Aufrufebenen vom Programm über QSQxxx bis hin zu QDBxxx genau verfolgen.

Fazit:
Die Scaliger-Nummer ist eine Speicherung in der Datenbank und hat mit SQL überhaupt nichts zu tun.
Oberhalb der DB, also SQL und Native-IO muss mit einem korrekten Datumformat passend zur Datei gearbeitet werden.

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

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