After trigger liest 'sich selber'

[BenderD]

Hallo,

wieso natürlich???
Dass ein Wackelhaufen woanders funktioniert belegt nix, anderes Verhalten kann auch an unique constraints oder Indexen liegen. Die debug Argumentation schon garnicht, unter Debug läuft manches ein wenig anders als ohne, insbesondere wesentlich langsamer, deshalb muss man das auch separat starten.
Entweder reicht man den Satz durch, oder man muss forciert schreiben, oder man akzeptiert halt einen gewissen Schwund.

mfg

Dieter Bender

Force Ratio steht (natürlich) > 1

Seltsam ist aber, das andere Abläufe (Auftragskopf schreiben, Auftrags Detail erfassen liest vorher auftragskopf) die absolut ähnlich sind, nur ohne Trigger seit Jahren funktionieren. Und mit Debug krig ich's ja auch nicht hin.

Zum Design: Das ist immer solange gut, bis der Kunde alles ganz anders will als ursprünglich besprochen. Kennt doch jeder. Ich weis schon das es in diesem fall nur 'Suboptimal' ist
Robi

[Pikachu]

Ist vielleicht eine COMMIT-Steuerung vorhanden und werden ab und zu Datensätze wieder durch ein ROLLBACK entfernt, nachdem sie geschrieben und der INSERT-Trigger aufgerufen wurde?

An alle: Ist das wirklich so, dass ein neuer Datensatz unter Umständen nicht gleich nach dem Anlegen zum Lesen verfügbar ist?

[BenderD]

Hallo,

Rollback schlägt erst nach dem Trigger zu, während der Aktivität des Triggers ist der Satz da (aber gesperrt).
Bei entsprechender Blockung ist das durchaus so; gesteuert wird das durch FRCRATIO (PF und LF!!!), SEQONLY und wohl auch durch unique Indexe und anderes beeinflusst; deshalb sollte man mit so etwas sorgfältig umgehen.
Wer innerhalb von einer Transaktion (Auftragskopf und Positionen schreiben) nicht immer wieder denselben Satz lesen will (wofür es keinen vernünftigen Grund gibt!!!) und seine Keys sauber ermittelt, wozu ihn Commitment Controll fast schon zwingt, der hat diese Probleme noch nie gehabt!!!


mfg

Dieter Bender

Ist vielleicht eine COMMIT-Steuerung vorhanden und werden ab und zu Datensätze wieder durch ein ROLLBACK entfernt, nachdem sie geschrieben und der INSERT-Trigger aufgerufen wurde?

An alle: Ist das wirklich so, dass ein neuer Datensatz unter Umständen nicht gleich nach dem Anlegen zum Lesen verfügbar ist?

[Robi]

@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

[BenderD]

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

[Fuerchau]

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

[BenderD]

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

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

[Fuerchau]

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.

[BenderD]

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

[Robi]

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

[Fuerchau]

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.