View Full Version : Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme
Die ILE-Integration mit V4 war damals noch nicht so besonders. Aber die Konzepte gab es schon.
Und Felder mit Datum-Format gab es sowieso nur in ILE.
In OPM waren und sind das immer nur Char-Felder und da kann dann auch Müll drinstehen.
Da aber wie bei euch auch gerne Strukturen als Parameter übergeben werden und diese meist sowohl Parameter als auch Returnwerte enthalten muss man das so hinnehmen.
Ich muss zugeben, die Ideen von D*B klingen vernünftig. Ich habe ja bereits gesagt, dass ich die Sache mit dem View Layer bei uns mal anspreche. Die anderen Punkte nehme ich dann auch gleich mit auf.
Der Punkt mit den 95% Kunstfehler bei Referenz ist aus meiner Sicht richtig, wenn man die alten Anwendungen aus heutiger Sicht betrachtet. Vor 20 Jahren hat man aber die meisten Programme als normale Programme (also Nicht-Serviceprogramme) geschrieben (Ich weiß gar nicht, ob damals Serviceprogramme schon gingen). Und da hat man einfach PARM-Anweisungen verwendet. Das war der Standard. Und das sind nun mal Calls per Reference. Ich weiß nicht, ob man damals die Parameter von "normalen" Programmen als const definieren konnte. Ich habe das jedenfalls nirgendwo gesehen.
... das mit den "Altlasten" ist richtig, vor ILE und Prototyping war alles per Reference. Aber auch hier habe ich eine einfache Empfehlung:
- keine Aufrufe von Altprogrammen neu einbauen stattdessen:
-- SRVPGM als wrapper mit stabilisierter Schnittstelle erstellen und verwenden
-- packt man Programme mit Aufruf alt neu an, umhängen
-- Implementierung bei Änderung an neu hängen und alt zum Wrapper machen
Für technische Schönheit verbrennt man keinen Aufwand, bei Neu Entwicklung oder Änderung Redesign Aufwand vorsehen, so kommt man schrittweise zu modernisierten Anwendungen. Was alt ist, funktioniert und keinen Änderungsaufwand verursacht, kann alt bleiben!!!
D*B
dschroeder
09-05-17, 08:18
OK, danke nochmals an alle für die guten Vorschläge!
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
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
"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.
... 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
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
10-05-17, 12:03
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
10-05-17, 12:09
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.