QZDASOINIT Job Prio und so...

[homerun]

Hallo
Gibt es eine Möglichkeit einem "user" der einen QZDASOINIT benutzt mehr Prio zu geben als einen anderen "user" mit einem QZDASOINIT
Job . Aber bevor der user den Job benutzt ?
Nachher kann man ja wrkactjob 5 > 40 die Prios setzen . Kann man das schon vorher bestimmen ?

Danke schonmal

[Sven Schneider]

Dazu erst einmal etwas zu den SQL-DB-Serverjobs QZDASOINIT/QZDASSINIT.

Diese werden beim Starten des Subsystems als "prestarted Jobs" (PJ's) gestartet.
Standardmäßig wird 1 PJ (Standard) gestartet.
Sobald der erste benutzt wird, werden zusätzlich 3 (Standard) weitere PJ's gestartet. --> damit es für die nächsten 3 User beim Connect schneller geht.
Diese PJ-Jobs werden 200 mal wiederverwendet (Standard), bevor sie beendet werden.

Jeder dieser Jobs kann also 200 mal wiederverwendet werden, auch von unterschiedlichen Usern !!!
Leider kann ich nicht festlegen, welcher User welchen Job benutzen kann/soll.
Die zugehörige Jobprio ist in der Job-Klasse QPWFSERVER mit 20 (Standard) hinterlegt. Diese KLasse benutzen alle Jobs im SBS QSERVER.
(Schau dir dazu die RTGE und PJ's zum SBS QSERVER an).

Die einzige Möglichkeit zur Anpassung der Job-Prio besteht folgendermaßen :

- kleines CL-Programm mit CHGJOB schreiben.
- Jobprio als Übergabeparameter im CL-PGM definieren.
- oder du hinterlegst deine Logik für die Jobprio im CL-PGM, den aktuellen User ermittelts du per RTVJOBA CURUSER(&USERVAR)
- CL-Programm als Store-procedure oder mit QCMDEXC per Call im SQL-Verarbeitungsprogramm ausführen.

D.h. der QZDAINIT-Job ändert seine Jobprio selbst.

Viel Spaß
Sven



[Dieser Beitrag wurde von Sven Schneider am 05. März 2002 editiert.]

[homerun]

Hallo
Danke erstmal , ich werde mir das mal anschauen.

[Jacko]

Hallo

ich habe auch ein Problem mit den QZDASOINIT Jobs und zwar werden die "plötzlich" automatisch beendet mit Beendigungscode 0. Könnt ihr mir da einen Tipp geben an was das liegen könnte?

<BLOCKQUOTE><font size="1" face="Verdana, Arial">Zitat:</font><HR>Original erstellt von Sven Schneider:
Dazu erst einmal etwas zu den SQL-DB-Serverjobs QZDASOINIT/QZDASSINIT.

Diese werden beim Starten des Subsystems als "prestarted Jobs" (PJ's) gestartet.
Standardmäßig wird 1 PJ (Standard) gestartet.
Sobald der erste benutzt wird, werden zusätzlich 3 (Standard) weitere PJ's gestartet. --> damit es für die nächsten 3 User beim Connect schneller geht.
Diese PJ-Jobs werden 200 mal wiederverwendet (Standard), bevor sie beendet werden.

Jeder dieser Jobs kann also 200 mal wiederverwendet werden, auch von unterschiedlichen Usern !!!
Leider kann ich nicht festlegen, welcher User welchen Job benutzen kann/soll.
Die zugehörige Jobprio ist in der Job-Klasse QPWFSERVER mit 20 (Standard) hinterlegt. Diese KLasse benutzen alle Jobs im SBS QSERVER.
(Schau dir dazu die RTGE und PJ's zum SBS QSERVER an).

Die einzige Möglichkeit zur Anpassung der Job-Prio besteht folgendermaßen :

- kleines CL-Programm mit CHGJOB schreiben.
- Jobprio als Übergabeparameter im CL-PGM definieren.
- oder du hinterlegst deine Logik für die Jobprio im CL-PGM, den aktuellen User ermittelts du per RTVJOBA CURUSER(&USERVAR)
- CL-Programm als Store-procedure oder mit QCMDEXC per Call im SQL-Verarbeitungsprogramm ausführen.

D.h. der QZDAINIT-Job ändert seine Jobprio selbst.

Viel Spaß
Sven

[Dieser Beitrag wurde von Sven Schneider am 05. März 2002 editiert.][/quote]

[BenderD]

Hi,

das ist der normale Lauf beim disconnect der Verbindung, da legt sich der Job schlafen und verschwindet aus dem WRKACTJOB. Der disconnect wiederrum kann von der Anwendung ausgelöst sein, oder auch von der Ablaufumgebung der Verbindung.

Dieter

[Sven Schneider]

Hallo Jacko,
die QZDASOINIT/QZDASSINIT Jobs sind PJ's (prestarted Jobs), welche automatisch mit dem Subsytem QSERVER gestartet werden.

Diese PJ-Jobs werden mehrmals wiederverwendet bevor sie automatisch beendet werden. (mit Beendigungscode 0)

(siehe WRKSBSD QSERVER --> Auswahl 10 --> Auswahl 5 vor z.B. QZDADOINIT --> Maximale Anzahl Verwendungen . . . . . . . . . . : 200 - MAXUSE)

Das Neustarten erfolgt dann automatisch unter Zuhilfnahme folgender Parameter :
Schwellenwert . . . . . . . . . . . . . . . . . : 1 THRESHOLD
Zusätzliche Anzahl Jobs . . . . . . . . . . . . : 3 ADLJOBS

d.h., wenn die verfügbaren Jobs unter den Wert THRESHOLD fallen, werden die Anzahl Jobs, welche im Parameter ADLJOBS stehen, zusätzlich gestartet.

Ändern kanst du diese Parameter mit CHGPJE.
(Vorsicht !!!)

Sven

[ludwigD]

Dazu erst einmal etwas zu den SQL-DB-Serverjobs QZDASOINIT/QZDASSINIT.

Diese werden beim Starten des Subsystems als "prestarted Jobs" (PJ's) gestartet.
Standardmäßig wird 1 PJ (Standard) gestartet.
Sobald der erste benutzt wird, werden zusätzlich 3 (Standard) weitere PJ's gestartet. --> damit es für die nächsten 3 User beim Connect schneller geht.
Diese PJ-Jobs werden 200 mal wiederverwendet (Standard), bevor sie beendet werden.

Jeder dieser Jobs kann also 200 mal wiederverwendet werden, auch von unterschiedlichen Usern !!!
Leider kann ich nicht festlegen, welcher User welchen Job benutzen kann/soll.
Die zugehörige Jobprio ist in der Job-Klasse QPWFSERVER mit 20 (Standard) hinterlegt. Diese KLasse benutzen alle Jobs im SBS QSERVER.
(Schau dir dazu die RTGE und PJ's zum SBS QSERVER an).

Die einzige Möglichkeit zur Anpassung der Job-Prio besteht folgendermaßen :

- kleines CL-Programm mit CHGJOB schreiben.
- Jobprio als Übergabeparameter im CL-PGM definieren.
- oder du hinterlegst deine Logik für die Jobprio im CL-PGM, den aktuellen User ermittelts du per RTVJOBA CURUSER(&USERVAR)
- CL-Programm als Store-procedure oder mit QCMDEXC per Call im SQL-Verarbeitungsprogramm ausführen.

D.h. der QZDAINIT-Job ändert seine Jobprio selbst.

Viel Spaß
Sven



[Dieser Beitrag wurde von Sven Schneider am 05. M&auml;rz 2002 editiert.]

leider laufen alle jobs mit Quser deshalb wird das so nicht funktionieren

[DVE]

leider laufen alle jobs mit Quser deshalb wird das so nicht funktionieren

.. aber jeder hat seine eigene Jobnummer.

.. desweiteren könntest du das QHST auswerten (MSG-ID CPIAD09). Um von "außen" festzustellen welcher Benutzer sich gerade welchen Job zugeordnet hat.

Gruß
DVE

[ludwigD]

du meinst mit der jobnr. joblog erzeugen, und durch das joblog durchparsen und den tatsächlichen user zu ermitteln,
ja das könnte gehen, aber der ansatz mit
rtvjoba (user) wird halt nicht gehen weil immer quser zrück kommt.

tja wenns leicht wär würde man uns ja nicht brauchen

[DVE]

du meinst mit der jobnr. joblog erzeugen, und durch das joblog durchparsen und den tatsächlichen user zu ermitteln,
ja das könnte gehen, aber der ansatz mit
rtvjoba (user) wird halt nicht gehen weil immer quser zrück kommt.

tja wenns leicht wär würde man uns ja nicht brauchen

beim RTVJOBA erhältst du alle Jobinfos also auch die Jobnummer und im Parameter CURUSER den aktuell angemeldeten Benutzer. Also nicht QUSER sondern den der sich den Job zugeordnet hat.

gruß
DVE

[Fuerchau]

Hier hilft tatsächlich eine SQL-Prozedur, die per

set :MYUser = User

den aktuellen SQL-User abfragt und dann damit ggf. das QCMDQXC/CLP aufruft um die Job-Prio zu setzen.

Aber Achtung:
Die Job-Prio muss auf jeden Fall angepasst werden da sonst irgendein vorheriger Wert stehen bleibt.

Verbindungen, die diese Prozedur nicht aufrufen laufen ggf. mit der falschen Prio.

[ludwigD]

endlich kapiert.
bei rtvjoba
user = user wie man ihn unter wrkactjob sieht (quser in unsren problem)

und curuser ist dann der richtige

vorher

nun

gruß
ludwig