Anmelden

View Full Version : DDS COMP



Seiten : 1 [2]

hel400
25-06-15, 07:46
Vielleicht solltest Du mal Deinen Kunden oder Chef dezent darauf hinweisen, dass DDS "stabilized" ist, und das bereits seit Release V5R3 (da gab es die letzte Änderung).
Alle neuen Änderungen nur in SQL erfolgen, auch die die "Erweiterung" des DDS betreffen. Release 6.1 war sogar ein Release, in dem man sich in erster Linie um Erweiterungen in SQL für naitve I/O gekümmert hab.

Empfehlung der IBM ist es alle neuen Datenbankenobjekte nur mit SQL zu erstellen und die vorhandenen peu à peu zu konvertieren.

Leider tragen solche "hartgesottenen Ignoranten" auch maßgeblich dazu bei, dass die IBM i den Ruf als veraltet und überholt hat, obwohl sie eigentlich die modernste Maschine ist. Man schmeißt im Endeffekt lieber die ganze Maschine mit allem drum und dran raus zugunsten einer Umgebung, in der DDS und native I/O eh' keine Rolle mehr spielen, als die vorhandenen Möglichkeiten zu nutzen.

Birgitta



Entschuldigung im Voraus für das komplette *offtopic*, aber das muss jetzt auch mal raus:

Ich bin nunmehr (inkl. Ausbildung) seit knapp 40(!) Jahren in der IT-Branche (damals sagte man noch EDV ...), meinen ersten Job als 16-Jähriger hatte ich als RPG-Programmierer bei der Öst. Niederlassung der Bayer Leverkusen auf einer IBM 370 (alles noch mit Lochkarten...), dnach S/38 und schließlich AS/400, die letzten 20 Jahre als Selbständiger.
Die Entwicklung dieser wirklich tollen Maschine habe ich also von Anfang an miterleben dürfen.
Zunächst war die AS/400 quasi ein "Selbstläufer", da die zahlreichen S/36- u. S/38 Anwender in Scharen die AS/400 kauften.
Was aber (zumindest im Deutschsprachigen Raum) immer aufgefallen ist, war das praktisch nicht vorhandene Marketing seitens IBM (wohlgemerkt nicht schlechtes - sondern überhaupt nicht vorhandenes!). Außer uns Anwendern hat das Ding praktisch (fast..) niemand gekannt. Man musste als Kunde danach gezielt suchen und fragen - anders wäre man nie auf diese Systemschiene gekommen.
Auch in den (Österreichischen) Fach- u. Hochschulen war das ebenso, das System wurde totgeschwiegen und die IBM machte nichts, aber auch wirklich NICHTS, um das zu ändern.
Als dann in den 90ern plötzlich Windows NT auftauchte und die AS/400-Kunden in Scharen die Plattform wechselten, verharrte die IBM in Schockstarre oder verfiel in Panik (Zitat des damaligen IBM AS/400-Bereichsleiters (Österreich) bei einer Veranstaltung ".. bitte bitte bleiben sie der AS/400 treu ...", die Kunden wurden dann erst recht neugierig auf die Konkurrenz ...). Aber wirklich getan wurde nichts.
Ganz im Gegenteil, da kam man (immer wieder) auf die glorreiche Idee, den Namen zu ändern, und so gab's AS/400, e Server, i Series, System i5, IBM i (to be continued ..?), ebenso die lustigen Namen für das Betriebssystem, welches man aktuell mit einem Apfeltelefon verwechseln kann und nicht zu vergessen die wechselnden Namen für die Datenbank, da wusste Big Blue ja auch nicht so recht, wohin die Reise gehen sollte.
(So nebenbei übrigens interessant, dass eine uuuuuuralte, spaltenorientierte(!) Programmiersprache komplett auf Freeformat umgestellt wurde und es dafür aber immer noch den gleichen, alten Namen gibt. Hier war anscheinend kein neuer Name angesagt, obwohl das genau hier notwendig wäre. Mehrmals habe ich schon bei Kunden die Gespräche miterlebt "ja ich programmiere schon lange in RPG. Was ist das denn? Nein, das habe ich noch nie gesehen...).

Seit vielen Jahren nun sind Informationen für Kunden, was es im AS/400-Bereich Neues gibt, praktisch nicht vorhanden. Die Meisten wissen tatsächlich nicht, dass es dieses System noch gibt (und was es mittlerweile alles kann!). Kurse-/Ausbildung (zumindest hier in Österreich) nur mehr von Drittfirmen, deren Vortragende spätestens bei der zweiten Zwischenfrage einknicken.
Ja und nicht zu vergessen die Software, egal ob DKS, IBM Lohn (Loga+), oder so Dinge wie iCluster - die IBM trennt sich von allem, und damit auch von den Kunden und der damit einhergehenden Bindung.

Lange Rede kurzer Sinn - jemanden, der seine Dateien lieber mit DDS definiert, als maßgeblich schuldtragend an der AS/400 Ignoranz zu bezeichnen, ist aus meiner Sicht völliger Unsinn!

(bitte nicht böse sein oder persönlich nehmen, wollte hier nur mal meine Meinung zu diesem wichtigen Thema posten)

harkne
25-06-15, 07:54
Vielen Dank für die ausführliche Info.

Ich werde das mal bei uns im Haus weiter geben.


Natürlich!
Du kannst SQL Scripte entweder im IFS oder als Source Physiscal File Member ablegen.
Mit RUNSQLSTM kannst Du diese Scripte jederzeit wieder ausführen.

Wir legen die Erstellungsbefehle für Datenbankenobjekte (wie DDS) als Teildateien ab (auch alte Schule!). Ich habe z.B. bei uns im PDM den RUNSQLSTM-Befehl hinterlegt. Anstatt jetzt ein Datenbanken-Objekt mit 14 zu erstellen wird die Auswahl RS verwendet.

Wenn man im RUNSQLSTM in der Option DFTRDBCOL die Objekt-Bibliothek mitgibt, kann man sogar die Qualifizierung mit der Bibliothek in den Skripten weglassen. Über das gleiche Skript könnte somit das Objekt in unterschiedlichen Schemata/Bibliotheken (Test/Echt) erstellt werden.

Die andere Alternative ist, die Teildatei mit dem IBM i Navigator - Run an SQL Script/Eine SQL Prozedur ausführen öffnen und anschließend ausführen.

Die SQL Skritpe können aus dem Datenbanken-Objekt über den IBM i Navigator generiert und wahlweise im IFS oder als Teildatei gespeichert werden.

Mit einem der letzten Technology Refreshes wurde auch die Stored Procedure GENERATE_SQL in der Bibliothek QSYS2 bereitgestellt, über die die SQL Skripte ebenfalls generiert und wahlweise ins IFS oder als Teildatei abgelegt werden können.

Noch ein Tip: STRSQL ist genaus "stabilized" wie DDS.
Aktuell ist das Strategische Produkt der IBM der IBM i Navigator (Client Access und Teile sind auch in der Web-Version realisiert).
IBM Data Studio wäre u.U. eine Alternative.
Man sollte sich langsam mit diesen Tools anfreunden.


Birgitta

Robi
25-06-15, 09:17
Etwas 'unglücklich' ist die sql Version trotzdem.
mit DDS hab ich die Datei angelegt und, wenn Felder hinzu kamen, diese in die DDS eingefügt und ein CHGPF gemacht. Brauchte ich die Datei woanders konnte ich Sie mit CRTPF erstellen.

Mit SQL pflege ich entweder mehrere Sourcen
--> Create Table ...
und, für jede Änderung, ein "alter table" mit den neuen Felder sowie eine Anpassung im Create Table.
Wenn mir (und ich habe solche Kunden) die Reihenfolge der Felder nicht egal ist, muß ich wie zu Zeiten vor CHGPF die Datei mit Map und Drop hin und her kopieren.

und jetzt hoff ich, das Ihr schreibt das das alles nicht stimmt! Wir machen das nämlich (teilweise) so
und da war DDS erheblich komfortabler!

Robi
(der gerne SQL verwendet aber nicht glaubt das alles neue 'per Se' besser ist)

RobertMack
25-06-15, 09:26
(der gerne SQL verwendet aber nicht glaubt das alles neue 'per Se' besser ist)

Like = *On;

If AllSql = *On;
MaintCostPerLine = 'more expensive';
EndIf;

:cool:

B.Hauser
25-06-15, 09:43
Mit TR2 für Release 7.2 bzw. TR10 Release 7.1 wird der CREATE TABLE-Befehl auf CREATE OR REPLACE erweitert, mit dem u.a. Spalten dazwischen geschoben werden können, Spalten verändert oder hinzugefügt werden können.
Man braucht keine unterschiedlichen Quellen mehr, sondern kann ein und das selbe Skript modifizieren und erneut ausführen (funktioniert wie CHGPF! - Alter Table ist nicht mehr notwendig)
Klappt übrigens auch mit einem CREATE TABLE, der auf einen SELECT basiert. Damit kann auch das Problem von Feld-Referenz-Dateien einfach gelöst werden.

Birgitta

camouflage
25-06-15, 09:46
Like = *On;

If AllSql = *On;
MaintCostPerLine = 'more expensive';
EndIf;

:cool:

Nicht doch...

wenn schon, nimm "true" und "false". Wer wird denn noch mit Indikatoren... :rolleyes:

Fuerchau
25-06-15, 11:26
Wenn man schon mit SQL arbeitet, ist die Reihenfolge der Felder in der Tabelle vollkommen egal.
Es ist schon AS/400-spezifisch, beim Hinzufügen von Feldern die Tabelle neu zu erstellen.
Sicherlich passiert dies nun automatisch, aber ein CPYF (Intern) sowie der doppelte Platz ist immer noch nötig. Andere DB's hängen das Feld einfach hinten dran und gut ist.

Problematisch ist das Einfügen von Feldern für jedes Programm, dass mit "Select *" in eine DS einliest.
Angehängte Felder werden ignoriert, dazwischen geschobene Felder führen (außer wenn alles CHAR ist) zu Fehlern beim Fetch (aufgelöste Moves).
Wenn alles CHAR ist merkt das Programm im Zweifel nichts und arbeitet mit falschen Feldinhalten.

BenderD
25-06-15, 11:46
Problematisch ist das Einfügen von Feldern für jedes Programm, dass mit "Select *" in eine DS einliest.
Angehängte Felder werden ignoriert, dazwischen geschobene Felder führen (außer wenn alles CHAR ist) zu Fehlern beim Fetch (aufgelöste Moves).
Wenn alles CHAR ist merkt das Programm im Zweifel nichts und arbeitet mit falschen Feldinhalten.

... wieder einer der Mythen: sowohl * als auch die DS werden beim compile in Feldnamen aufgelöst, Murks passiert da nur bei der Änderung von Feldtypen oder Feldnamen (das machen nur Wahnsinnige). Nach Recompile passt auch wieder alles. Huddel kriegt man, wenn man select Feldliste in eine externe Datenstruktur fetched (wie manche empfehlen).

Allen Problemen geht man aus dem Weg, wenn man grundsätzlich select * in eine DS aus einer View macht und Views nie ändert (wie ich das empfehle und mache).

D*B