Wiederkehrender Job mit spätester Ausführungszeit
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
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?
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?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Moin D&P,
musst du selber machen - etwa so:
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
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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.18
Basis: 7.50
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.18
Basis: 7.50
... so haben wir das auch gelöst:
Aufruf mit iv_report = sy-repid.
Zum Abschluss noch:
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.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.
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
@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.
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.
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
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:
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:
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?
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.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'.Gibt es einen Grund, weshalb ich stattdessen den Funktionsbaustein nutzen und erst danach in die TBTCO gehen sollte?
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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.18
Basis: 7.50
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.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
@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.
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.
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
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.
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
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:
Mit Deiner Version
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.
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 )Code: Alles auswählen.
jobname = @ls_this_job-jobname
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
@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.
Seite 1 von 1
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10024
vor 7 Stunden von ralf.wenzel 104 / 10024
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 7 Stunden von ralf.wenzel 104 / 10024
vor 7 Stunden von ralf.wenzel 104 / 10024