OPNQRYF im RPG-Programm durch SQL ersetzen

[dschroeder]

Hallo,
ich habe hier ein älteres RPGLE-Programm, mit dem Daten gesucht und in einer programmgesteuerten Subfile angezeigt werden. Die Arbeitsweise des Programms ist so, dass eine logische Datei mit klassischen RPG-Zugriffen (CHAIN, READ, SETLL, ...) verarbeitet wird. Die logische Datei wird vor der Programmausführung jedoch mittels OVRDBF von einem OPNQRYF überschrieben, so dass die Logische nur noch die gewünschten Daten enthält. Funktioniert auch alles. Aber OPNQRYF verwendet die klassische SQL Engine und wirkt sich relativ ungünstig auf die Performance unserer Anlage aus. Deshalb wäre es schön, wenn wir das so umbiegen könnten, dass die aktuelle SQL-Engine SQE verwendet wird. Wir wollen das Programm im Moment aber nicht neu schreiben und nicht stark anpassen. Deshalb die Frage: Gibt es einen Weg, die OPNQRYF-Geschichte durch SQL zu ersetzen? Also z.B. so etwas wie eine View zu erstellen, die exakt der logischen Datei entspricht, so dass RPG diese View verarbeiten kann? Da eine View keine Sortierung beinhaltet, weiß ich allerdings nicht, wie das gehen soll. Vielleicht gibt es ja noch andere Möglichkeiten. Eine temporäre Tabelle, die genau wie die logische aufgebaut ist und alle selektierten Daten enthält, ist wahrscheinlich zu unperformant.

Also, falls jemand eine Idee hat, bitte melden.

Dieter

[B.Hauser]

Hallo Dieter,

mit einer View wirst Du da wenig Chancen haben. Zwar kann die View mit Sicherheit alle gewünschten Datensätze enthalten, aber eine View ist immer ungeschlüsselt und die Reihenfolge der ausgegebenen Datensätze hängt von den Zugriffswegen ab, die der Optiomizer wählt. Die gewünschte Reihenfolge kann immer nur drurch einen zusätzlichen ORDER BY im endgültigen SELECT-Statement (außerhalb der View) gewährleistet werden.

So wie ich das sehe musst Du entweder das Programm auf embedded SQL ändern, oder das Ergebnis der OPNQRYF in eine (temporäre) physische Datei mit entsprechendem Index oder Key Constraints ausgeben und diese Datei verarbeiten.

Birgitta

[dschroeder]

Vielen Dank Birgitta.
Ich habe mir das schon gedacht. Aber es hilft mir sehr weiter, bestätigt zu kommen, dass es wirklich so ist. Auf Dauer werden wir das Programm sicherlich neu schreiben und dann mit embedded SQL arbeiten.
Dieter

[Pikachu]

Vielleicht fehlt einfach ein geeigneter Zugriffspfad. Habt ihr mal die SQL-Hinweise angesehen, die im Debug-Modus nach STRDBG UPDPROD(*YES) erzeugt werden?

[dschroeder]

Wir hatten einen Fachmann im Haus, der Performanceanalysen gemacht hat und einige Einstellungen gemacht hat. Wir machen sehr viele SQL Zugriffe. Nur ganz ganz wenige davon benutzen die klassische SQL Engine. Wir möchten das System einfach sauber haben und nur noch die SQE benutzen. Die Performance des Programms selber ist gar nicht das Problem. Das Problem ist, dass sehr oft ein (temporärer) Index erzeugt wird. Das möchten wir gerne beseitigen. Ich habe als erste Maßnahme schon mal die Optimierung für das OPNQRYF auf *FIRSTIO gestellt. Das hat schon etwas gebracht.

Zu deiner Anmerkung: Das Log sagt nicht, dass Zugriffspfade fehlen. Da wir eine Like-Abrage machen (suche alle Kunden, in deren Namensfelder "meier" vorkommt), kann das System wahrscheinlich keinen permanenten Pfad vorhalten.

Danke für den Hinweis.

Dieter

[Fuerchau]

Für einen Like wird auch kein temporärer Pfad erstellt.
Ggf. sind ja noch weitere Felder im Where bzw. Order By, für die kein Index vorhanden ist.
Prüfe den Zugriff mal als SQL und schau dir dann die Diagnose bzgl. Indizes an, manchmal hilft das auch für die CQE.

[dschroeder]

Gute Idee. Ich versuche das mal.
Danke.

[TheDevil]

Hallo.
So wie ich das verstanden habe schreibt euer OPNQRYF das Ergebniss in eine PF Datei. Diese besitzt dann eine oder mehrere logische Files. Wenn dann der Parameter FRCRATIO für die physische Datei auf 1 stehen sollte wird dies quälend langsam von statten gehen, vor allem bei grossen Datenmengen.
Guck doch da mal nach ...
Gruß,
Ralf

[dschroeder]

Nein. Das Ergebnis des OPNQRYF wird direkt verarbeitet. Es wird keine physische Datei geschrieben. Das einzige Problem, das wir haben, ist, dass OPNQRYF anscheinend die CQE benutzt. Wir würden aber gerne alles einheitlich über die SQE laufen lassen.
Dieter

[Fuerchau]

Wenn das Ergebnis des OPNQRYF nur sequentiell bearbeitet wird, hilft dir ggf. auch folgender Trick (mache ich im Moment bei einem Kunden mit V5R2:

create table qtemp/xxmytable as (
select ...
where ...
order by ...) with data
ovrdbf myfile qtemp/xxmytable

Ggf. die Ergebnismenge mit "fetch first nn rows" einschränken, da der User im Zweifel sowieso nicht alles ansieht.
Alternativ kann man auch einen QM-Query mit Parametern schreiben und diesen dann per "STRQMQRY ... OUTPUT(*OUTFILE) ... " laufen lassen.

Ist die Tabellenstruktur dann identisch kann man im OVRDBF noch den LVLCHEK rausnehmen.
Ggf. reicht auch nur die Umwandlung des Programmes mit Bezug auf die neue Datei.

Möglichkeiten gibts da viele.

[dschroeder]

Nochmals danke für die Tipps.
Dieter

[Pikachu]

Aber OPNQRYF verwendet die klassische SQL Engine ...

Anscheinend nicht mehr ab V7R2, wenn ich dieses Dokument richtig verstehen:

"Improved SQL Query Engine (SQE) capabilities. The progression of expanding the interfaces supported by SQE continues with IBM i 7.2. By default, SQE will be used to implement Native DB queries, including those made via traditional interfaces Open Query File (OPNQRYF) and Query/400. Just by moving to IBM i 7.2, these Native DB queries will be easier to observe and manage through the extensive database tooling found in the IBM i Navigator OnDemand Performance Center . Heavy Native DB queries could reap a performance benefit from an implementation through a far more advanced query engine."

Im IBM i Memorandum für Benutzer Version 7.2 steht natürlich auch etwas darüber drin.