verschiedene Jobs gleiche Datei, schreib / lese konflikt?

[dibe]

Ok, das ist schlecht
Das erste Pgm schreibt die Sätze (1-n)
Das 2. ergänzt sie (Update)
das 3. macht die letzte Verarbeitung und muß nur die passenden lesen

Also
1. Pgm mit feod?
2. Pgm muß dann eine eigene Datei mit feod schreiben? oder gibt es eine Möglichkeit in Update?

Danke nochmal!

[hel400]

:-)

Der Hintergrund ist ganz einfach der, dass ("normalerweise", also wenn man an den Standardparametern nichts ändert) die Sätze bei OUTPUT immer nur BLOCKWEISE ausgegeben werden. Das System wartet also, bis mehrere Sätze da sind und gibt dann alle gleichzeitig aus.

Das bedeutet aber, dass ein einzelner Satz nach dem WRITE für alle anderen Jobs noch nicht sichtbar ist(!!).
Daher macht man dann ein FEOD und der neue Satz wird sofort "auf Platte geschrieben" (wobei das immer noch nicht physisch sein muss, aber der Controller hat das Ding schon mal für "alle" zur Verfügung).

An der restlichen Verarbeitung und für die anderen Programme ändert sich aber absolut nichts!
Einfach nach dem WRITE ein FEOD und fertig.
READs und UPDATEs bleiben unverändert.

[dibe]

ja, das Prinzip ist mir schon klar.

Ich dachte nur, das System würde merken, das der Satz der da gerade gelesen werden soll nicht aktuell ist und dann den aktuellen 'von wo auch immer' zur Verfügung zu stellen.
Wir haben in keinem Pgm Probleme, das ggf ein alter Satz verarbeitet wird.
Daher habe ich den Einwand nicht verstanden, wir müssten mit Feod arbeiten.

Und wenn es keinen adäquaten Befehl für den Update gibt, MUSS ich doch davon ausgehen, das das vom System gehändelt wird.

Die Frage ging mehr in die Richtung: Kann es sein, das ich bei o.g workflow 'alte' Daten verarbeite oder nicht!?

Danke
DiBe

[hel400]

Du denkst noch falschherum :-)

Es kann NICHT sein, dass irgendein Pgm. "alte" Daten verarbeitet, weil bei einem UPDATE besteht das beschriebene Problem gar nicht!

Es ist ausschließlich bei einem WRITE (also NEUER Satz).
Dieser steht für andere Jobs "evtl" noch nicht zur Verfügung.

Daher nochmals: Nach einem WRITE ein FEOD
(nicht bei update erforderlich!)

[dibe]

OK danke

also beim Update nicht nötig,
das hatte ich gehoft

Danke!
Dietlinde Beck

[Fuerchau]

Das FEOD lässt sich auch per Definition verhindern denn nicht das System sorgt für das Blocken sondern die RPG-Runtime (interne Routinen im Programm).
Wenn du die Datei als UF-Datei mit Append definierst wird nicht geblockt.
Bei OPM-RPG muss man halt ein paar IO's in einer blinden BEGSR definieren damit der Compiler zufrieden ist, in ILERPG ist das nicht mehr nötig.
Ansonsten gibt es irgendwo NOBLOCK-Optionen.

Was deine DTAQ-Verarbeitung angeht so kann man per DTAQ auch (wenn es die Anwendung erlaubt) die Daten quasi-parallel verarbeiten.
Die DTAQ wird ja nach FIFO verarbeitet. Wenn also mehrere Jobs auf der selben DTAQ "horchen" werden sie abwechslend beim Eintreffen eines Satzes gestartet.
D.h., du kannst per Prestart-Job in einem SBS z.B. 3 Programme starten die eben je nach Auftreten der Daten fast parallel arbeiten können. Dies kannst du natürlich auch mit allen 3 Programmen machen.
Somit spart man sich ggf. die Programminitialisierungen (Open, Parameter laden, interne Tabellen laden usw.).

[B.Hauser]

Ansonsten gibt es irgendwo NOBLOCK-Optionen.

... und was ist mit dem Schlüssel-Wort BLOCK(*NO), das in den F-Bestimmungen angegeben werden kann?

[B.Hauser]

Die DTAQ wird ja nach FIFO verarbeitet.

DataQueues können auch geschlüsselt angelegt werden, dann erfolgt die Verarbeitung in Schlüssel-Folge, die nicht mehr zwangsläufig FIFO ist.

[Fuerchau]

Da die Schlüssel aber nicht UNIQUE sind werden die Schlüssel weiterhin nach Fifo abgerufen.
Schlüssel verwende ich meist nur für Jobtrennungen.

Ich habe ja ansonsten mit NOBLOCK, also nicht Blocken hingewiesen und "irgendwo" gesagt.
BLOCK(*NO) gibts ja nur bei ILE und nicht bei OPM.