Wiederkehrender Job mit spätester Ausführungszeit

Getting started ... Alles für einen gelungenen Start.
11 Beiträge • Seite 1 von 1
11 Beiträge Seite 1 von 1

Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von DeathAndPain (Top Expert / 1579 / 182 / 345 ) »
Hallo zusammen,

kurze Frage an die Experten: Wenn ich einen Job einplane, der z.B. stündlich ausgeführt werden soll, der aber nicht ausgeführt werden soll, wenn der von der vorigen Stunde noch nicht abgeschlossen ist (in dem Fall die Ausführung einfach überspringen und nächste Stunde wieder einsteigen), gibt es dafür in der SM37 eine elegante Einplanungslösung, oder muss ich selber im ausgeführten Report anhand der Tabellen TBTCO und TBTCP schauen, ob eine Instanz von mir bereits unterwegs ist?


Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von black_adept (Top Expert / 3648 / 77 / 748 ) »
Moin D&P,
musst du selber machen - etwa so:

Code: Alles auswählen.

    CALL FUNCTION 'GET_JOB_RUNTIME_INFO'
      IMPORTING
        jobcount        = ls_this_job-jobcount
        jobname         = ls_this_job-jobname
      EXCEPTIONS
        no_runtime_info = 1
        OTHERS          = 2.
    IF sy-subrc = 0.
      SELECT 'X'
        FROM tbtco
        WHERE status    = 'R'  " Running
          AND jobname   = @ls_this_job-jobname
          AND jobcount <> @ls_this_job-jobcount
        INTO @DATA(lv_other_job_still_running) UP TO 1 ROWS.
      ENDSELECT.
      IF lv_other_job_still_running = 'X'.
        me->suicide( '2' ).
      ENDIF.
    ENDIF.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von a-dead-trousers (Top Expert / 3776 / 143 / 984 ) »
Alternativ könnte man auch ein Sperrobjekt z.B. auf den Report-Namen verwenden. Bei Start des Reports wird das Sperrobjekt angefordert. Funktioniert das nicht, dann läuft schon ein anderer Report mit dem Namen. Am Ende des Reports wird das Sperrobjekt wieder freigegeben.

Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
DeathAndPain

Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.07
Basis: 7.40

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von IHe (ForumUser / 88 / 25 / 27 ) »
... so haben wir das auch gelöst:

Code: Alles auswählen.

METHOD check_running.

  DATA:
    lv_prog  TYPE indx-srtfd,
    lv_relid TYPE indx-relid VALUE 'EP',
    lv_srtf2 TYPE indx-srtf2 VALUE '0'.

  lv_prog = iv_report.

  rv_running = abap_false.

  CALL FUNCTION 'ENQUEUE_ESINDX'
    EXPORTING
      relid          = lv_relid
      srtfd          = lv_prog
      srtf2          = lv_srtf2
    EXCEPTIONS
      foreign_lock   = 1
      system_failure = 2.
  IF sy-subrc NE 0.
    rv_running = abap_true.
  ENDIF.

ENDMETHOD.
Aufruf mit iv_report = sy-repid.

Zum Abschluss noch:

Code: Alles auswählen.

METHOD DEQUEUE.
  DATA:
    lv_prog  TYPE indx-srtfd,
    lv_relid TYPE indx-relid VALUE 'EP',
    lv_srtf2 TYPE indx-srtf2 VALUE '0'.

  lv_prog = iv_report.

  CALL FUNCTION 'DEQUEUE_ESINDX'
    EXPORTING
      relid = lv_relid
      srtfd = lv_prog
      srtf2 = lv_srtf2.

ENDMETHOD.
Ingo Hoffmann

ECC|S/4HANA|BTP
dbh SAP Solutions

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von black_adept (Top Expert / 3648 / 77 / 748 ) »
@a-d-t und IHE: Euer Ansatz ist sicher der schönere, wenn ich verhindern will, dass ein PROGRAMM 2x gleichzeitig ausgeführt wird.
Aber D&P will ( zumindest lt. Posting - aber da er in die TBTCP schauen will, meint er evtl. tatsächlich das, was ihr ihm vorschlagt ) verhindern, dass ein JOB 2x gleichzeitig ausgeführt wird, welcher theoretisch sogar mehrere Steps enthalten könnte.

@D&P: Wenn du tatsächlich den Mehrfachstart eines JOBS mit mehreren Steps unterbinden willst schreib mich mal via PM an, da das etwas aufwändiger ist, wenn es nachher "schön" aussehen soll.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von DeathAndPain (Top Expert / 1579 / 182 / 345 ) »
Tatsächlich meinte ich ein Programm. Wobei ich nach meinem Verständnis nicht in der TBTCO, sondern nur in der TBTCP die Information finde, in welchem Job dieses Programm gestartet ist (egal in welchem Step des betreffenden Jobs). In der TBTCO wiederum habe ich einen Index auf das Startdatum und kann so die Suche auf alle Jobs beschränken, die heute gestartet worden sind und noch laufen.

Erst mal vielen Dank an alle. Ein Sperrobjekt ist für mich nicht erste Wahl, weil ich mir die Option offen halten möchte, im Einzelfall den Job parallel im Vordergrund zu starten. Klar könnte man das über Prüfung von SY-BATCH regeln, aber das eigentliche Kriterium zu prüfen, nämlich ob ein entsprechender Jobstep gerade läuft, sagt mir mehr zu als ein indirekter Weg über Sperrobjekt.

@black_adept: Danke für den Hinweis auf den FB GET_JOB_RUNTIME_INFO. Ich habe mal reingeschaut und sehe darin einen direkten CALL 'GetRuntimeInfo'. Du weißt nicht zufällig, worin sich dieser von den Einträgen in TBTCO und TBTCP unterscheidet? Kann es sein, dass ein Job aktiv ist, ohne dass dies mit entsprechendem Step in der TBTCP steht? Ansonsten hätte ich nämlich einfach gesagt:

Code: Alles auswählen.

  SELECT SINGLE COUNT(*) FROM TBTCO
    JOIN TBTCP ON TBTCP~JOBNAME = TBTCO~JOBNAME
              AND TBTCP~JOBCOUNT = TBTCO~JOBCOUNT
   WHERE STRTDATE = SY-DATUM " Index TBTCO~8 nutzen: Nur Jobs, die heute gestartet wurden
     AND TBTCP~STATUS = 'R'
     AND TBTCP~PROGNAME = SY-REPID.
Und dann den SY-SUBRC checken (Hinweis für Unkundige: Auch wenn man es nicht erwarten sollte, setzt COUNT(*) den SY-SUBRC). Wäre das nicht genauso gut und einfacher als der Funktionsbausteinaufruf mit nachfolgendem Zugriff auf die TBTCO?

Wenn ich noch weiter drüber nachdenke, frage ich mich, ob ich die TBTCO überhaupt benötige. Ich könnte doch einfach sagen:

Code: Alles auswählen.

  SELECT SINGLE COUNT(*) FROM TBTCP
   WHERE PROGNAME = SY-REPID " Index TBTCP~1 nutzen: Nur Jobs mit diesem Programm im Step
     AND STATUS = 'R'.
Dann würde er eventuell sequentiell durch eine längere Liste von Logs dieses Jobs rasen, weil ich keine Einschränkung auf den Tag habe, aber dafür würde ich mir den JOIN sparen. Bin nicht sicher, welche der beiden Varianten performanter ist.

Gibt es einen Grund, weshalb ich stattdessen den Funktionsbaustein nutzen und erst danach in die TBTCO gehen sollte?

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von a-dead-trousers (Top Expert / 3776 / 143 / 984 ) »
Der GET_JOB_RUNTIME_INFO ist dazu da um den aktuellen Jobnamen zu ermitteln. Einfach um die Ergebnismenge zu verkleinern. Wenn du mit dem Programmnamen auch zurecht kommst, kannst du dir den Funktionsbaustein sparen.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.

ECC: 6.07
Basis: 7.40

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von black_adept (Top Expert / 3648 / 77 / 748 ) »
@D&P: Mein Coding ist aus einem bei uns produktiven "Vorschaltstep" übernommen, bei dem wir für diverse Jobs ein paar zusätzliche Startbedingungen als die von SAP zur Verfügung gestellten abprüfen wollen, um dann evtl. den Job nicht ausführen zu wollen ( z.B. Job darf nicht parallel laufen, Job darf in nur Mittwochs, Donnerstags und Samstag laufen o.ä. ) . Da dieser Vorschaltstep generisch ist wird der von dir angefragte FuBa eigentlich nur für die Ermittlung des JOBNAMEns benötigt.
Und zu deiner allgemeineren Frage worin er sich unterscheidet: Wenn mehrere Jobs tatsächlich gleichzeitig laufen, kannst du in der TBTCO und TBTCP nicht mehr unterscheiden welches der Job ist, in dem dein Programm läuft. Aber der Kernel weiß welcher Jobcount dazu gehört und gibt dir das zurück.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von DeathAndPain (Top Expert / 1579 / 182 / 345 ) »
Warum nicht? Ich sehe doch in TBTCP-PROGNAME den Namen des Reports, der in dem Step ausgeführt wird und brauche dann nur den Status zu prüfen. Dort finde ich dann auch JOBNAME und JOBCOUNT dazu. Wobei ich seltsamerweise hier auf dem System Jobs habe, die beendet sind, bei denen der STATUS in der TBTCP aber dennoch immer noch auf 'R' steht. In der TBTCO stimmt der Status, und tatsächlich läuft der Prozess auch nicht mehr (SM50). Sehr seltsam... man kann sich auf TBTCP-STATUS demnach nicht verlassen.

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von DeathAndPain (Top Expert / 1579 / 182 / 345 ) »
Ah, jetzt habe ich verstanden, was Du meinst. Das laufende Programm ist ja selber ein Hintergrundjob und soll sich ja nicht selbst finden, sondern nur herausfinden, ob es noch ein anderes gibt. Aber dennoch müsste der Code nach meinem Verständnis dann wie folgt lauten:

Code: Alles auswählen.

  CALL FUNCTION 'GET_JOB_RUNTIME_INFO'
    IMPORTING
      JOBCOUNT        = CURRENT_JOB-JOBCOUNT
      JOBNAME         = CURRENT_JOB-JOBNAME
    EXCEPTIONS
      NO_RUNTIME_INFO = 1
      OTHERS          = 2.

  SELECT SINGLE COUNT(*) FROM TBTCO
    JOIN TBTCP ON TBTCP~JOBNAME = TBTCO~JOBNAME
              AND TBTCP~JOBCOUNT = TBTCO~JOBCOUNT
   WHERE TBTCO~STATUS = 'R' " Index TBTCO~7 nutzen: Nur laufende Jobs
     AND TBTCP~PROGNAME = SY-REPID
     AND (    TBTCP~JOBNAME <> CURRENT_JOB-JOBNAME
           OR TBTCP~JOBCOUNT <> CURRENT_JOB-JOBCOUNT )
Mit Deiner Version

Code: Alles auswählen.

jobname   = @ls_this_job-jobname
würdest Du nach meinem Dafürhalten auf die Nase fallen, sobald jemand denselben Report unter einem anderen Jobnamen einplant. Jobnamen sind ja Schall und Rauch; interessant ist doch nur der Reportname in der TBTCP.

Re: Wiederkehrender Job mit spätester Ausführungszeit

Beitrag von black_adept (Top Expert / 3648 / 77 / 748 ) »
@D&P: Keine Angst - das ist bei uns so gewollt und seit ca. 10 Jahren produktiv. Wir fallen deshalb nicht auf die Nase, weil tatsächlich nach dem gleichen JOBNAMEN geschaut wird, da es z.B. durchaus ok ist, dass der gleiche Report mit unterschiedlichen Varianten parallel laufen darf, aber dass der gleiche Report nicht mit der gleichen Variante laufen soll. Sind halt meist Hintergrundsachen, wo wir nicht sicher sein können, dass bis zum nächsten Jobstart tatsächlich alles abgearbeitet wurde - insbesondere wenn der Job aus mehreren Steps besteht, von denen einer evtl. einen Engpass darstellt und der auch (weil SAP-Standardprogramm ) nicht wirklich beschleunigt werden kann. Und wenn einer der (periodischen) Jobs z.B. noch nicht fertig ist, wird dann der Nachfolgejob direkt beendet und plant sich halt zum dann folgenden Zeitpunkt ein und hofft, dass der erste Job dann endlich zu Potte gekommen ist.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Seite 1 von 1