DTAQ startet nicht

[Daniela]

Hallo allerseits,

mein Programm1 wartet auf Daten in der DTAQ (Parameter wait = -1) und wird über eine Batchdatei mit dem Befehl „rmtcmd call pgm(Programm1)“ gestartet. Nun starte ich mein 2tes Programm mit dem Befehl call pgm(Programm2) das die Daten in die DTAQ reinstellt. Doch erst nach dem ich das Programm2 erneut starte funktioniert mein Batchdatei. Was ist falsch?
Wenn ich nun beim Parameter length bewusst einen falschen Wert eingegeben habe und mein Programm1 auf die Daten wartet, startet meine Batchdatei nicht. Das ist ja auch richtig, aber jeder Versuch mit einem falschem Wert erfordert anschließend wenn der Parameter length wieder richtig ist, das starten des Programm2. Das heißt, mein Programm2 muß derzeit 2 Mal gestartet werden, dass es funktioniert und bei 3 Fehlversuchen 3 weitere Mal.

Gruß Daniela

[kuempi von stein]

Sehr verwirrend.
Kannst du da mal ein mehr konkretes Beispiel geben?

Und mir ist nicht klar, warum man die Länge falsch angeben sollte?
Das ist doch nur die Maximale (Feld)Länge, mit der Du auch die DTAQ erstellt hast?
Wieviel Daten (Zeichen) da in dem Satz wirklich drin sind, ist doch egal?

k.

[Daniela]

Zum besseren Verständnis habe ich hier mal meine 2 Programme dargestellt. Wenn ich nun im Programm1 bei LEN als Wert Inz(21) angebe und im Programm2 DCL VAR(&LANG1) TYPE(*DEC) LEN(5 0) VALUE(21) angebe funktioniert mein Programm nicht. So war das gemeint, mit dem falschen Wert.

Dieses Programm wird per Batchdatei mit dem Befehl rmtcmd call pgm(Programm1)vom PC aus gestartet.

D Que s 10 Inz('DTAQSTEINL')
D Lib s 10 Inz('STAR')
D Len s 5 0 Inz(5)
D Wait s 5 0 Inz(-1)
D Data DS 50

C DoU *InLr
C Call 'QRCVDTAQ'
C Parm Que
C Parm Lib
C Parm Len
C Parm Data
C Parm Wait

C Select
C When Data = 'START'
C Leave

C EndSl

C EndDo

C Eval *InLr = *On


Programm2 starte ich mit dem Befehl call pgm(Programm2) nach dem das Programm1 per Batch gestartet wurde.

PGM

DCL VAR(&LANG1) TYPE(*DEC) LEN(5 0) VALUE(5)
DCL VAR(&TEXT1) TYPE(*CHAR) LEN(5) VALUE('START')

CALL PGM(QSNDDTAQ) PARM(DTAQSTEINL STAR &LANG1 &TEXT1)

ENDPGM

[Fuerchau]

Beim QRCVDTAQ musst du die maximal erwartete Länge, also die Länge der DTAQ angeben.
Anschließend überschreibt der QRCVDTAQ den Wert mit der empfangenen Länge.
Der Rest des Puffers ist dann undefiniert (ggf. mit Blanks gefüllt).
Du kannst den empfangenen Wert dann per %SUBST bzw. SUBST-Befehl auslesen.
Vor dem QRCVDTAQ musst du dann natürlich die Länge wieder neu füllen !

[Pikachu]

Probier's mal so:

...

If Len > 0

Select
When %Subst(Data:1:Len) = 'START'
Leave

EndSl

EndIf

...

[Daniela]

Vielen Dank für die guten Tips !!! - Habe sie alle angewendet. Die Ursache weshalb ich mein Programm2 nach den Fehlversuchen mehrfach bzw. generell 2mal starten musste, liegt darin, daß diese abgebrochenen Jobs immer noch im Hintergrund laufen. Jetzt kämpfe ich noch mit dem Problem, daß sich diese Jobs (Mehrfach vorhandene Jobs gefunden) weder mit ENDJOB noch mit ENDJOBABN beenden lassen. Vielleicht weiß mir zu diesem Problem noch jemand eine andere Lösung ausser PWRDWNSYS.

Gruß Daniela

[kuempi von stein]

.....weder mit ENDJOB noch mit ENDJOBABN beenden lassen. Vielleicht weiß mir zu diesem Problem noch jemand eine andere Lösung ausser PWRDWNSYS.
...

Der nächste logische Schritt wäre glaube ich ENDSBS....
Aber wenn so ein Job erst mal hartnäckig im System kleben bleibt, ist Ursachenforschung angesagt.

kuempi

[Fuerchau]

Wenn ENDJOBABN auch nicht mehr hilft, kommt auch ein ENDSBS hier nicht weiter.
Ein PWRDWNSYS ist dann leider erforderlich.

Noch ein Tipp:
An Stelle mit -1 zu warten, solltest du eine Zeit einstellen und den END-Status des Jobs prüfen (per CLP mit RTVJOBA ENDSTS) um das Programm ggf. normal zu beenden.

PS:
Versuche mal die DTAQ zu killen.

[Pikachu]

Jetzt kämpfe ich noch mit dem Problem, daß sich diese Jobs (Mehrfach vorhandene Jobs gefunden) weder mit ENDJOB noch mit ENDJOBABN beenden lassen.
Ein ENDJOBABN geht erst 10 Minuten nach einem ENDJOB OPTION(*IMMED).