CL: Kann man Status eines Jobs abfragen?

[Fuerchau]

In CL gibt es leider keinen CLOSE !
Die einzige Möglichkeit ist das Beenden des CL's.

Hierzu gibt es 2 Möglichkeiten:
1. ENDPGM/RETURN
2. TFRCTL

Zu 1: Dies ist sichherlich nicht gewünscht, aber man kann ja obigen Vorschlag aufnehmen, d.h., die Abfrage der Spoolfile in einem Unterprogramm durchzuführen. Wenn das Unterprogramm beendet wird, wird auch die Datei geschlossen.

zu 2: TFRCTL entspricht im wesentlichen dem CALL-Befehl, was aber das Beenden des eigenen Programmes zur Folge hat, d.h., die Datei wird geschlossen !

Warum kannst du TFRCTL nicht verwenden ?

[hs]

Nochmals vielen Dank für eure Unterstützung.

Ich habe herausgefunden, dass die Datei Offensichtlich automatisch geschlossen wird, wenn ich über den letzten Satz hinauslese.

Deshalb kann ich jetzt alles in einem CL erschlagen:

PGM
/* VARIABLEN*/
DCL VAR(&JOBNR) TYPE(*CHAR) LEN(10)
DCL VAR(&JOB) TYPE(*CHAR) LEN(10)
DCL VAR(&STATUS) TYPE(*CHAR) LEN(10)
DCL VAR(&WARTEN) TYPE(*DEC)
DCLF FILE(QTEMP/WAOUTPUT)
/* FESTSTELLEN, OB der JOB LÄUFT */
START: RTVJOBA JOB(&JOB) NBR(&JOBNR) PRTDEV(&DRUCKER)
WRKACTJOB OUTPUT(*PRINT) SBS(MEINSBS)
CRTPF FILE(QTEMP/WAOUTPUT) RCDLEN(150)
CPYSPLF FILE(QPDSPAJB) TOFILE(QTEMP/WAOUTPUT) +
JOB(&JOBNR/*N/&JOB) SPLNBR(*LAST)
DLTSPLF FILE(QPDSPAJB) JOB(&JOBNR/*N/&JOB) +
SPLNBR(*LAST)
CHGVAR VAR(&WARTEN) VALUE(0) /* STARTWERT */
/* JETZT LESEN BIS DATEIENDE UND JOB SUCHEN */
READ: RCVF /* SATZ LESEN*/
MONMSG MSGID(CPF0864) EXEC(GOTO ENDE)
/*VERLASSEN, WENN DATEIENDE ERRREICHT*/
CHGVAR VAR(&JOB) VALUE(%SST(&WAOUTPUT 4 10))
CHGVAR VAR(&STATUS) VALUE(%SST(&WAOUTPUT 111 3))
IF COND(&JOB = 'MEINJOB' *AND &STATUS = +
'RUN') THEN(CHGVAR VAR(&WARTEN) VALUE(1))
GOTO READ /* NÄCHSTEN SATZ LESEN */
/* WURDE DER JOB MIT STATUS RUN GEFUNDEN ? */
ENDE: DLTF FILE(QTEMP/WAOUTPUT)
IF COND(&WARTEN = 1) THEN(DO)
DLYJOB DLY(60)
GOTO START
ENDDO
ENDPGM


Gruß
HS

[Dieser Beitrag wurde von hs am 23. Januar 2003 editiert.]

[B.Hauser]

Statt GOTO START hätte man auch einen erneuten CALL auf das Programm machen und das laufende Programm beenden können.
Bei dieser Lösung ist auch ganz sicher, dass die Datei geschlossen wurde und von vorne verarbeitet wird.

Birgitta

[Bodo Roggenkamp]

Hallo Hs,

nun warst Du etwas schneller. Wollte Dir gerade anbieten, Dir via Mail ein Test_CL_PGM zu schicken. Es ist sehr wohl möglich, eine permanent existierende Datei innerhalb eines CL's auszulesen und vor dem EOF die Datenbankdatei erneut auf den Anfang der Datei zu positionieren. Wenn noch Bedarf besteht, E-Mail bekannt geben.

Gruss
Bodo

[jajonowak]

hallo hs,
da die arbeitsdatei sowieso in der qtemp steht, würde ich der crtpf vorverlegen und anstelle des dltpf würde ich ein clrpfm ensetzen (os400 braucht dann nicht schon wieder tabellen verwalten)

[Fuerchau]

Es ist leider nicht sichergestellt, dass die Datei nach einem CPF0864 beim RCVF tatsächlich geschlossen ist !
Beim nächsten Release oder PTF kann dieser "Fehler" behoben sein, da in CL definiert ist, dass eine Datei nur 1 Mal verarbeitet werden kann !
Warum kannst du dann nicht nach dem DLYJOB einen TFRCTL verwenden ?

Anmerkung: Das Abfragen des eigenen Jobs ist nicht nötig, da beim CPYSPLF ... JOB(*) immer der eigene Job gemeint ist.

[hs]

Ich habe es versucht mit TFRCTL.

Ging aber nicht, da die Datei in der QTEMP nicht gelöscht wurde.

Und löschen kann ich sie ja im CL nicht, da sie noch in Benutzung durch den RCFT ist, wenn ich nicht bis über den letzten Satz lese.

Eventuell ist dieser Fehler erst in neueren Releases, bei unserem 3.7 jedenfalls scheint es zu funktionieren.

Und auf PTF brauche ich wohl auch nicht mehr zu hoffen :-)

Gruß
HS

[rolf]

Hallo zusammen.
Also im CL gibt es sehr wohl den Befehl Close um eine Datenbankdatei zu schliessen.
Der Befehl zum Schliessen heisst "CLOF" und der zum Oeffnen "OPNDBF".
Wenn ich eine geöffnete Datei neu positionieren will, gibt es den Befehl "POSDBF".
Ich brauche also kein TFRCTL oder anderes.
Gruss
Rolf

[Bodo Roggenkamp]

Hallo Rolf,

so ist es. Das es möglich ist, habe ich ja bereits geantwortet. Trotzdem wird von einigen das Gegenteil behauptet. Warum nur? Weil sie es nicht besser wissen?
Wenn in einigen Beiträgen behauptet wird, im CL kann eine Datei mehrfach ausgelesen werden, dann muss man doch davon ausgehen, das dem so ist und die Leute auch schon damit gearbeitet haben. Und doch wird stur etwas anderes behauptet.
Schon merkwürdig...

Gruss
Bodo

[schreibr]

Vielleicht liegt es aber auch am fehlenden Verständnis, dass hier unterschiedliche Meinungen herrschen.
Das Lesen einer Datei im CL läuft mit RCVF. Um das Dateiende festzustellen wird auf MONMSG MSGID(CPF0864) abgefragt. Wenn diese MONMSG im CL erreicht wird, ist es definitiv nicht mehr möglich mit POSDBF OPNID(Datei) POSITION(*START) die Datei erneut zu lesen, da durch den letzten RCVF bereits der Dateizeiger im "Nirwana" steht.
Mit einem kleinen Trick kann man dies jedoch umgehen. Vor dem RCVF mit RTVMBRD FILE(Datei) NBRCURRCD(Variable) holt man sich die aktuelle Satzanzahl der zu lesenden Datei. In der RCVF-Schleife einen Zähler+1 mitlaufen lassen. VOR jedem erneutem RCVF den Zähler mit der NBRCURRCD(Variable) vergleichen - sind beide Werte identisch den POSDBF absetzen und der nächste RCVF führt nicht zur MONMSG(CPF0864) und damit geht der Dateizeiger nicht ins "Nirwana".

Gruss Reinhold

[hs]

Also nochmals vielen Dank an alle, die mir bei der Erstellung des CL geholfen haben

Ich versuche die Diskussion jetzt mal abzuschliessen.

Das CL funktioniert mittlerweile einwandfrei, habe auch noch ein paar Finessen eingebaut.

Ich hatte beim testen nämlich festgestellt, dass der Job - wenn er läuft - nicht immer nur den Status RUN hat, sondern auch z.B. LCKW, wenn er auf eine Sperre wartet.

Deshalb habe ich noch eingebaut, dass das CL solange wartet, bis der Job einen bestimmten Status angenommen hat, z.B. DLYW.

Hier das fertige CL:

PGM PARM(&JOBNAME &SBSNAME &BEDINGUNG &JOBSTAT &WARTEZEIT)
/************************************************** *************************/
/* */
/* DIE PROZEDUR WARTET SOLANGE, BIS DER ÜBERGEBENE JOB EINEN */
/* BESTIMMTEN STATUS HAT BZW. NICHT MEHR HAT */
/* DANN WIRD DAS CL BEENDET. */
/* */
/* PARAMETER: */
/* - JOBNAME : WELCHER JOB SOLL GEPRÜFT WERDEN */
/* - SBSNAME : IN WELCHEM SUBSYSTEM */
/* - BEDINGUNG: EQ: CL WARTET SOLANGE, WIE JOB DIESEN STATUS HAT */
/* NE: CL WARTET SOLANGE, BIS JOB ANDEREN STATUS HAT */
/* - JOBSTAT : DER JOBSTATUS, DER ABGEPRFT WERDEN SOLL */
/* - WARTEZEIT: SOLANGE WARTEN BIS ERNEUTE PRÜFUNG ERFOLGT */
/************************************************** *************************/
/* VARIABLEN*/
DCL VAR(&DRUCKER) TYPE(*CHAR) LEN(10)
DCL VAR(&STATUS) TYPE(*CHAR) LEN(10)
DCL VAR(&WARTEN) TYPE(*DEC)
DCL VAR(&JOB) TYPE(*CHAR) LEN(10)
DCL VAR(&JOBNAME) TYPE(*CHAR) LEN(10)
DCL VAR(&SBSNAME) TYPE(*CHAR) LEN(10)
DCL VAR(&JOBSTAT) TYPE(*CHAR) LEN(5)
DCL VAR(&BEDINGUNG) TYPE(*CHAR) LEN(2)
DCL VAR(&WARTEZEIT) TYPE(*DEC)
DCLF FILE(QTEMP/WAOUTPUT)
/* AB HIER VERARBEITUNG */
CRTPF FILE(QTEMP/WAOUTPUT) RCDLEN(150)
RTVJOBA PRTDEV(&DRUCKER)
START: CHGJOB PRTDEV(OHNE) /* SOLL NICHT GEDRUCKT WERDEN */
WRKACTJOB OUTPUT(*PRINT) SBS(&SBSNAME)
CHGJOB PRTDEV(&DRUCKER)
CPYSPLF FILE(QPDSPAJB) TOFILE(QTEMP/WAOUTPUT) JOB(*) +
SPLNBR(*LAST)
DLTSPLF FILE(QPDSPAJB) JOB(*) SPLNBR(*LAST)
CHGVAR VAR(&WARTEN) VALUE(0) /* STARTWERT */
/* JETZT LESEN BIS DATEIENDE UND JOB SUCHEN */
READ: RCVF /* SATZ LESEN*/
MONMSG MSGID(CPF0864) EXEC(GOTO WEITER)
/*VERLASSEN, WENN DATEIENDE ERRREICHT*/
CHGVAR VAR(&JOB) VALUE(%SST(&WAOUTPUT 4 10))
CHGVAR VAR(&STATUS) VALUE(%SST(&WAOUTPUT 111 4))
/* HANDELT ES SICH UM DEN GESUCHTEN JOB? */
IF COND(&JOB *EQ &JOBNAME) THEN(DO)
/* JETZT JE NACH BEDINGUNG DEN JOBSTATUS PRÜFEN */
IF COND(&BEDINGUNG *EQ 'EQ' *AND &STATUS *EQ &JOBSTAT) +
THEN(CHGVAR VAR(&WARTEN) VALUE(1))
IF COND(&BEDINGUNG *NE 'EQ' *AND &STATUS *NE &JOBSTAT) +
THEN(CHGVAR VAR(&WARTEN) VALUE(1))
ENDDO
GOTO READ /* NÄCHSTEN SATZ LESEN */
/* WURDE DER JOB MIT ENTSPRECHENDEM STATUS GEFUNDEN ? */
WEITER: IF COND(&WARTEN = 1) THEN(DO)
CLRPFM FILE(QTEMP/WAOUTPUT)
DLYJOB DLY(&WARTEZEIT)
GOTO START /* WIEDER VON VORN BEGINNEN */
ENDDO
ENDE:
DLTF FILE(QTEMP/WAOUTPUT)
ENDPGM

[Fuerchau]

Also:
OPNDBF eröffnet zwar eine Datei, aber nicht für das CLP !
Zusätzlich ist nämlich ein OVRDBF ... SHARE(*YES) erforderlich (bzw. CHGPF/LF ... SHARE(*YES)), damit beim Open (RPG/COBOL/...) die GLEICHE Datei noch einmal eröffnet wird.
Dies kann mann mittels DSPJOB, Auswahl 14 nämlich sehr schön sehen, dass die Datei dann ggf. 2 Mal eröffnet ist!

Unabhängig von OPNDBF, CL eröffnet die Datei mit einem eigenen ODP als INPUT !
D.h., POSDBF funktioniert nicht, da CL ja diese Datei gar nicht eröffnet.

Auch nach intensivem Test (V4R5, V5R1) konnte ich in einem CLP eine Datei NICHT 2 Mal lesen, beim 2.Versuch wurde sofort CPF0864 gemeldet und es wurde KEIN Satz verarbeitet.

Wenn man einen RCVF absetzt und die Datei nicht vorhanden ist, wird CPF4101 gemeldet (Datei nicht gefunden), ist die Datei beim 2. Durchlauf nicht vorhanden, wird aber CPF0864 gemeldet, als ob ich die Datei verarbeitet hätte !!!

@hs

Debugge mal dein Programm, ob du wirklich die Datei 2 Mal liest, laut CL-Definition ist dies WIRKLICH nicht möglich und ich habe es einfach nicht geschafft !!!

Und was den TFRCTL betrifft, hast du natürlich recht, dass ich die Datei bis zum Ende lesen muss, wenn ich sie löschen will.
Der TFRCTL schließt aber die Datei auch, wenn ich nicht bis zum Ende gelesen habe.
Ich kann also die Datei z.B. am Anfang des Programmes mittels DLTF und MONMSG löschen, falls sie existieren sollte.

@rolf

Die Befehle OPNDBF/CLOF/POSDBF wirken nur auf HLL-Programme, also RPG/COBOL usw.
Ein CLP ignoriert sogar SHARE(*YES) und eröffnet die Datei immer INPUT !
Ein mehrfaches Lesen ist definitiv NICHT möglich !