STRSQL - in welcher Datei???

[woodstock99]

aha.... hmmm weiß jemand näheres??? irgendwie muß man da ja drauf zugreifen können....

[Fuerchau]

Mit entsprechender Berechtigung und MI-Zugriffen.
Die Daten stehen in einer USRQ bzw. in eienm USRSPC, der dem Benutzerprofil angehängt ist. Dabei werden die SQL-Eingaben je Device zugeordnet.
Ein API zum Auslesen ist nicht definiert.
Man kann aber die Sitzungsinhalte per F13-Menü in eine Datei ausgeben lassen (stimmt, beim Verlassen).

[woodstock99]

danke für eure antworten.. naja dann heisst es für mich mal wieder

jugendforscht wie man den ganzen sums auslesen kann....

[BenderD]

... der Kram steht im Context QRECOVERY und man kommt da nur mit DMPSYSOBJ oder MI Programmierung dran. Soweit dazu was zu finden ist ist der Type wohl 19 und der Subtype EE. Das ganze ist undeokumentiert und die zu findenden Informationen unvollständig/widersprüchlich.

D*B

[Fuerchau]

Zusätzlich kann sich das auch nach jedem Release wieder ändern (habe ich zumindest per DMPSYSOBJ V5R1 auf V5R3 mal festgestellt).

[woodstock99]

jupp das hab ich soweit auch gefunden


DMPSYSOBJ OBJ(ISQLSTUUUUUDDDDD) CONTEXT(QRECOVERY) TYPE(19) SUBTYPE(EE)
bla bla bla......

ja wie dieter schon sagte was da bis jetzt zu finden ist ist keine wirkliche hilfe.. aber parole niemals aufgeben )

[BenderD]

... das ist zum Beispiel eine der falschen Informationen (Devicename ist Quatsch, die Info kann von einer Session auf eine Session anderen Namens wandern...)

D*B

jupp das hab ich soweit auch gefunden


DMPSYSOBJ OBJ(ISQLSTUUUUUDDDDD) CONTEXT(QRECOVERY) TYPE(19) SUBTYPE(EE)
bla bla bla......

ja wie dieter schon sagte was da bis jetzt zu finden ist ist keine wirkliche hilfe.. aber parole niemals aufgeben )

[Fuerchau]

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.

[andreaspr@aon.at]

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]

@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??

[BenderD]

- 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]

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