Umstellung DDS auf DDL, Datum- und Zeitformat macht Probleme

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

[dschroeder]

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.

[Fuerchau]

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.

[BenderD]

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]

OK, danke nochmals an alle für die guten Vorschläge!