SQL-View auf /36-Datei

[hel400]

Möglicherweise verstehe ich das eigentliche Problem noch nicht so ganz -
aber warum nicht einfach eine LF (per DDS) direkt auf die QS36F-Datei machen?
Diese hat ja trotzdem ein Feld (bzw. bei definiertem Key mehrere) und diese Felder kann man ja direkt in der LF mit "SST" in die gewünschten Einzelfelder zerlegen.
Somit bliebe die Originaldatei unangetastet und für SQL gibt's die LF.

[GruberWolfgang]

Hallo hel400,

die Idee ist prinzipiell OK und praktizieren wir auch. Das ganze scheitert aber dann, wenn - wie bei /36-Umgebung nicht unüblich - in an sich gezonten/gepackten Feldern Blanks enthalten sind. Eine konditionierte DDS-Beschreibung kriegen Sie meines Wissens nach mit DDS nicht hin. Das würde aber in SQL gehen (mit entsprechendem Definitonsaufwand, ggf. mit einer UDF unterstützt). Ein entsprechender SQL funktioniert auch wie gewünscht. Soll aber mit diesem SQL eine View angelegt werden, weigert sich die AS/400 mit dem SQL7008, Ursachencode 3(View auf programmbeschriebene Datei nicht möglich). Warum IBM das verbietet, kann ich auch nicht ganz nachvollziehen. Natürlich kann man die programmbeschreibene Datei in eine DDS-beschriebene Datei umkopieren - wie von Bender auch vorgeschlagen -, das ändert aber noch nichts an den problematischen zoned/packed-Feldern. Auch der von Bender vorgeschlagenen PlanB, über ein Trigger-Programm eine korrekte Schattendatei aufzubauen ist eine gute Lösung - aber halt mit Aufwand verbunden. Diese Trigger automatsich zu generieren ist aber in unserem Fall nicht wirklich möglich, da es sich um RPG/36-Programme($MAS aus den 70er Jahren) handelt und keine Cobol-Copy-Books vorliegen.

[B.Hauser]

Ich hab's nicht versucht, und mache Dir auch keine großen Hoffnungen, aber ein Versuch wär's zumindest wert:

1. Einen Alias auf die programmbeschriebene Datei erstellen
2. Eine View auf den Alias generieren.

Birgitta

[Fuerchau]

Eine View auf Alias ging noch nie. Ein Alias ist eine DDMF!

[BenderD]

... da geht es ja wieder kunterbunt durcheinander:
- ein Alias ist kein DDMF.
- ein DDNF ist ein Alias.
- ein create view geht immer auf die Tabelle runter.
- eine view auf eine nicht extern beschriebene Datei geht nicht.
- was sehr wohl mit äüßerst sparsamem Aufwand geht:
-- die Datei über Trigger in eine Datei mit einem Feld zu spiegeln
-- diese Trigger sind auch ohne Copy Books generierbar
-- auf diesen "Schatten" kann man views erstellen, wie man will

D*B

[GruberWolfgang]

Hallo Frau Hauser,

die Hoffnung stirbt ja immer zuletzt :-)

Das Ergebnis meines Test:
Create Alias funktioniert.
Select auf den Alias funktioniert auch mit allen komplexen Cases und Datenprüfungen
CreateView auf den ALias bringt leider auch weider den SQL7008.

Ich kann mit dem aktuellen Stand schon leben , aber..
...der Grund, warum IBM den CreateView auf die programmbeschriebene Datei verbietet würde mich allerdings schon interessieren. Haben Sie nicht Kontakte ins Labor?

@Fuerchau:
Ein CREATE VIEW auf einen ALIAS funktioniert schon, wenn der ALIAS sich auf eine Table bezieht. Das Problem scheint tatsächlich die zugrundeliegenden Basistabelle/Basisdatei zu sein.

[GruberWolfgang]

Hallo Herr Bender,


Sie haben mit allem Recht.
Die Generierbarkeit der Trigger ist sicher auch ein denkbares Thema. Da aber die zugrundeliegenden Dateien viele zoned/packed mit /36-blanks enthält erfordert dies doch eine hohe manuelle Nacharbeit und Prüfung auf "Bit-Ebene" und wo was stehen soll muss man ja dazu nun mal wissen, d.h. die programmbeschriebenen Struktur müsste man dann irgendwie analysieren.

[DKSPROFI]

Moin,

als mehr oder weniger "alter" MAS/34 und /36 Hase kann vielleicht geholfen werden. Es gibt eine Datei KONTRL. In dieser Datei stehen die Satzbeschreibungen der MAS Dateien drin, mit Feldnamen, Längen und weiteren Attributen. Wir haben 1997 einige MAS Dateien zu DDS konvertiert, da im Programm FA02 der Kunde einen Sonderwunsch haben wollte, der nur mit einem Externen RPG/400 Programm zu lösen war.

mfg

DKSPROFI