View Full Version : STRSQL - in welcher Datei???
Hm, bisher wurden mir mein SQL's seit V5R3 immer sitzungsspezifisch angezeigt. Früher (ich weiß nicht mehr bis wann) war das Sitzungsunabhängig, da entschied wohl die Reihenfolge bzw. der parallele Aufruf von STRSQL.
Wenn ich an einem System mit wechselnden Sitzungen (z.B. QPADEV) arbeite komme ich an meine frühreren SQL's nicht mehr dran.
Ausserdem scheint das System sich da auch selber zu bereinigen.
Sporadisch startet STRSQL mit einem leeren Fenster.
woodstock99
12-04-10, 08:41
jupp......
naja ich glaub da hilft nur wieder ein umweg wie z.b. sowas......
http://search400.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid%203_gci1096666,00.html
... man sollte schon immer dazu sagen, was man vor hat. Für irgendwelche Berechtigungsdinge ist der Ansatz über die STRSQL Info zu gehen untauglich, man kann ja ohne speichern raus. Statt über DBMON zu gehen, würde ich erst mal bei den Exits nachsuchen - die richtige Lösung wäre hier ohnehin eine vernünftige Object Security Konzeption (aber tout le monde sucht ja hier stets nach Placebo Lösungen, weshalb ich diese Sachen aus meinem Angebot gestrichen habe!!!)
D*B
jupp......
naja ich glaub da hilft nur wieder ein umweg wie z.b. sowas......
How to log use of STRSQL (http://search400.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid%203_gci1096666,00.html)
andreaspr@aon.at
12-04-10, 09:46
Ich habe selbst auch noch nicht durchblicken können wie sich die Informationen zusammenstellen, aber zumindest kann ich Bender bestätigen.
Es gibt bei uns einen "Verwaltungs-User" auf der AS/400. Wenn ich mit dem User einsteige und ins STRSQL gehe sehe ich auch die Befehle von meinen Kollegen. Das aber auch nicht immer. (ZB wenn ich mit dem selben User ein 2tes mal eingestiege).
Hm, bisher wurden mir mein SQL's seit V5R3 immer sitzungsspezifisch angezeigt. Früher (ich weiß nicht mehr bis wann) war das Sitzungsunabhängig, da entschied wohl die Reihenfolge bzw. der parallele Aufruf von STRSQL.
Wenn ich an einem System mit wechselnden Sitzungen (z.B. QPADEV) arbeite komme ich an meine frühreren SQL's nicht mehr dran.
Ausserdem scheint das System sich da auch selber zu bereinigen.
Sporadisch startet STRSQL mit einem leeren Fenster.
woodstock99
12-04-10, 10:12
@andreaspr...
wie ist der verwaltungsuser bei euch angelegt(usrprf , berechtigungen, userklasse usw ...)
deinen satz "Das aber auch nicht immer. (ZB wenn ich mit dem selben User ein 2tes mal eingestiege)." verstehe ich nicht ganz....
die history ist user+sitzungsabhänig....
also ist das ergebnis immer anders oder verstehe ich dich nur falsch??
- im Jobkontext des Benutzers können mehrere SQL Sitzungen abgespeichert werden.
- eine gespeicherte Sitzung kann nicht von mehreren Jobs des Benutzers gleichzeitig verwendet werden
- die Sitzungen werden unter dem Namen des Devices gespeichert, der die Sitzung ursprünglich mal erzeugt hat
- bei STRSQL wird die erste freie zugeordnet
- ist keine frei, wird unter dem Namen des Devices eine neu erzeugt
beim DMPSYSOBJ kann man Wildcards angeben (so kommt man an die Namen und Inhalte dran).
D*B
andreaspr@aon.at
12-04-10, 10:52
Benutzerklasse . . . . . . . . . . . . . . : *USER
Sonderberechtigung . . . . . . . . . . . . : *ALLOBJ
*JOBCTL
*SPLCTL
Eigner . . . . . . . . . . . . . . . . . . : *USRPRF
Gruppenberechtigung . . . . . . . . . . . : *NONE
Art der Gruppenberechtigung . . . . . . . : *PRIVATE
Zusätzliche Gruppenprofile . . . . . . . . : *NONE
Unterstützungsstufe . . . . . . . . . . . : *SYSVAL
Aktuelle Bibliothek . . . . . . . . . . . : *CRTDFT
Möglichkeiten einschränken . . . . . . . . : *NO
Jobbeschreibung . . . . . . . . . . . . . : QDFTJOBD
Bibliothek . . . . . . . . . . . . . . . : QGPL
der Rest ist allgemein *SYSVAL
ich denke, dass - wenn man mit dem gleichen Profil arbeitet - die SQL-Historie jedes mal überschrieben wird, sobald ein User aus dem STRSQL aussteigt.
Ich habe das gerade mit einem Kollegen getestet und ich habe fast immer eine Historie von einer anderen Sitzung erhalten.
So quasi: Sitzung A geht ins STRSQL erhält Historie 1 Sitzung B geht ins STRSQL erhält Historie 2. Stizung A beendet, Sitzung B beendet, Sitzung A erhält nun Historie 2.
Ist aber auch nicht immer so. Leide haben wir dann doch nicht soviel Zeit und Lust ganz genau herauszufinden, wann er welche Historie greift.
Auf jeden fall wird zwar auch für jede Sitzung eine Historie gespeichert, nur wenn mehrere mit dem gleichen User arbeitet, ist nicht gewährleistet, dass ich die Historie von meiner Sitzung jedes mal bekomme. Scheint mehr ein Glücksspiel zu sein.
die Aussage von Bender:
- eine gespeicherte Sitzung kann nicht von mehreren Jobs des Benutzers gleichzeitig verwendet werden Kann
haben wir in diesem Test auch wiederlegen können.
Edit: wir haben V5R4
soso, wie sieht denn das gleichzeitige benutzen derselben gespeicherten Sitzung aus??? Die SQL Befehle des einen Benutzers tauchen bei dem anderen auf? Wenn der eine speichert kann der andere nicht? - das halte ich für ein Gerücht!!!
D*B
Benutzerklasse . . . . . . . . . . . . . . : *USER
Sonderberechtigung . . . . . . . . . . . . : *ALLOBJ
*JOBCTL
*SPLCTL
Eigner . . . . . . . . . . . . . . . . . . : *USRPRF
Gruppenberechtigung . . . . . . . . . . . : *NONE
Art der Gruppenberechtigung . . . . . . . : *PRIVATE
Zusätzliche Gruppenprofile . . . . . . . . : *NONE
Unterstützungsstufe . . . . . . . . . . . : *SYSVAL
Aktuelle Bibliothek . . . . . . . . . . . : *CRTDFT
Möglichkeiten einschränken . . . . . . . . : *NO
Jobbeschreibung . . . . . . . . . . . . . : QDFTJOBD
Bibliothek . . . . . . . . . . . . . . . : QGPL
der Rest ist allgemein *SYSVAL
ich denke, dass - wenn man mit dem gleichen Profil arbeitet - die SQL-Historie jedes mal überschrieben wird, sobald ein User aus dem STRSQL aussteigt.
Ich habe das gerade mit einem Kollegen getestet und ich habe fast immer eine Historie von einer anderen Sitzung erhalten.
So quasi: Sitzung A geht ins STRSQL erhält Historie 1 Sitzung B geht ins STRSQL erhält Historie 2. Stizung A beendet, Sitzung B beendet, Sitzung A erhält nun Historie 2.
Ist aber auch nicht immer so. Leide haben wir dann doch nicht soviel Zeit und Lust ganz genau herauszufinden, wann er welche Historie greift.
Auf jeden fall wird zwar auch für jede Sitzung eine Historie gespeichert, nur wenn mehrere mit dem gleichen User arbeitet, ist nicht gewährleistet, dass ich die Historie von meiner Sitzung jedes mal bekomme. Scheint mehr ein Glücksspiel zu sein.
die Aussage von Bender:
- eine gespeicherte Sitzung kann nicht von mehreren Jobs des Benutzers gleichzeitig verwendet werden Kann
haben wir in diesem Test auch wiederlegen können.
Edit: wir haben V5R4
andreaspr@aon.at
12-04-10, 12:23
soso, wie sieht denn das gleichzeitige benutzen derselben gespeicherten Sitzung aus??? Die SQL Befehle des einen Benutzers tauchen bei dem anderen auf? Wenn der eine speichert kann der andere nicht? - das halte ich für ein Gerücht!!!
D*B
nicht ganz so. Ich gehe ins STRSQL führe ein paar SQLs aus, und beende mit F3.
Ich gehe wieder ins STRSQL und sehe meine letzten Befehle.
Mein Kollege geht jetzt auch ins STRSQL und sieht auch meine Befehle ==> gleiche Historie in beiden Sitzungen. Diesen Fall hatten wir auf jeden Fall so (sogar ein paar mal)! Das ist kein Gerücht, sondern das war Fakt.
Jedoch interessant wird es dann, wenn der erste wieder aussteigt und ein dritter User ins STRSQL einsteigt bzw. der erste aussteigt, der zweite aussteigt und der erste wieder einsteigt usw.
wir haben dadurch die verschiedesten Historien erhalten.
... nochmal ganz langsam zum mitdenken:
- zwei verschiedene Benutzer sehen niemals die gleiche Historie!!!
- ein Benutzer kann an verschiedenen Bildschirmen die gleiche SQL Sitzung wiederaufnehmen, aber nie!!! gleichzeitig
D*B
nicht ganz so. Ich gehe ins STRSQL führe ein paar SQLs aus, und beende mit F3.
Ich gehe wieder ins STRSQL und sehe meine letzten Befehle.
Mein Kollege geht jetzt auch ins STRSQL und sieht auch meine Befehle ==> gleiche Historie in beiden Sitzungen. Diesen Fall hatten wir auf jeden Fall so (sogar ein paar mal)! Das ist kein Gerücht, sondern das war Fakt.
Jedoch interessant wird es dann, wenn der erste wieder aussteigt und ein dritter User ins STRSQL einsteigt bzw. der erste aussteigt, der zweite aussteigt und der erste wieder einsteigt usw.
wir haben dadurch die verschiedesten Historien erhalten.