After trigger liest 'sich selber'

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