Hallo, es gibt ein bereits bestehendes Programm welches einzelne Jobs öffnet, ein Programm submitted, und den Job wieder schliesst. Am Ende gibt es dann n-Jobs, die erzeugt wurden, bis alles abgearbeitet ist.
Am Ende wird via den Bausteinen BP_JOB_SELECT und BP_JOBLIST_PROCESSOR_SM37B eine Listübersicht für die Jobübersicht gedruckt/angezeigt.
Wird aber das Prgramm im Hintergrund eingeplant und nicht online ausgeführt, bleibt es im letzten Step hängen. Die Funktion BP_JOBLIST_PROCESSOR_SM37B wird angefahren, und kommt nicht mehr zurück. Ausserdem wird anscheinend im Hintergrund da noch eine Tabelle gefüllt, und irgendwann git es einen Speicherüberlauf. Das Thema ist jetzt bei mir gelandet...so richtig habe ich keinen Ansatz. Gut, ich könnte SY-Batch abfragen, und diese BP_JOBLIST_PROCESSOR_SM37B dann unterdrücken. Dann ist aber wohl der Spool leer...
Angefahren wird der Baustein mit joblist_opcode = '22' (das ist quasi: zeige Jobliste an). Wie bekomme ich die Liste einfach in den Spool ohne Abbruch?
LG
Es gibt den Fubas JOB_OPEN, womit du einen Job erstellst. Dieser liefert dir eine Jobnummer zurück. Mit der Nummer und den Namen des Jobs setzt du den SUBMIT Befehl für das Programm ab (hier aus meiner Methode kopiert)
SUBMIT (i_report)
WITH SELECTION-TABLE i_rsparams
VIA JOB i_name
NUMBER i_number
AND RETURN.
Dann startet du mit dem Fuba JOB_SUBMIT den Job. Mit JOB_CLOSE wird es wieder geschlossen.
ANSCHLIEßEND (nach JOB_CLOSE läuft der Job noch): Lesen ich mit dem Fuba BP_JOB_READ, ob der Job noch läuft (Exp-Parameter: job_read_jobhead-status)*.
Abschließend kann man mit BP_JOBLOG_READ auf Fehler prüfen.
--
*Im Grund habe ich für meinen Fall ein Programm (Report), welches im Hintergrund gestartet werden muss. Als FrontEnde habe ich ein Webdynpro, bei dem der Anwender auf das Ende des Jobs warten soll. Durch den Job und den Meldungen im Joblog werden mögliche Dumps verhindert, die u.U. durch Dypro-Befehle ausgelöst werden.
Hallo danke für die Antwort, aber hilft mir nicht so richtig.
Sagen wir es so: Programm A startet mehrere andere Jobs 1-n, und schliesst die auch. Die laufen z.T. mehrere 1000 Sekunden. Sind Rückrechnungen. Und je nachdem, kann das pro Mitarbeiter auch mal einige Minuten dauern. Das funktioniert auch korrekt.
Am Ende des Hintergrundjobs steht ja wieder Programm A, im logischen Ablauf das letzte Programm der Kette. Und genau das bleibt hängen, wenn quasi die Jobliste angedruckt wird-aber nur in der Hintergrundverarbeitung, nicht online am Bildschirm. Aber wenn die User das starten, wollen die ja irgendwann nach Hause gehen, und nicht warten, bis Programm A fertig ist. Daher nimmt man ja die Hintergrundausführung, nachdem man auf dem Selektionsbild die entsprechenden passenden Eingaben gemacht hat. Aber wie gesagt, der letzte Step hängt sich immer auf, und schreibt dann noch den Speicher voll, so das die Basis das Ding irgendwann canceln muss.