-
strsql überwachen
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
-
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.
-
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
-
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?
-
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
PHP-Code:
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
PHP-Code:
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.
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
-
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/knowledg...ajrmstexdb.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.
-
Zitat von dibe
... einfach das Programm abpinseln, das sieht so aus, dass es funktionieren sollte!!!
D*B,
der sich fragt, wofür es Objekt Security gibt.
-
Zitat von BenderD
der sich fragt, wofür es Objekt Security gibt.
Klar:
weils schee is
-
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
-
Genau, du bekommst nur die Infos:
* Job
* Libs und Tabellen
* Action (insert, delete, update, select)
Die restlichen Infos muss man sich separat ermitteln.
-
Die Disziplin bedeutet, dass es für Echt und Test tatsächlich getrennte Umgebungen gibt, die ein Ummelden erzwingen (Testuser, Echtuser).
Über die erwähnte Objektsicherheit komme ich eben nur an die Testdaten als Testuser und umgekehrt.
Dies mag zwar lästig sein, aber sicher und einfach ist es doch mal eben eine weitere Sitzung aufzumachen (im Zweifel geht immernoch Systemanfrage 1) und sich in die richtige Umgebung zu setzen.
Und Firmen, die nicht unbedingt mit dem Geld geizen müssen richten zusätzlich noch eine LPAR als Testumgebung ein. Außer Platten kostet das nichts.
-
So, habe nun die Bestätigung bekommen:
"Das geht nur über die Schnittstelle
QIBM_QDB_OPN
Den STRSQL bekommen sie eigentlich gar nicht mit, aber alle Befehle.
Aber die Schnittstelle ist sehr kritisch, da sie bei allen Programmen
aufgerufen wird, die nicht aus der QSYS kommen."
Similar Threads
-
By KingofKning in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-15, 00:32
-
By NEWSolutions Redaktion in forum NEWSolutions artikel
Antworten: 0
Letzter Beitrag: 09-05-15, 23:51
-
By DISCOME in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 25-02-14, 14:55
-
By homerun in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 25-04-03, 10:37
-
By Günther in forum IBM i Hauptforum
Antworten: 7
Letzter Beitrag: 20-03-03, 13:51
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks