View Full Version : After trigger liest 'sich selber'
@bender
Natürlich, weil ich keine Anwendung kenne die das auf 1 hat.
zu Wackelhaufen: kein Komentar
@Pikatchu
kein Commit
und
Normalerweise (innerhalb eines Jobs) funktioniert das
Wenn ein submitteter Job sofort den frischgeschriebenen Satz lesen will ist ein FEOD nötig.
Im Trigger Fall hat ich noch nie einen Wackehaufen programmiert
Robi
Hallo,
das Kriterium ist da wohl nicht der Job, sondern der offene Datenpfad (plus die Zufallskomponente, wann nun gerade die FRCRATIO voll ist) und da stützen sich zuweilen zwei schwankende Gestalten gegenseitig; wenn in einer Anwendung Dateien mit share(yes) geöffnet werden, dann funzt das, in dem Trigger kann man genau dies nicht sicherstellen und es funktioniert manchmal.
Mit Datenbank Verarbeitung haben aber solche Vorgehensweisen nix zu tun, auch wenn man das so oft sieht, dass es mancher für normal hält.
mfg
Dieter Bender
@bender
Natürlich, weil ich keine Anwendung kenne die das auf 1 hat.
zu Wackelhaufen: kein Komentar
@Pikatchu
kein Commit
und
Normalerweise (innerhalb eines Jobs) funktioniert das
Wenn ein submitteter Job sofort den frischgeschriebenen Satz lesen will ist ein FEOD nötig.
Im Trigger Fall hat ich noch nie einen Wackehaufen programmiert
Robi
Nur so am Rande:
FRCRATIO hat nix mit der Verfügbarkeit des Satzes zu tun, auch mit FRCRATIO <> 1 kann der Satz gelesen werden.
SEQONLY wird bei Update/Insert automatisch ausgeschaltet, wenn ein Update/Insert-Trigger definiert ist.
Gerade weil der Trigger ja jeden einzelnen Satz bearbeiten muss.
Anders siehts da bei Input-Dateien aus. Hier kann SEQONLY verwendet werden und somit im Puffer des Programmes ein ganzer Block vorhanden ist in dem der neu eingefügte Satz eben noch nicht enthalten ist.
Lösung:
Beim Erstellen der Programme Blockung für die Datei ausschalten.
SEQONLY(*NO) reicht da leider nicht, da dies das Blocken eben nicht verhindert.
Mit ODP's ist da etwas vorsichtiger umzugehen, da sonst aktuelle Lesezeiger verstellt werden können.
Hier kann man ggf. mit
OVRDBF ... SHARE(*YES)
OPNDBF ... *ALL
das Blocken verhindern. Allerdings können hier ggf. Satzsperren von untergeordneten PGM'en aufgehoben werden so dass nachfolgende Updates auf die nase fallen (Read fehlt).
Hallo,
wir sind uns doch erst mal einig, dass die nicht gefundenen Sätze sich in einem Buffer des Programmes befinden, das den Trigger gefeuert hat?!
- der Trigger weiß nicht wer ihn ausgelöst hat
- der Trigger kann nicht beeinflussen ob das auslösende Programm mit share oder ohne öffnet
- der Trigger kann nicht beeinflussen ob das auslösende Programm SEQONLY verarbeitet oder nicht
- der Trigger kann nicht beeinflussen ob das auslösende Programm Commit verwendet oder nicht und unter welchem Sperrlevel es arbeitet
- der Trigger soll unabhängig von diesen Konstellationen arbeiten
mein Vorschlag mit FRCRATIO lebt mit der Hoffnung, dass FRCRATIO 1 das Blocken halbwegs sicher abschaltet, die Doku ist da ein wenig Wachsweich iSeries Information Center (http://publib.boulder.ibm.com/iseries/v5r1/ic2924/index.htm?info/rbam6/rbam6frcratioexpand.htm)
Ansonsten bleibe ich dabei: ein von einem Trigger abhängiges Programm sollte den Satz nicht erneut lesen, sondern vom Trigger das passende Image übergeben bekommen, alles andere ist instabil, was ich zuweilen salopp einen Wackelhaufen nenne, was den Autor des Programmes nicht herabwürdigen soll (sorry, falls das jemand anders versteht)
mfg
Dieter Bender
Nur so am Rande:
FRCRATIO hat nix mit der Verfügbarkeit des Satzes zu tun, auch mit FRCRATIO <> 1 kann der Satz gelesen werden.
SEQONLY wird bei Update/Insert automatisch ausgeschaltet, wenn ein Update/Insert-Trigger definiert ist.
Gerade weil der Trigger ja jeden einzelnen Satz bearbeiten muss.
Anders siehts da bei Input-Dateien aus. Hier kann SEQONLY verwendet werden und somit im Puffer des Programmes ein ganzer Block vorhanden ist in dem der neu eingefügte Satz eben noch nicht enthalten ist.
Lösung:
Beim Erstellen der Programme Blockung für die Datei ausschalten.
SEQONLY(*NO) reicht da leider nicht, da dies das Blocken eben nicht verhindert.
Mit ODP's ist da etwas vorsichtiger umzugehen, da sonst aktuelle Lesezeiger verstellt werden können.
Hier kann man ggf. mit
OVRDBF ... SHARE(*YES)
OPNDBF ... *ALL
das Blocken verhindern. Allerdings können hier ggf. Satzsperren von untergeordneten PGM'en aufgehoben werden so dass nachfolgende Updates auf die nase fallen (Read fehlt).
Wenn eine Datei mit "O" geöffnet wird und ein Trigger anhängig ist, wird automatisch ins Joblog eine Nachricht eingetragen "Zugriff in SEQONLY(*NO) geändert".
Der Open mit "U" blockt grundsätzlich nicht.
Ein Update/Insert-Trigger verhindert automatisch das Blocken von Ausgabeoperationen.
Da ändert auch FRCRATIO(1) nichts dran ausser dass damit die Zugriffe im allgemeinen z.T. erheblich verlangsamt werden.
.. was dann ja bedeutet, dass das Problem woanders angesiedelt sein muss...
Wenn eine Datei mit "O" geöffnet wird und ein Trigger anhängig ist, wird automatisch ins Joblog eine Nachricht eingetragen "Zugriff in SEQONLY(*NO) geändert".
Der Open mit "U" blockt grundsätzlich nicht.
Ein Update/Insert-Trigger verhindert automatisch das Blocken von Ausgabeoperationen.
Da ändert auch FRCRATIO(1) nichts dran ausser dass damit die Zugriffe im allgemeinen z.T. erheblich verlangsamt werden.
Also, ich bin noch nicht viel weiter,
unser gesamtes Design umzubauen ist mächtig aufwändig,
da eine Aufgabe bei uns immer von einem Pgm erledigt wird. Im 'benötigt' Fall wird es einfach nur gerufen.
Da niemand garantieren kann, das der Satz der gelesen wurde nicht schon 5 Stunden am Bildschirm steht, bevor er verarbeitet wird, lesen wir immer in den verarbeiteten Programmen. Das ursprüngliche Verarbeitungspgm müßte ich dann zerschlagen in 'nachlesen' und 'verarbeiten'. aus dem Trigger dann nur das Verarbeitungsprogramm rufen.
D.H. - Neuerfinden von Namensregeln, anpassen von internen Dokumetationen, Gesetz "zum finden von verwendbaren Programmen" überarbeiten, "zu Beachten" erweitern, ...
Na ja hoffentlich hilft's
@Bender
der "Wackelhaufen" verärgert zuweilen schon ein bischen
Damit lebe ich aber gerne, wenn es konstruktiv bleib
vielen Dank
Robi
Wenn ein Trigger ein anderes Programm aufruft, muss dieses sicherstellen, dass die Daten auch tatsächlich erneut gelesen werden.
Ich kenne auch Programme, die sich "merken", welche Daten schon mal gelesen wurden und diese halt nicht nochmal neu liest.
Im OPMRPG gabs die Anweisung FREE um ein gecalltes Programm zurückzusetzen.
Im ILERPG gibts dies nicht mehr.
Hier hilft nur, dem Triggerprogramm eine eigene ACTGRP zu verpassen, ggf. ein CLLE zwischenzuschalten, dass wiederum eine eigene ACTGRP bildet und dann das ursprüngliche Programm aufruft. Dieses Ursprungsprogrogramm sollte in der ACTGRP *CALLER (bei OPM standard) laufen.
Nach dem Aufruf dann ein RCLACTGRP durchführt um eben für den nächsten Aufruf die Initialisierung sicherzustellen.
Aber über Performance dürfen wir uns hier nicht unterhalten.