verschiedene Jobs gleiche Datei, schreib / lese konflikt?

[dibe]

Guten Morgen
wir haben 3 Pgmme, die alle die selbe Datei lesen / updaten / schreiben.
Bisher immer komplett von Anfang bis Ende. Die Programme machen unterschiedliche Auswertungen und bereiten andere Daten auf. Sie laufen bisher an verschiedenen Tagen.
Eine neue Anforderung erfordert nun, das das sehr Zeitnah geschieht.
Die Überlegung: Alle 3 Pgmme werden, unabhängig von einander, mit einem Parameter submittet, der sie veranlasst auf eine dataq zu lauschen. Dort stellen wir den Basis-Key des benötigten Satzes rein. Ist Pgm1 fertig schreibt es die dataq für Pgm2 und verarbeitet den nächsten Dataq Satz. Pgm2 macht das für Pgm3. So könnte diese sehr zeitkritische Job parallel laufen.
Nun sagte ein Kollege das ginge nicht, oder nur, wenn wir mit FEOD die Daten tatsächlich in die Datei zurück schreiben, was das ganze wieder verlangsamt.
Hat er recht?
PS: ein Umbau der Pgmme, die Daten per Parameter aus zu tauschen geht aufgrund der Datenkonstellation nicht. (es sind 1-n Sätze betroffen, jedes Pgm verwendet in Abhängigkeit von internen Kriterien einen dieser Sätze)

Vielen Dank
Dietlinde Beck

[Fuerchau]

FEOD verlangsamt gar nichts, denn damit wird nur der Puffer an das OS übergeben. Wann das OS dann mal tatsächlich schreibt bleibt diesem seit jeher überlassen.
Wenn die Datei ungeblockt geschrieben wird, für Update geöffnet ist oder das Programm mit *INLR = *ON verlassen wird, ist FEOD sowieso wirkungslos. Die Runtime sorgt fürs schreiben.

Aber warum denn so kompliziert?
Sind die Programme Langläufer?
Ich würde ganz einfach ein CLP schreiben dass die 3 Programme nacheinander aufruft.
Wenn die dann mal jeweils nur ein paar Sekunden was tun ist das doch zeitnah genug.
Das CLP kann ja per DLYJOB warten und kreist dann um die CALL's.

[dibe]

Ich würde ganz einfach ein CLP schreiben dass die 3 Programme nacheinander aufruft.

So war die erste Version. Aber ...
Es werden ca 40.000 Sätze täglich verarbeitet
Wenn der Job nacheinander läuft und im Idealfall 2 Sekunden benötigt (das ist die durchschnittliche aktuelle Zahl für alle 3 Pgmme, bei einem Satz Daten)
sind das 80.000 Sekunden oder 1333 Minuten oder 22 Stunden und das ist zu lange, da die 40.000 Sätze in 8 Stunden entstehen!

Die Pgmme sollen in Schleife die Dataq's abhören, den/die Satz/Sätze bearbeiten, updaten und die dataq für das nächste Pgm schreiben.
Bedeutet die Antwort das es so gar nicht geht? auch nicht mit feod?

[hel400]

Doch, mit FEOD geht das schon (das schließt die obige Antwort ja auch nicht aus).

Was gemeint war, ist in Kurzform: FEOD wird nur bei OUTPUT-, nicht aber bei UPDATE benötigt.

[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.