Job Prio des Users ändern?

[Mr-Ferret]

Hallo,
sorry wenn euch die Frage zu banal erscheint oder schon gestellt wurde.
Gibt es eine Möglichkeit bzw. wie kann ich es bewerkstelligen, das ein Job eines Users eine bestimmte Priorität erhält?
Ich weiss, das ich im laufenden Job die "Run priority" ändern kann, aber Standardmäsig ist es immer 20 und ich möchte bei diesem User min. 50 oder evtl. noch höher gehen.
Also wenn mit dem User ein Job gestartet wird dieser automatisch die Run prio. 50 hat.
Ich dachte es geht in der Job description, jedoch finde ich den Eintrag nicht.

Vielen Dank
Gruß
Manfred

[holgerscherer]

Hallo Manfred,
schau Dir bitte mal die zugehörigen Klassen an, da geht das.

z.b.

WRKSBSD QINTER
-> 7 routing entries
Hier kommt es auf die Vergleichswerte an, Interaktivjobs werden normal mit *ANY behandelt. Also 5 vor den letzten Eintrag, der QCMD mit Vergleichswert *ANY aufruft.
Hier siehst Du eine Klasse, z.B. QGPL/QINTER
nun mit WRKCLS QGPL/QINTER und Option 2 rein. Da siehst Du eine Priorität.

Viele Grüße
Holger

[Mr-Ferret]

Hallo Holger,
vielen Dank für deine Erklärung, jedoch bin ich mir nicht sicher ob ich das verstanden habe.
Ich habe einen User "LWS_User" welcher gestartet durch eine Gui, Jobs ausführt.
Diese Jobs laufen im Subsystem QUSRWRK/QSYS sind vom Typ PJ
Wenn ich das nach deinem Beispiel richtig verstanden habe ist die Klasse QSYSCLS50 unter QSYS.
Dort steht die Prio 50 der Job jedoch hat die Prio 20.
Wenn ich in den Job WRKACTJOB mit 2 rein gehe, hat dieser dann den Jobnamen QZDASOINIT mit dem User QUSER und einer Prio von 20.
Was muß ich also tun, das der Job vom User LWS_User immer mit der Prio 50 läuft?

Vielen Dank
Gruß
Manfred

[holgerscherer]

Hallo Manfred,
der QZDASOINIT läuft garantiert mit Jobdescription QGPL/QDFTSVR
WRKJOBD QDFTSVR -> Routing Data QCMDI
Aaber! Prestarted Jobs haben eine eigene Definition.
WRKSBSD QUSRWRK
10 prestart job entries
suche den Eintrag QZDASOINIT, Auswahl 5
Klasse suchen, meist QSYS/QPWFSERVER
Und in dieser Klasse steht 20 drin

Also entweder die Klasse anpassen (mhm...) oder einen PJ Eintrag anpassen.

IBM i Workmanagement ist recht komplex ;-)

-h

[BenderD]

... das würde aber alle User betreffen, das würde ich schön bleiben lassen! Die erste Frage ist zunächst: welches Problem will ich lösen und dann erst: wie stellt man diesen oder jenen Unfug an?

D*B

[Fuerchau]

Im Ernstfall tut der QZDASOINIT ja fast gar nichts, also die Prio macht da keinen Unterschied.
Schlechte SQL's sind da eher das Problem, wenn nämlich Indizes aufgebaut werden müssen. Hier ist anzusetzen, denn Jobprio 50 oder höher ändert in solchen Fällen nicht die Systemlast.

[RobertMack]

Also wenn mit dem User ein Job gestartet wird dieser automatisch die Run prio. 50 hat.

Trage doch dem USRPRF ein Starprogramm ein welches CHGJOB RUNPTY() ausführt...

[Fuerchau]

Nun ja, du musst dazu den Autostartjob anpassen, und anschließend das Originalprogramm aufrufen.
Allerdings läuft der Job bis dahin erst mit QUSER. Erst nach dem SQLConnect wird der CurrentUser gesetzt wobei der Job immer noch QUSER heißt.
Also das ist eine schlechte Option.
Lieber den Debugmodus (ConnectionString, QAQQINI) verwenden und die Ursache ermitteln.

Wie Dieter schon sagt, alles andere ist Murks.

[holgerscherer]

... das würde aber alle User betreffen, das würde ich schön bleiben lassen! Die erste Frage ist zunächst: welches Problem will ich lösen und dann erst: wie stellt man diesen oder jenen Unfug an?

D*B

Das war ja nicht die Frage ;-) Und ganz unter uns - die meisten Klassendefinitionen sind heutzutage per Default eher zweitklassig... und werden meist mit altmodischen Methoden drittklassig umgebaut.
Aber lassen wir lieber den Thread-Ersteller zu Wort kommen, warum ein User explizit bevorzugt werden soll...

-h

[Fuerchau]

In diesem Fall eher benachteiligt, denn je höher die Prio desto "relativ" langsamer ist der Job.

[Mr-Ferret]

Guten Morgen,
und ich dachte, das ist bestimmt ganz einfach
Nun um das ganze etwas ausführlicher zu erklären:
Wir betreiben auf der i5 ein ERP System das da heist M3 und ist von der Firma Infor.
Innerhalb diesem System gibt es die Möglichkeit eigene Masken mit SQL-Abfragen zu generieren und den Usern zur Verfügung zu stellen. Da diese Abfragen zum Teil doch etwas mehr CPU benötigen und dadurch teilweise das System ausbremsen, war meine Idee, ich schraub die Prio runter, damit falls ein anderer "wichteiger" Job kommt dieser bevorzugt wird bzw. der normale Ablauf nicht darunter leidet.

Die SQL Statements wurden schon soweit durchläuchtet, das unserer Meinung und auch Beraterseitig keine weiter Performance rausgeholt werden kann.

Ich wollte nun eben für diesen einen User die Prio ändern, nicht für das ganze System oder andere User damit in mitleidenschaft ziehen.

[BenderD]

... wenn denn das ERP komplett über QZDASOINIT zugreift, wäre Holgers Vorschlag der schlechteste, weil er allen schadet und nichts positives bewirkt und der von Robert der, der am wenigsten schadet, weil er nichts bezweckt.
Selektiv einzugrenzen gibt es nur die Möglichkeit über die Exit Schnittstellen von DB2, oder über Auftrennung der Serverjobs in verschiedene Subsysteme und dann kann man auf SubsystemEbene unterschiedliche eine class mit unterschiedlichen Prios zuordnen. Aber eigentlich gehört das an der Quelle geheilt: am Index Design!!!

D*B