Berechtigung QSYS View ermöglichen

[Gutmann]

Hallo Holger, danke für die Antwort.
Es war angedacht, dass wir für eine Liste von Benutzern die wir Beispielsweise in unserer eigenen Menüverwaltung haben zusätzliche Systemwerte anzeigen, wie z.B. Letzte Logindatum.
Kannst du zu 1) nochmal genauer schildern, was du damit meinst?
Den

DSPFD QSYS2/USER_INFO habe ich ausgeführt - auf welche Zahl soll ich achten?

Kann zu Fragen 4-6 noch jemand eine Hilfe abgeben?

[Fuerchau]

Wie Holger schreibt, viele neue SQL-Funktionen sind i.W. nur wegen des iSeries Navigator entstanden, da Java eben nicht so einfach auf API's zugreifen kann.
Daher sind diese SQL-Funktionen eben Wrapper auf API's.
Und wenn du dir die API's ansiehst, dann kannst du verstehen, warum das so lange dauert.
Des weiteren liefern die Table-Function i.d.R. eben alles was du dann per Where-Klausel wieder ausfilterst.
Dabei haben die API's häufig eigene Filterkriterien.

Wenn du eine eigene Table-Function schreibst, dann sorge doch dafür dass du optionale Parameter bereits als Filterkriterium übergeben kannst!
Damit sparst du dir auch hier bereits den vollen Aufbau um anschließend wieder nicht gewünschtes auszufiltern.

Bei der Declaration von UDF's und UDP's müssen die Ein-/Ausgabeparameter gezielt deklariert werden, dadu ja im SQL-Body oder dem externen Programm ja noch diverse Änderungen an den Werten und somit auch den Typen vornehmen kannst.
Bei der Übergabe passieren dann wieder Autocasts.

Ich glaube nicht, dass MQT's auch auf Table-Functions funktionieren, ggf. weiß Birgitta da weiter.
I.d.R. machen MQT's an Hand bestimmter Kriterien ihre Updates, was bei UDTF's ja nicht klappen kann.

Was deinen Fehler angeht, so starte den Debugger und schaue die Fehlermeldungen dazu an.
Das kann an Parameterfehlern liegen als auch an falscher Interpretation der Aufgabenstellung.

[holgerscherer]

Hallo Holger, danke für die Antwort.
Es war angedacht, dass wir für eine Liste von Benutzern die wir Beispielsweise in unserer eigenen Menüverwaltung haben zusätzliche Systemwerte anzeigen, wie z.B. Letzte Logindatum.
Kannst du zu 1) nochmal genauer schildern, was du damit meinst?
Den

DSPFD QSYS2/USER_INFO habe ich ausgeführt - auf welche Zahl soll ich achten?

Kann zu Fragen 4-6 noch jemand eine Hilfe abgeben?

Also keine Systemwerte anzeigen, sondern Attribute eines Userprofils, dafür gibts das CL Command RTVUSRPRF (auch via SQL aufrufbar). Das könnte flotter sein, als eben die USER_INFO abzufragen. Im DSPFD nicht auf eine Zahl achten, sondern runter blättern und das SQL anschauen und auswendig lernen - das muss nämlich jedes Mal ausgeführt werden ;-)

Fragen 4-6 dürften sich erledigen (falls nicht generell gemeint), wenn Du den einfachen Weg über die altmodische Variante (siehe oben) gehst.

Ach ja - arbeitet Ihr mit GreenScreen und RPG/CL oder mit einer PC-basierten Anwendung, die per ODBC/JDBC/SQL zugreift?

-h

[Gutmann]

dafür gibts das CL Command RTVUSRPRF (auch via SQL aufrufbar). Das könnte flotter sein, als eben die USER_INFO abzufragen.

Ach ja - arbeitet Ihr mit GreenScreen und RPG/CL oder mit einer PC-basierten Anwendung, die per ODBC/JDBC/SQL zugreift?

-h

Danke für die Antworten. Dann bleiben noch zwei Fragen.

Die UDF besteht ja nur aus einem SELECT * FROM - was soll ich da debuggen?

Holger, wie führst du das denn über SQL aus?

Das entscheidende ist halt, ich habe eine Liste von Usern und muss dazu die korrespondierenden Infos des Benutzerprofils dazu mappen. Ein Parameter für die Funktion kann ich also nicht vornehmen. Die Infos wenn wirklich in einer Tabelle wären die einfach gejoined werden kann wäre schon hübsch.

Wir arbeiten sowohl als auch mit ODBC aber auch nativ auf der i mit RPG/CL.

Wäre die QSYRUSRI wie hier eine Option?
https://www.ibm.com/support/pages/ex...g-qsyrusri-api
Ich müsste halt dann N-mal pro Userprofil das ich anzeigen will die Infos dazu lesen.

[Fuerchau]

Mach mal einen DSPFD der View für die UserInfo.
Dort kannst du dir den SQL genau ansehen.
U.U. wird in from "table(getirgendwas(p1, p2))" gelesen, da durchaus 2 API's eine Rolle spielen können.
Ein List-API für USRPRF-Objekte und ein USRINFO-API je User.
Somit könntest du die Inner-Function ganz genauso aufrufen.
Ich kann das i.M. nicht online verifizieren, aber es aber bei anderen Systemviews genau so gesehen.

[Gutmann]

Hallo Herr Fürchau, a

lso das CREATE bzw. das FROM sieht wie folgt aus:

SELECT * FROM TABLE (QSYS2.OBJECT_STATISTICS('QSYS      ','USRPRF ',NULL)) a, lateral (SELECT * FROM TABLE (QSYS2.QSYUSRINFO(a.OBJNAME)) as x) as b;

Wenn ich das so ausführe braucht es immerhin nur 500 ms.
Die Objectstatistics allein bringt mir nichts, die qsyusrinfo aber auch nicht, da hier der User fehlt. Da es ja nicht nur um den einen geht, muss ich sie eben joinen über den LATERAL SELECT wie oben zu sehen.
Den Befehl DSPFD kannte ich so gar nicht, ich bin immer über SCHEMATA u. SQL generieren gegangen
Wenn ich nun aber eine View anstelle der UDF mache, wie kriege ich das dann mit den Rechten hin?

[Fuerchau]

"QSYS2.OBJECT_STATISTICS('QSYS ','USRPRF ',NULL)"

Die Funktion nimmt 3 Parameter:
1. Lib
2. ObjType
3. wahrscheinlich OBJNAME, wobei NULL dem *ALL entspricht.

Wahrscheinlich kann man das auch für andere Objekttypen verwenden.

"QSYS2.QSYUSRINFO(a.OBJNAME)"

Damit hast du doch genau die Funktion, die du eigentlich willst:
Parameter dürfte der Username sein, was durch den Join vom 1. API ermittelt wird.

SELECT * FROM TABLE (QSYS2.QSYUSRINFO("MEIER"))

sollte also genau von enem User die Info bringen.

[BenderD]

Hallo Holger, danke für die Antwort.
Es war angedacht, dass wir für eine Liste von Benutzern die wir Beispielsweise in unserer eigenen Menüverwaltung haben zusätzliche Systemwerte anzeigen, wie z.B. Letzte Logindatum.
Kannst du zu 1) nochmal genauer schildern, was du damit meinst?
Den

DSPFD QSYS2/USER_INFO habe ich ausgeführt - auf welche Zahl soll ich achten?

Kann zu Fragen 4-6 noch jemand eine Hilfe abgeben?

Table Functions sind Murks, wenn anschließend ein Index für effektiven Zugriff benötigt würde. Beispielsweise bei ORDER BY, WHERE, JOIN - also fast immer. Dann geht nämlich die Verarbeitungszeit hoch und die Aktualität der Daten runter. Mit MQTs kann man die Zugriffszeit zu Lasten der Aktualität verbessern, das ist die Datenbank Variante zu eurer Snapshot Lösung. Murks * Murks (Table Function auf Table Function) hebt sich nicht weg, sondern potenziert sich.

Einzelne virtuelle Felder implementiert man besser als SQL Functions, die man auch in Views verwenden kann. Durch intelligentes caching kann man auch mehrere Attribute auf einmal holen und einzeln in Functions liefern.

In eurem skizzierten Fall handelt es sich um Daten, die sich selten ändern. Da ist das sauberste einen Startbestand zu erzeugen (den habt ihr ja bereits) und dann die Änderungs Events automatisch einzupflegen. Die Änderungsevents kriegt man hier über das Audit Journal mit RCVJRNE. Mit dieser Strategie kriegt man auch die Security Probleme einfach und sauber gelöst.

D*B

[Fuerchau]

So, ich konnte dies nun mal verifizieren:

SELECT * FROM TABLE (QSYS2.QSYUSRINFO('BFUERCHAU'))

kommt zum gewünschten Ergebnis. Etwas Mühe macht dann noch die Spaltenüberschrift, aber die steht a in SYSPARMS.
SELECT * FROM sysparms WHERE SPECIFIC_NAME = 'QSYUSRINFO' and
SPECIFIC_SCHEMA = 'QSYS2'

Dasselbe gilt auch für die Object-Function:
SELECT * FROM TABLE (QSYS2.OBJECT_STATISTICS('QSYS ','USRPRF', 'BFUERCHAU'))

Man kann hier alle Objektarten und Namen verwenden und es ist auch sauschnell.