SQL-View auf /36-Datei

[GruberWolfgang]

Ich versuche eine SQL-View auf eine alte /36-Datei zu erstellen. Diese enthält natürlich alles, was eine /36-Datei so enthält:

• blanks in gepackten Felder
• blanks in gezonten Feldern
• ungültiges in eigentlich als numerisch geplante Spalten
• undefiniertes, von dem keiner mehr weiss
• Datumsangaben in allen Variationen und (Un-)-Gültigkeiten
• usw.

Der Basis-Select für die View funktioniert schon. Aber beim CREATE VIEW laufe ich auf Fehler SQL7008. Ich habe die Datei bereits unter Journalisierung genommen - SQL7008 kommt immer noch. Die Datei hat eine ungewöhnliche Besonderheit, da sie den Parameter ALWDLT auf *NO sitzen hat. Leider hat sie auch noch die CCSID 65535. Man hat da wohl (früher) mit relativen Satznummern gearbeitet. Ich brauche auch nur eine "readonly"-View. Ich habe versucht, durch eine "Dummy"-Join eine "Readonly"-View auszulösen, aber der SQL7008 kommt immer noch. Hat da jemand noch eine Idee, woran das liegen kann.
Auf die ursprünglichen Entwickler besteht kein Zugriff mehr und die bestehenden Programme traut sich kaum einer zu ändern. Das Alter der Programme liegt bei 40+ :-(

[Fuerchau]

Leider kann man auf programmbeschriebene Dateien keine SQL-View erstellen.
Schau dir im Joblog den Grund für SQL7008 an:
7 - Basistabelle ungültig ... ist programmbeschrieben.

Du hast also keine Chance per SQL mit dieser Tabelle zu arbeiten.

[B.Hauser]

Über eine View geht das nicht, aber eine (externe) UDTF (User Defined Table Function) sollte möglich sein.

Mit Native I/O kann die programmbeschreibene Datei problemlos in eine Datenstruktur gelesen und auch die falschen Werte ausgebessert werden.
Die Werte aus den korrigierten Datenstrukturen können dann ausgegeben werden.
Das Ganze ist allerdings ein bisschen tricky, da die UDTFs über das Call-Back-Processing Prinzip verarbeitet werden.

Nähere Informationen zu UDTFs sind hier:
The power of user-defined table functions

[BenderD]

... ich habe zwar Altlasten dieser Art seit gefühlt 100 Jahren verdrängt, aber...
ich würde mal versuchen die Datei durch eine "extern" beschriebene mit einem langen Alfafeld zu ersetzen (füllen mit cpyf *nochk) und gehe mal davon aus, dass der /36-Schinken das nicht merkt und das Teil Programm beschrieben verarbeitet, wie bisher. Und auf diese Table kann man dann eine View erstellen.

D*B

[GruberWolfgang]

Hallo,
vielen Dank für die Rückmeldung. Den Ursachencode 7 hatte ich schon gesehen, allein mir fällt kein Grund ein, warum man das verbieten muss. Ich wollte die Daten eigentlich primär analysieren und auswertbar machen, über die View auch noch zu schreiben wäre das Sahnehäubchen gewesen.(Die Performanceverluste hätte ich in Kauf genommen und der Select funkioniert ja auch wie gewünscht).
Aber wenn IBM meint, das verbieten zu müssen, dann werden die wohl schon ihre Gründe haben - wahrscheinlich Erziehung zu sauberen Tabellen :-).
Die Vorschläge von Bender/Hauser werde ich mir mal anschauen.

[GruberWolfgang]

Hallo Frau Hauser,

vielen Dank für ihren Tipp.

Die externe UDTF (consuming a program-described file) sollte mein Problem wohl lösen können. Leider bin ich des RPG kaum mächtig und brauche wohl etwas Zeit das so umzusetzen. (Ein Cobol-Beispiel wäre mir leichter gefallen :-)). Die programm-beschriebene Datei enthält leider viele numerische/gepackte Felder, die - wie nun mal bei /36-Programmen nicht unüblich - oftmals Blank enthalten(von tatsächlich falschen Inhalten mal ganz abgesehen). Die Lösung sollte auch wesentlich performanter sein, als mein komplexer SQL mit den vielen Datenprüfungen und Umsetzungen.

[GruberWolfgang]

Hallo Herr Bender,

vielen Dank für ihre Antwort.

das haben wir für einige Dateien schon gemacht und für diese Dateien auch eine "vernünftige" DDS angelegt. Mit dieser dann extern beschriebenen Datei sind wir (einigermaßen)SQL-fähig. Ein lästiges Problem bleiben dabei aber die "/36-blanks" in gezonten und gepackten Feldern. Schon ein ORDER BY auf so eine Spalte findet SQL dann verständlicherweise nicht mehr so gut.
Bei meinem Beispiel traue ich mich aber nicht so Recht, diese Datei so neu zu definieren, da sie von der Anwendung scheinbar(?) mit relativen Satznummern gelesen wird. Deshalb der verzweifelte Versuch, über eine programmbeschriebene Datei eine View zu legen. Ich hoffe, mit dem Vorschlag von Frau Hauser (exteren UDTF), weiter zu kommen.

[BenderD]

Hallo Herr Bender,

vielen Dank für ihre Antwort.

das haben wir für einige Dateien schon gemacht und für diese Dateien auch eine "vernünftige" DDS angelegt. Mit dieser dann extern beschriebenen Datei sind wir (einigermaßen)SQL-fähig. Ein lästiges Problem bleiben dabei aber die "/36-blanks" in gezonten und gepackten Feldern. Schon ein ORDER BY auf so eine Spalte findet SQL dann verständlicherweise nicht mehr so gut.
Bei meinem Beispiel traue ich mich aber nicht so Recht, diese Datei so neu zu definieren, da sie von der Anwendung scheinbar(?) mit relativen Satznummern gelesen wird. Deshalb der verzweifelte Versuch, über eine programmbeschriebene Datei eine View zu legen. Ich hoffe, mit dem Vorschlag von Frau Hauser (exteren UDTF), weiter zu kommen.

... die relativen Satznummern sind sicher kein Problem, die ändern sich ja nicht, wenn man die copy Arie sensibel vornimmt. Bei den Feldern mit dubiosen Inhalten bleibt wohl kaum was anderes, als diese als binary zu betrachten und dann aufzubereiten.
Plan B wäre für mich über Trigger oder Journal eine konsolidierte Parallelsicht aufzubauen, das wäre bei mehrfach Zugriffen auch wesentlich permanenter als eine UDF, die ja letztlich die Daten immer wieder neu aufbereitet.

D*B

[GruberWolfgang]

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.

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