refresh DSPLF via DTAQ

[LSMD]

Guten Tag

Ich möchte eine Autorefresh Subfile Programmieren. Ich hab dazu wie immer google benutzt. Nun hab ich mir selber was zusammen geschrieben wobei ich von folgender These ausgehe:

Wenn 2 Jobs die gleiche dtaq auslesen nehmen sie sich gegenseitig die Datensätze weg, deshalb muss erst geprüft werden welchem Job der Datensatz zugeordnet werden muss ehe dieser gelöscht werden darf.

Nun geb ich dem Rcvdtaq '*NO ' mit. Das Resultat ist das der Job auf evtw steht und sich nur noch mit *IMMED beenden lässt.

Wo ist der Fehler?

p my_exfmt b
d my_exfmt pi
d s_dtaQMsgSize s 5 0
d ds_dQM DS
d a_dta_typ 10A
d a_dta_unb 2A
d a_dta_dsp 10A
d a_dta_lib 10A
d a_dta_job 10A
d s_lenOfKeyDat s 3 0
d a_KeyDta s 256A
d s_lenOfSndInf s 3 0 Inz(50)
d a_SndInf s 1024A
d s_SODR s 5 0 Inz(42)
d a_Error s 1024A
/Free
write SFLCTRL1;
DoW a_dta_job<>curjob and a_dta_typ<>c_refresh;
RcvDtaQ(c_dtaq:c_lib:s_dtaQMsgSize:ds_dQM:*HIVAL:
'':s_LenOfKeyDat:a_keyDta:s_lenOfSndInf:a_SndInf
:'*NO ':s_SODR:a_Error);
EndDo;
If a_dta_job=curjob;
RcvDtaQ(c_dtaq:c_lib:s_dtaQMsgSize:ds_dQM:*HIVAL:
'':s_LenOfKeyDat:a_keyDta:s_lenOfSndInf:a_SndInf
:'*YES':s_SODR:a_Error);
EndIf;
read SFLCTRL1;
/End-Free
p my_exfmt e

[Fuerchau]

Dann nimm doch eine *Keyd-DTAQ, in der der Key dem Job entspricht.
Dann kann jeder seine Daten mit Löschen lesen.
Zusätzlich solltest du einen Timeout (nicht *HIVAL) angeben, so dass der Job nicht blockt.

[LSMD]

Auf die Idee kam ich auch schon, nur wie kann ich spezifizieren welchen key die Datensätze haben die über die DSPF reinkommen?

CRTDSPF FILE(TST/SFD) +
SRCFILE(TST/QDDSFSRC) +
SRCMBR(TSTSFD) DFRWRT(*NO) +
DTAQ(TST/DTQ)

mehr ist da nicht

[Fuerchau]

Ich dachte, du bekommst auch noch von anderen Jobs Nachrichten.
Wenn das nicht der Fall ist, dann erstelle doch per CLP vorher in der QTEMP eine DTAQ und mach einen OVRDSPF bevor du das Programm startest. Dann gibts das Problem nicht.

[LSMD]

ne ich bekomme sowohl daten über die dspf rein als auch über ein Programm das Triggert ob sich an der Datengrundlage was ändert.



Wenn der User "schuss drückt" bekommt die DTAQ einen vom System erzeugten Datensatz. Den generiere nicht ich. Wenn sich irgendetwas in der datenbank ändert wird per Trigger in die DTAQ auch ein datensatz reingeschrieben. Ersteren erzeuge nicht ich... selbst wenn der DSPF Datensatz der DTAQ einen Key hat weiß ich nicht wie der aussieht, da ich bisher noch kein Anständiges Beispiel dafür gefunden hab.

[Fuerchau]

In diesem Fall würde ich mit 2 DTAQ's arbeiten.
1 in QTEMP für die DSPF, eine 2. Keyed-DTAQ (Schlüssel ggf. Job-Nr.) für den Empfang anderer Nachrichten.

Die DSPF-DTAQ mit Timeout=0 lesen, die andere mit 1.

Wenn Dir das zu aufwändig wird, dann halt mit Timeout und *NO lesen, wenn die Nachricht dann passt, ohne Timeout mit *YES lesen zum Löschen.
Allerdings wirst du dann ggf. Synchronisationsproblme zwischen den Jobs bekommen.

Alternativ kann man auch ein kleines Batch-Programm benutzen, dass die DSPF-OUTQ (jetzt nicht QTEMP) an die Keyd-DTAQ mit der Job-Nr. weiterleitet.

[LSMD]

Tatsächlich hat der RcvDtaQ mit "*NO" und *HIVAL probleme verursacht und verhält sich anders als mit "*YES" und *HIVAL. Statt *HIVAL 0 einzugeben war die Lösung des Problems und 0 verhält sich genauso wie es *HIVAL tun sollte.


Vielen Vielen Dank

[Fuerchau]

Bedenke:
Wenn du immer mit Timeout 0 arbeitest erzeugst du sehr schnell sehr hohe Prozessorlast.
Versuche es wenigsten bei *NO mit Timeout 1.