[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Jan 2012
    Beiträge
    917

    SBMJOB mit RUNPTY

    Hallo,

    es gibt wahrscheinlich keine einfache Möglichkeit, einem Job direkt eine bestimmte Run-Priorität zuzuordnen, oder?

    Es geht mir darum, ein Programm täglich mit sehr niedriger Priorität als SBMJOB zu starten. Ich will natürlich nicht jeden Tag manuel einen CHGJOB mit RUNPTY manuell angeben. Der Befehl SBMJOB kennt aber den Parameter RUNPTY nicht. Es scheint irgendeine Möglichkeit zu geben, Classen zu definieren oder Routingdata anzugeben. Ich muss zugeben, dass ich mich damit nicht beschäftigt habe.

    Weiß jemand auf die Schnelle, wie das geht?

    Vielen Dank im Voraus.

    Dieter

  2. #2
    Registriert seit
    Dec 2014
    Beiträge
    275
    zB Variante 1:

    - CRTCLS CLS(myclass) RUNPTY(30)
    - ADDRTGE SBSD(xxx) SEQNBR(nn) CMPVAL(ABC123) PGM(QCMD) CLS(myclass)
    --> SBMJOB CMD(xyz) RTGDTA(ABC123)
    (CMPVAL und RTGDTA müssen übereinstimmen!)

    oder Variante 2:
    Ein CL submiten, in diesem ein CHGJOB RUNPTY und danach das eigentliche Pgm/Cmd aufrufen

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    917
    Vielen Dank für deine Lösungen. Ich tendiere zur Lösung mit dem CRTCLS. Mir ist nur nicht klar, was ich da genau mache. Ich weiß eigentlich gar nicht, was in diesem Zusammenhand eine CLS ist und was ein RTGE ist.

    Kann ich da etwas kaputt machen, wenn ich einen Routing-Entry für das SBS QBATCH mache? Ich möchte auf jeden Fall nur meinen eigenen Job beeinflussen. Nichts sonst am Subsystem ändern.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    18.670
    Nö, du machst nichts kaputt.
    Die CLS-Objekte dienen eben dem Finetouning für Workmanagement.
    RTGE's sind Routingentries. Anhand dieser werden Jobs den Job-Queues und Subsystemen zugeordnet.

    Aber eigenlich ist das so nicht nötig, da du real keinen nennenswerten Effekt erreichst.
    Was willst du eigentlich tun?

    Alternativ kann man in Subsysteme auch Autostart-Jobs (ADDAJE) oder Prestart-Jobs (ADDPJE) hinzufügen, wenn diese permanent laufen sollen (und vorzugsweise per Sleep/DTAQ-Wait o.ä. auf Ereignisse warten).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Jan 2012
    Beiträge
    917
    Vielen Dank für die Erklärung.

    Bei uns laufen die "normalen" Batch-Jobs mit runpty 50. Ich habe jetzt einen Job, der eine Cachedatei permanent aktualisiert. Da es sich "nur" um einen Cache handelt, sollte dieser Job die anderen Jobs möglichst nicht beeinträchtigen. Deshalb hatte ich gedacht, eine runpty von 51 wäre sinnvoll. Aber natürlich kann es sein, dass das gar nichts bringt. Unsere Maschine ist eigentlich recht schnell und hat wahrscheinlich noch Reserven.

    Mir ist auch nicht so recht klar, was die runpty bringt. Klar, die Jobs mit niedrigerer Zahl werden irgendwie bevorzugt. Aber wie das System das macht, ist mir unklar. Eine sehr "harte" Umsetzung würde ja dafür sorgen, dass die Jobs mit größerer runpty erst dann zum Zuge kommen würden, wenn alle anderen Jobs mit besserer Priorität gar nichts mehr zu tun haben. Das wird ja niemals der Falls sein.

    Aber egal,
    vielen Dank für eure Erklärungen!

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    18.670
    Kurze Erklärung:
    Job-Scheduling funktioniert mit einer sog. Zeitscheibe.

    Das folgende ist ein vereinfachtes bildliches Modell:

    Alle aktiven Jobs werden gleichmäßig auf diese Scheibe verteilt, wobei die Priorität quasi die Häufigkeit auf der Scheibe bestimmt.
    Wenn die Prio 1 die höchste ist, dann wird "100 - Prio" gerechnet, ansonsten halt die Prio.
    M.a.W: Bei der Prio 50 ist jeder Job 50 mal vertreten, bei Prio 51 dann 49 Mal.
    Bei 1000 laufenden Jobs macht dies 49999 Einträge, also 999 x 50 + 1 x 49.
    Hinzu kommt die Verteilung und auch ggf. Verschiebung von Jobs auf verschiedene CPU's, da jede CPU ihre Zeitscheibe verwaltet.

    Somit lässt sich ausrechnen, wie stark der Prio 51-Job tatsächlich verlangsamt wird.

    Hinzukommt, dass jede E/A-Aktion (Platte, Netzwerk, Geräte) den zugeteilten Zeitanteil unterbricht und der nächste Job in der Reihe drankommt. Die nicht verbrauchte Zeit wird nicht angespart sondern kommt dem Gesamtsystem zugute. Der Job wird erst wieder aktiv, wenn die E/A-Operation beendet ist und der Job in der Zeitscheibe wieder dran ist.

    Zu sehen ist das Ganze dann bei WRKSYSSTS.
    "Aktiv => Warten" = Jobs mit vorzeitigem Zeitscheibenende.
    "Warten => nicht wählbar" = Jobs, deren E/A beendet ist aber in einer bestimmten Zeit laut Zeitscheibe noch nicht wieder dran waren.
    "Aktiv => nicht wählbar" = Jobs, die ihre Zeitscheibe voll ausnutzen, aber in einer bestimmten Zeit noch nicht wieder dran waren.
    Die letzten beiden Angaben können auf CPU-Engpässe hindeuten.

    Bei DSPJOB kannst du die Laufzeit im Verhältnis zur verbrauchten CPU-Zeit eines Jobs ausrechnen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Jan 2012
    Beiträge
    917
    Hallo Baldur. Danke für die wirklich gute Erklärung.

    Das würde dann bedeuten, dass die Zahl bei runpty nicht nur die Reihenfolge der Jobs beeinflusst, sondern tatsächlich auch den Anteil an der Zeitscheibe mitbestimmt.
    Wenn ich nur Jobs mit Prio 50 hätte und dann einen mit Prio 51 zusätzlich definieren würde, dann würde die Prio 51 bewirken, dass der Job öfter zum Zuge kommt, als wenn ich den Job mit 60 definieren würde. Das war mir bisher nicht klar. Ich dachte immer, die exakte runpty wäre egal und es ginge nur darum, welcher Job niedriger oder höher priorisiert ist.

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    18.670
    Nicht die Reihenfolge wird beeinflusst sondern der Anteil an der gesamt verfügbaren Zeit.
    Prio 51 heißt, 1x weniger, da 1 die höchste Prio und 99 die niedrigste ist.

    Wenn du also nur 2 Jobs hättest, käme Job 1 50 Mal, und Job 2 49 Mal innerhalb einer vorgegebenen Zeit dran.
    Um Jobs gleichmäßig zu bedienen und die Zeit nicht unendlich ist, bekommt ein Job nur max. x Milli-/Microsekunden je Zeitscheibenanteil.

    Bei diesen 2 Jobs hast du also 99 Anteile in einer vorgegeben Zeit zur Verfügung.
    Interessant ist also eher die Differenz von 20 zu 80, wobei die IBM i i.M. 20 für Dialog und 50 für Batch wählt, in der Hoffnung, dass Dialogjobs i.d.R. ihre Zeitscheibe nie ausnutzen (warten auf den User), was die Problematik rechenintensiver Dialoge erklärt.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Jan 2012
    Beiträge
    917
    Vielen Dank. Man lernt nie aus ...

    Dieter

Ähnliche Themen

  1. SQLCSR und SBMJOB
    Von easchbac im Forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 02-06-16, 06:51
  2. SBMJOB
    Von malzusrex im Forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 22-03-15, 06:33
  3. SBMJOB und DEC
    Von sirdidi im Forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 24-01-14, 10:31
  4. Berechtigung bei SBMJOB
    Von horst im Forum IBM i Hauptforum
    Antworten: 8
    Letzter Beitrag: 15-01-02, 06:55
  5. sbmjob
    Von muadeep im Forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 13-11-01, 15:05

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •