View Full Version : SQL-View auf /36-Datei
GruberWolfgang
01-09-15, 13:13
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+ :-(
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.
Ü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 (http://www.ibm.com/developerworks/ibmi/library/i-power-of-udtf/index.html)
... 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
01-09-15, 16:32
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
01-09-15, 19:53
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
01-09-15, 20:04
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.
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
01-09-15, 21:35
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.
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