QZDASOINIT Job Prio und so...

[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ä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