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.

[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

[AG1965_2]

Viele Softwarehäuser haben sich für den internen Gebrauch eine Überwachung gebastelt, die, wenn ein Job zu sehr die anderen Leute behindert, die Priorität dieses Jobs heruntersetzt.
Wenn 1. an den SQL-Statements wirklich nichts mehr zu optimieren ist, und 2. Indizes wirklich nichts mehr helfen, würde ich 3. daran denken, so was auch auf einem Produktivsystem einzusetzen, um nicht immer manuell eingreifen zu müssen.

[holgerscherer]

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.

Ganz Einfach ist meinst einfach ganz falsch ;-) Wenn ein SQL viel CPU benötigt, hat das Gründe, die im Design liegen (wie Dieter und Baldur korrekt schreiben). Und wenn jeder User selbst sein Design machen kann (sprich, SQL in bairisch reintippt), wird es lustig. Wenn alle meinen, es ist performancemässig nichts mehr raus zu holen, wird gern mit neuer Hardware gewunken, oder (wie von mir pauschalisiert) mit demokratischer Bestrafung per Priorität. Aber damit ist das Problem ja nicht gelöst.

Wenn Du nur für einen speziellen User die Prio ändern willst, dann halte Dich an die vorhandenen Vorschläge: CHGJOB wenn möglich. Alternativ ein Scriptle, das mittels WRKACTJOB prüft, was dieser User macht, und wenns ein QZDASOINIT ist mit CPU > 20%, dann eine zwangspause von 3-5 Sekunden (wirkt Wunder) und schlechterer Priorität.

Kann beispielsweise auf der PUB1.DE ausprobiert werden.

-h