strsql überwachen

[dibe]

Guten Tag,
gibt es eine Möglichkeit die einzelnden Befehle im STRSQL (5250) zu überwachen?

Ich habe ein Exit Programm für
QIBM_QZDA_SQL1
QIBM_QZDA_SQL2
erfasst und stelle nun fest, das das Pgm nicht aufgerufen wird.

Hintergrund:
Viele User dürfen SQL verwenden, i.d. R SELECT ...
Einige machen auch mal ein UPDATE oder DELETE

Der User Exit soll das Stmt untersuchen ob eine Lib drin ist bzw. die Liblist des Jobs ermitteln und bei update oder delete auf die ECHT Libs das Statement melden.
Erst nach einer Freigabe durch einen 2. User (in unserer DB) darf das Stmt ausgeführt werden.
Bisher gilt das als Regel die 'vereinbart' ist, soll aber technisch unterstützt werden.

UPDATE oder DELETE in den Programmen sollen nicht betroffen sein.

Vielen Dank
Dietlinde Beck

[Fuerchau]

Ganz so einfach kannst du dir das nicht machen, da bei SQL die LIBL ggf. nicht relevant ist.
Du kannst das Default-Schema in der Verbindung angeben oder per Set-Anweisung verändern und per QCMDEXC-Call sogar einen OVRDBF hinlegen, der den SQL woanders hin verweist. Das taucht in der LIBL nicht auf.
QDB_OPEN wäre da u.U. die bessere Alternative.

Um wirklich eine vollständige Kontrolle zu haben empfehle ich immer ein Komplettprodukt einzusetzen, dass alle Registry-Infos überwacht.

STRSQL arbeitet (glaube ich eher) mit CLI-API's.

[andreaspr@aon.at]

Wie Baldur schon schrieb ist der QDB_OPEN die richtige Wahl dafür.
Dieser greift, egal ob STRSQL, Embedded SQL, JDBC etc.

Hier kannst du lediglich DELETE, INSERT, SELECT und UPDATE prüfen.
Auch die Tabelle + Bibliothek wird dir hier geliefert.
Wenn es sich z.B. um einen JOIN handelt, wo auf mehrere Tabellen zugegriffen wird, bekommst du eine Liste aller Tabellen + Bibltiothek im Aufruf des Exit-PGM.

Du kannst hier jedoch nicht verhindern, dass ein CREATE TABLE abgesetzt wird.

lg Andreas

[dibe]

Danke für die Antworten,
da werde ich mich mal mit dem QDB_open beschäftigen.

@Baldur
Es geht nicht darum bösartigkeiten zu verhindern.
Es geht um versehentliche falsche Aktionen, die für die Testumgebung gedacht, aufgrund der Liblist aber versehentlich in der Echtumgebung laufen.

OVR oder Schema ... haben wir hier nicht (-lach-)

Danke

Ich habe hier in der qsysinc/qrpglesrc ein EDBOPNDB Eintrag. Ist das der *entry parm?

[dibe]

Habe das soeben mal ausprobiert,
Aufgerufen wird das ExitPgm nun beim select aus strsql.
Die Parameter verstehe ich nicht, oder die sind falsch.
Ich habe nur

DEDBDBFAE00 DS
D* QDBE Opn DB File Array Entry
D EDBDBEFN02 1 10
D* QDBE File Name
D EDBDBELN01 11 20
D* QDBE Library Name
D EDBDBEMN01 21 30
D* QDBE Member Name
D EDBQDBER01 31 32
D* QDBE Reserved
D EDBEDBFT01 33 36I 0
D* QDBE DB File Type
D EDBDBEUP01 37 40I 0
D* QDBE Underlying Physical
D EDBBEOIO01 41 41
D* QDBE Open Input Opt
D EDBBEOOO01 42 42
D* QDBE Open Output Opt
D EDBBEOUO01 43 43



EVAL EDBDBFAE00
EDBDBEFN02 OF EDBDBFAE00 = ' DB'
EDBDBELN01 OF EDBDBFAE00 = 'OP0100 '
EDBDBEMN01 OF EDBDBFAE00 = ' DS'
EDBQDBER01 OF EDBDBFAE00 = 'P_'
EDBEDBFT01 OF EDBDBFAE00 = -640552384
EDBDBEUP01 OF EDBDBFAE00 = 1077991639
EDBBEOIO01 OF EDBDBFAE00 = 'C'
EDBBEOOO01 OF EDBDBFAE00 = 'K'
EDBBEOUO01 OF EDBDBFAE00 = '7'
EDBBEODO01 OF EDBDBFAE00 = '4'




ich habe hier ein BSP gefunden (https://www.ibm.com/developerworks/ibmi/library/i-open-db-file-exit-program/index.html).

Aber wenn das 'alles' ist, kann ich damit nix anfangen!

das Sql Stmt fehlt!
Die Info, das ein Update oder Delete gemacht werden soll als '1' oder '0'
hilft gar nicht, wenn ich keine Herkunft (welches Pgm macht das) habe
Und das über den Job zu ermitteln, bei JEDEM Dateizugriff?
Nicht wirklich!

Schade.
Noch einer eine Idee?
Danke
DiBe

[Fuerchau]

Die Begründung für so eine Aufgabe finde ich da schon seltsam.
Das bestätigt da schon, dass Programmierer bereits in der Biebel erwähnt wurden: "...denn sie wissen nicht was sie tun.";-).
Ich würde da schon eher im Ansatz sicherstellen dass die Umgebung stimmt.

Was die Parameter angeht, so sind diese u.U. vom falschen Release. Online gibts da bestimmt neuere Definitionen.

Ansonsten frag ich mal jemanden, der sich explizit auskennt.

Und was die API's angeht:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzajr/rzajrmstexdb.htm

da finde ich auch keine Programminformation.
Du kannst ja auch mal das NDB-API probieren.

Ebenso einfach ist das Auslesen der Stackinformation. Das habe ich auch schon mal im Trigger gemacht da der tatsächliche Auslöser (eben nicht QDBPUT) gesucht wurde.

[BenderD]

ich habe hier ein BSP gefunden (https://www.ibm.com/developerworks/ibmi/library/i-open-db-file-exit-program/index.html).

Noch einer eine Idee?
Danke
DiBe

... einfach das Programm abpinseln, das sieht so aus, dass es funktionieren sollte!!!

D*B,
der sich fragt, wofür es Objekt Security gibt.

[holgerscherer]

der sich fragt, wofür es Objekt Security gibt.

Klar:
weils schee is :)

[dibe]

ist das bei Euch anders?

Die Entwickler arbeiten in der Testumgebung, biegen sich Datein so hin, um die neuen Funktionen zu testen, mal mehr mal weniger.
Hektischer Tag, anruf aus der Fachabteilung, irgendwas geht nicht.
Wechsel in die Produktionsumgebung, ausprobieren, ok, alles i.o. Anwender hatte 'irgendwas' vergessen/nicht beachtet. TelKo, zum nächsten übernächsten oder vergangenen Projekt.
Dazu noch schnell etwas nachsehen, irgend eine Auswertung auf Echtdaten.
Aus Gewohnheit die Echtdaten mit Bibliothek abgefragt. (Liblist zeigt noch auf Echt Daten)
Dann endlich Ruhe,
update Datei set Feld = Wert where ...
xxx Sätze aus Datei in LIB ECHT geändert. MIST

Passiert 1 mal im Jahr, ist aber (fast) immer sehr ärgerlich.
Wie erzwingt Ihr die Disziplin?

Dietlinde Beck

[andreaspr@aon.at]

Genau, du bekommst nur die Infos:
* Job
* Libs und Tabellen
* Action (insert, delete, update, select)
Die restlichen Infos muss man sich separat ermitteln.