SQL-View auf /36-Datei

[BenderD]

Hallo Herr Bender,

beruhigend, wenn man beim gleichen Problem auf die gleichen Lösungen kommt.
Ihren Plan B haben wir vor einiger Zeit schon für einige wichtige Dateien - mit denen wir mit neuen Web-Anwendungen weiter arbeiten sollten/wollten - vollzogen, da ich mich nicht mit den /36-Strukturen rumschlagen wollte - das funktioniert übrigens reibungslos, sicher und absolut synchron, auch wenn ich ansonsten Redundanz gar nicht mag. Aber für 100+ alte Dateien jeweils einen Trigger zu schreiben und den /36-Inhalt anlaysieren, mag der Kunde gar nicht bezahlen :-(.
Der Kunde (und wir auch) will nur auch andere alte Dateien einigermaßen mit SQL auswerten, deshalb der Versuch mit der View.
Was die relativen Satznummern betrifft stimme ich Ihnen schon zu; ich musste aber schon des öfteren ein paar Überraschungen erleben, die mich da vorsichtig machen.

... naja, die Altlasten Billiglösung heißt da IDDU, die Trigger sollten aber durchaus generierbar sein, wenn da COBOL Copy Books vorhanden sind...

D*B

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

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