andere Berechtigung in SQL-Unterprogramm?

[rebe]

Hallo,

ich habe ein SQLCBLLE-Programm, das einen SELECT-Befehl auf eine Datei macht, auf die nur wenige Benutzer Berechtigung haben.
Was muß ich tun, damit dieses Unterprogramm Berechtigung auf diese Datei hat? Ich dachte beim Umwandeln (CRTSQLCBLI) gebe ich bei Benutzerprofil USRPRF *OWNER an und dann geht's. Leider nicht. Muß ich innerhalb des Programms einen neuen CONNECT machen mit einem Benutzerprofil das Berechtigung auf die Datei hat? Wenn ein Parameter beim Umwandeln dafür zuständig ist, würde ich lieber das machen.

Danke für Tipps.

Grüße
Reiner

[Fuerchau]

Probiers mit
/exec sql set option usrprf=*owner
/end-exec

[rebe]

Probiers mit
/exec sql set option usrprf=*owner
/end-exec

Danke für den Beitrag.
Das sollte ja eigentlich das gleiche sein wie USRPRF(*OWNER) beim Umwandeln. Es kommt immer noch die Fehlermeldung "keine Berechtigung" SQL0551.

Reiner

[BenderD]

Hallo,

die Problem beschreibung ist ein wenig zu allgemein gehalten:
bei dynamischem SQL muss zusätzlich DYUSRPRF auf Owner gestellt werden (beim Compile, oder set option, was ebenfalls zur Compiletime wirkt.
Bei remote Zugriff wird als Owner immer der Owner des Packages gezogen, was beim deployment zu Problemen führen kann, da gehören die Packages zuweilen dem QUSER.

mfg

Dieter Bender

Hallo,

ich habe ein SQLCBLLE-Programm, das einen SELECT-Befehl auf eine Datei macht, auf die nur wenige Benutzer Berechtigung haben.
Was muß ich tun, damit dieses Unterprogramm Berechtigung auf diese Datei hat? Ich dachte beim Umwandeln (CRTSQLCBLI) gebe ich bei Benutzerprofil USRPRF *OWNER an und dann geht's. Leider nicht. Muß ich innerhalb des Programms einen neuen CONNECT machen mit einem Benutzerprofil das Berechtigung auf die Datei hat? Wenn ein Parameter beim Umwandeln dafür zuständig ist, würde ich lieber das machen.

Danke für Tipps.

Grüße
Reiner

[rebe]

Hallo Dieter,

es ist kein dynamisches SQL und auch kein Remote-Zugriff.

Es geht darum, daß ein Unterprogramm Zeiten von Mitarbeitern ermitteln soll. Dieses Unterprogramm benutzt SQL-Befehle (select). Der User, der das Hauptprogramm aufruft, hat keine Berechtigung auf diese Stundendatei. Damit das Unterprogramm aber die Stunden holen kann, muß es mit einem anderen Benutzerprofil auf die Daten zugreifen. Das versuche ich zu programmieren.

Alles klar soweit?

Reiner

[BenderD]

Hallo,

genau für diesen Fall gibt es ja diesen Compile Parameter und der funzt bei mir eigentlich immer, es muss da also eine spezielle Konstellation vorliegen. Was meint hier eigentlich Unterprogramm? Sind da noch SQL Programme drüber? Hast du mal alle SQL Programme im Call stack mit Owner umgewandelt? Oder ist das ILE und hast du dem "Unterprogramm" mal eine eigene Activationgroup verpasst? Gibt es weitere Meldungen im Joblog? Hast du das ganze mal unter Debug gemacht, um sicher zu gehen, dass der Fehler auch an dieser Stelle auftritt?

mfg

Dieter Bender

Hallo Dieter,

es ist kein dynamisches SQL und auch kein Remote-Zugriff.

Es geht darum, daß ein Unterprogramm Zeiten von Mitarbeitern ermitteln soll. Dieses Unterprogramm benutzt SQL-Befehle (select). Der User, der das Hauptprogramm aufruft, hat keine Berechtigung auf diese Stundendatei. Damit das Unterprogramm aber die Stunden holen kann, muß es mit einem anderen Benutzerprofil auf die Daten zugreifen. Das versuche ich zu programmieren.

Alles klar soweit?

Reiner

[Fuerchau]

Ein solches Unterprogramm muss sowohl mit *OWNER im Programm als auch per USRPRF=*OWNER im SQL erstellt werden.
Wenn es innerhalb einer bestehenden SQL-Session aufgerufen wird, erfolgt keine neue SQL-Anmeldung (intern wird automatisch connected) sondern die aktuelle Sitzung verwendet.
Es ist also auf jeden Fall eine eigene Aktivierungsgruppe erforderlich um nicht in bestehende SQL-Sessions hineinzugeraten.

[rebe]

Das Problem ist gelöst, bzw. umgangen.
Danke für alle Beiträge.

Zuerst habe ich das Programm in ILE COBOL geschrieben. Bin halt in RPG noch nicht so fit. Dann habe ich das Programm spaßeshalber mal in RPG geschrieben und siehe da, es funktioniert sofort. Sch... COBOL!
Wahrscheinlich geht es in COBOL auch, aber habe keine Lust da jetzt weiter rumzuhexen.

Grüße
Reiner

[rebe]

Hallo,

das Problem ist doch nicht gelöst. Ich habe da eine Kleinigkeit übersehen. Zwischendurch habe ich zum Test dem User mal die Berechtigung *USE für die Datei gegeben und vergessen, das wieder rauszunehmen, dann ist klar, daß es geht.

Nehmen wir mal die RPG-Version. Damit beschäftigen sich wohl mehr hier. Zum Testen rufe ich das Programm einfach per Call auf, nicht aus einem übergeordneten Programm.

Im Programm habe ich DFTACTGRP(*NO) ACTGRP(*NEW) gesetzt. Zusätzlich noch "set option usrprf = *owner".
Berechtigung auf die Datei ist PUBLIC *EXCLUDE. Ich als Umwandler des Programms habe *ALL.
Beim Ausführen des Programms mit einem dummen User bekomme ich ein CPF4269 (Keine Berechtigung für Objekt ...).
Hat jemand eine Idee was ich probieren kann?

Danke für eure Unterstützung schon mal.

Grüße
Reiner

[Fuerchau]

Und das Programm selber läuft auch unter *OWNER ?

[rebe]

Ach ja, der Teil war mir noch unklar.
Ich habe das Programm (CRTSQLRPGI) mit USRPRF(*OWNER) umgewandelt. Wenn ich dsppgm mache, dann steht unter Benutzerprofil immer *USER. Ich habe das Programm immer neuumgewandelt, aber nie gelöscht!!

Jetzt habe ich gerade spaßeshalber mal in die Hilfe zum Befehl CRTBNDRPG geschaut und da steht in der Hilfe zum Parameter Benutzerprofil "Dieser Parameter wird nicht aktualisiert, wenn das Programm bereits vorhanden ist. Um den Wert für USRPRF zu ändern, das Programm löschen und unter Verwendung des korrekten Werts erneut umwandeln.". Tja, da war der Haken. Das sollte in der Hilfe beim Befehl CRTSQLRPGI aber auch drin stehen. So schnell kommt man da nicht drauf.

So jetzt geht's. Berechtigung habe ich kontrolliert!

Danke für die Nachfrage.

Reiner