Berechtigung QSYS View ermöglichen

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