[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Jan 2012
    Beiträge
    1.102

    Triggerverarbeitungsprogramm aus Testumgebung debuggen

    Ich bin's schon wieder.
    Ich habe eine Datenbanktabelle, auf der ein Triggerprogramm, z.B. TRIGGER01 (RPGLE) liegt. Das Triggerprogramm ruft ein weiteres Programm auf, dass die eigentliche Arbeit macht. (z.B. TRIGGERWRK).
    Jetzt möchte ich eine Anpassung in TRIGGERWRK machen und diese Anpassung in einer Testumgebung testen. Also erstelle ich eine Lib TESTLIB, in die ich das angepasste Programm TRIGGERWRK reinstelle.
    Dann setze ich die Bibliotheksliste so, dass TESTLIB ganz vorne steht und rufe STRSQL auf. Dort mache ich ein Update auf die Datenbanktabelle. Der Trigger wird ausgelöst. Aber er ruft immer das TRIGGERWRK aus der Echtumgebung auf.

    Wird STRSQL von einem separaten SQL-Servicejob bedient, so dass die Änderung der *LIBL nicht wirkt? Oder müsste das eigentlich gehen?

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Es geht dann, wenn das Triggerprogramm in deinem Job noch nie aufgerufen wurde.
    Also immer dann, wenn du das Programm neu erstellst, musst du dich leider auch wieder abmelden und neu anmelden, da durch den CRTxxxPGM das aktive Programm in QRPLOBJ verschoben wird und somit weiterläuft.
    STRSQL läuft im aktuellen Job, es sei denn du machst einen Connect auf die eigene Maschine.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Tatsache! Mit einem frischen Job klappt es. Muss man erst mal drauf kommen.
    Herzlichen Dank.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das ist aber eigentlich schon immer so gewesen.
    Wenn Programme einen Call gemacht haben, dann halten Sie einen Pointer auf das gefundene Objekt bis der Job beendet ist.
    Ausnahme: das CL-Kommando CALL, das immer eine neue Referenz ermittelt (wiederum nicht im CLLE).

    Im alten OPM-RPG gabs den Befehl "FREE" (COBOL CANCEL), mit dem ein Call-Pointer aufgehoben wurde und das Programm (auch wenn LR=OFF ist), aus dem Speicher entfernt hat.
    Dies ist im ILERPG nicht mehr möglich, da ACTGRP's bzgl. von Inits anders arbeiten.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Nov 2003
    Beiträge
    2.304
    Parsing Program Names on a Call (ILE RPG)

    Program references are grouped to avoid the overhead of resolving to the target program. ...

  6. #6
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Vielen Dank für Eure Antworten. So klar war mir das bisher nicht. Ich weiß, dass es oft Probleme gibt, ein neu kompiliertes Programm in den Zugriff zu bekommen. Da werden oft die Objekte aus der QRPLOBJ gezogen. Erst wenn die ACTGRP beendet wird, kann man sicher davon ausgehen, dass das neue Objekt gezogen wird.
    Ich dachte aber bisher, dass das etwas anderes ist, wenn man die *LIBL ändert. Dass das auch nicht sofort wirkt, war mir nicht so klar.

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das ist ja nicht nur mit Programmen so, das gilt auch und gerade bei SQL für die sog. ODP's.
    Wenn ein Programm eine Datei offen hat, dann hilft ein CHGLIBL auch nicht mehr.

    Vorsichtig muss man ebenso bei ACTGRP's und RCLACTGRP sein.
    Wenn ein ILE aufgerufen wird, laufen bestimmte Initialisierungen tatsächlichund ausschließlich beim Aktivieren eines Programmes (noch vor INZSR), dann wird falls vorhanden die INZSR aufgerufen.

    Macht man nun ein RCLACTGRP und ein Programm aus Gruppe A hält noch einen Pointer aus Gruppe B, so wird das Programm aus B nicht entfernt, die ACTGRP aber gelöscht.
    Ruft nun A das Programm B auf, stürzt dieses mit diversen Fehlern ab, da z.B. automatisch geöffnete Dateien bei der Initialisierung geöffnet wurden, beim RCLACTGRP zwangsgeschlossen aber nun beim erneuten Aufruf nicht wieder geöffnet werden. Ebenso wird auch INZSR nicht erneut aufgerufen, was durch den RCLACTGRP ggf. erforderlich wäre.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Copysourcen debuggen in RDi
    By stefan24 in forum NEWSboard Programmierung
    Antworten: 2
    Letzter Beitrag: 14-09-15, 13:19
  2. RDi 9.1 hängt sich beim Debuggen weg
    By dschroeder in forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 20-06-14, 12:14
  3. Probleme beim debuggen von C-Programmen
    By areichelt in forum IBM i Hauptforum
    Antworten: 7
    Letzter Beitrag: 24-10-02, 10:19

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •