View Full Version : Logische Datei
Hallo zusammen,
ich habe folgende Ausgangssituation...
- ich muss 20 PF-Datei aus der S/36-Umgebung
verarbeiten, als wären sie eine :(
- ich habe eine LF erstellt, mit...
PFILE(DATEIA
DATEIB -
DATEIC)
- alle 20 PF's haben 2 Felder, K00001 und F00001, die
Länge und der Aufbau sind identisch !
- in dem 2.Feld F00001 sind u.a. auch gepackte oder binäre
Daten
Nun zu meinen Fragen...
Frage 1
- kann ich die gepackten bzw. binären Inhalte auch mit...
SST(F00001 5 4) (Beispiel)
definieren ?
Frage 2
Im RPG kann ich beim READ aus einer solchen LF auslesen,
aus welcher PF der Datensatz kommt (...über die INFDS,
glaube ich zumindest mal gelesen zu haben)
- gibt es irgendeine Möglichkeit, das auch mit SQL
zu tun ???
- ich muss für jeden mit SQL gelesenen Satz aus der LF
erkennen können, aus welcher PF-Datei dieser Satz kommt !
Vielen Dank für eure Unterstützung im Voraus ! :rolleyes:
Peet
M.E. hat SQL überhaupt Probleme eine solche logische Datei zu verarbeiten und liest nur die Daten aus der ersten Datei.
Eine Möglichkeit wäre, anstatt der LF eine SQL View zu basteln, in der alle 20 Dateien über UNION-Anweisungen zusammengemischt werden. Der Datei-Name kann als separate Spalte mit übernommen werden. Das Problem mit SQL-Views ist allerdings den Datensatz in Spalten aufzudröseln, insbesondere wenn gepackte numerische Werte enthalten sind. Machbar aber ...
Eine weitere Möglichkeit wäre eine externe UDTF (User Defined Table Function) zu erstellen, d.h. die Daten werden mit RPG und über die neu generiere logische Datei verarbeitet. (An dieser Stelle kann auch der Datei-Name ermittelt und ausgegeben werden).
UDTFs werden in der FROM-Anweisung eines SQL-Statements in Verbindung mit der TABLE-Anweisung hinterlegt und können wie jede andere physische Datei oder View verarbeitet werden.
In folgendem Artikel ist ein Beispiel für eine UDTF, in der mit RPG eine intern beschriebene Datei gelesen wird enthalten.
The Power of User-Defined Table Functions (http://www.ibm.com/developerworks/ibmi/library/i-power-of-udtf/)
Birgitta
Hallo Birgitta !
M.E. hat SQL überhaupt Probleme eine solche logische Datei zu verarbeiten und liest nur die Daten aus der ersten Datei.
..Grundsätzlich scheint das zu funktionieren, ein erster Test der Daten hat kein Anlass zur Sorge gegeben :)
Eine Möglichkeit wäre, anstatt der LF eine SQL View zu basteln, in der alle 20 Dateien über UNION-Anweisungen zusammengemischt werden. Der Datei-Name kann als separate Spalte mit übernommen werden. Das Problem mit SQL-Views ist allerdings den Datensatz in Spalten aufzudröseln, insbesondere wenn gepackte numerische Werte enthalten sind. Machbar aber ...
...das denke ich mir, das es recht "kompliziert" wird :eek:
Eine weitere Möglichkeit wäre eine externe UDTF (User Defined Table Function) zu erstellen, d.h. die Daten werden mit RPG und über die neu generiere logische Datei verarbeitet. (An dieser Stelle kann auch der Datei-Name ermittelt und ausgegeben werden).
UDTFs werden in der FROM-Anweisung eines SQL-Statements in Verbindung mit der TABLE-Anweisung hinterlegt und können wie jede andere physische Datei oder View verarbeitet werden.
In folgendem Artikel ist ein Beispiel für eine UDTF, in der mit RPG eine intern beschriebene Datei gelesen wird enthalten.
The Power of User-Defined Table Functions (http://www.ibm.com/developerworks/ibmi/library/i-power-of-udtf/)
..das schaue ich mir an, bisher habe ich mich immer davor gescheut, weil man sich erst einmal "einarbeiten" muss, aber
von "nichts" kommt "nichts" :rolleyes:
Birgitta
Vielen Dank Birgitta !
Peet
Mit SQL würde ich tatsächlich die Finger von lassen.
Da die Strukturen ja intern defniert sind, ist eine Strukturierung mit SQL eher sinnlos.
Ich würde die Dateien einzeln (mit UserOpn und Programmvariable für Dateinamen) durcharbeiten.
In der Zeit, in der du über SQL nachdenkst, hast du das Problem "klassisch" längst gelöst.
Wenn du unbedingt SQL nehemn willst, kannst du nur eine Union-View erstellen:
select 'FILEA', a.f1, a.f2 from Filea a
union all
select 'FILEB', a.f1, a.f2 from Fileb a
:
Möchstest du es strukturieren geht dass dann per "substr(a.f2, Pos, Len)".
Gepackte Dezimaldaten kannst du dann nur per
"dec(substr(hex(substr(a.f2, Pos, Len)), 1, len*2-1), n, m)" umwandeln, wobei du das Vorzeichen noch separat auswerten musst.
Vielen Dank für die Infos ! :)
Mit SQL würde ich tatsächlich die Finger von lassen.
Da die Strukturen ja intern defniert sind, ist eine Strukturierung mit SQL eher sinnlos.
Ich würde die Dateien einzeln (mit UserOpn und Programmvariable für Dateinamen) durcharbeiten.
In der Zeit, in der du über SQL nachdenkst, hast du das Problem "klassisch" längst gelöst.
Wenn du unbedingt SQL nehemn willst, kannst du nur eine Union-View erstellen:
select 'FILEA', a.f1, a.f2 from Filea a
union all
select 'FILEB', a.f1, a.f2 from Fileb a
:
Möchstest du es strukturieren geht dass dann per "substr(a.f2, Pos, Len)".
Gepackte Dezimaldaten kannst du dann nur per
"dec(substr(hex(substr(a.f2, Pos, Len)), 1, len*2-1), n, m)" umwandeln, wobei du das Vorzeichen noch separat auswerten musst.