[NEWSboard IBMi Forum]
Seite 2 von 4 Erste 1 2 3 ... Letzte
  1. #13
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Ja, weil das trotzdem durch SQL gemacht wurde, siehe "Set Option".
    Da du den Trigger ja debuggen kannst, kannst du den commit-Status des Jobs ja prüfen.
    Wenn du z.B. über STRSQL einen Update machst, wird der Trigger ja auch aufgerufen.
    Allerdings funktioniert das nur über eine 2. Sitzung per STRSRVJOB zur 1. Sitzung und dann per STRDBG, der auf dem Zieljob ausgeführt wird.
    So teste ich immer erst mal die Trigger.

    Bei STRSQL kann man den Commit-Status per F13 einstellen und so mit und ohne Commit testen.
    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

  2. #14
    Registriert seit
    Sep 2004
    Beiträge
    327
    Habe das Programm nun endlich fertig. Was ein Krampf mit den Parametern.
    Nun habe ich folgendes Problem:
    Ich mache einen strcmtctl *chg
    call PGMxx
    Result = A --> perfekt
    endcmtctl
    call PGMxx
    bricht ab, weil das Objekt nicht aufgelöst werden kann
    Aufl¦sung zu Objekt nicht m¦glich. Art und Subart X'0201', Berechtigung
    X'0000'.

    Das passiert auch, wenn ich es umgekehrt mache, d.h.
    zuerst den Aufruf vom Programm
    dann STRCMTCTL *CHG
    dann Aufruf des Programmes
    Inhalt aus dem Programm:
    c callp RtvCmtData(w@Rcvva:
    c w@RcvLe:
    c 'CMTI0100':
    c w@errorDta)

    definiert wie folgt:

    dRtvCmtData pr extpgm( 'QTNRCMTI' )
    d w@Receiver like( w@rcvva )
    d w@Laenge const like( w@Rcvle )
    d w@Format 8 const
    d w@Error like (w@ErrorDta)

    An was kann das liegen?

  3. #15
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    In welcher Aktivierungsgruppe läuft denn Dein PGMXXX?
    Mit welchem Commitment Scope wird denn die Commitment Steuerung gestartet?
    Sollte es *ACTGRPDFN sein, würde ich die Aktivierungsgruppe mit RCLACTGRP vor dem erneuten Aufruf schließen.
    Sollte es allerdings die Default Activation Group sein .... dann hast du Pech gehabt, d.h. da hilft nur ein EndJob
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  4. #16
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn ich Trigger auf einer Tabelle habe, darf ich RCLACTGRP nicht verwenden.
    Denn die ACTGRP wird aufgelöst, jedoch findet dann die Datenbank den Trigger nicht mehr, denn dieser Pointer auf das Programm wird wohl nur beim 1. Open generell gesetzt und irgnedwo im Job festgehalten.
    Das war schon immer ein Problem, seit V2R1.
    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. #17
    Registriert seit
    Sep 2004
    Beiträge
    327
    Guten Morgen Zusammen,
    sorry für meine schlechte Erklärung. Es geht noch gar nicht um das Trigger Programm, sondern um das Programm welches prüft, ob STRCMTCTL aktiv ist oder nicht, sprich in dem Programm wird das API QTNRCMTI aufgerufen.
    Irgendetwas stimmt nicht, eventuell auch falsch programmiert.
    @Birgitta:Vergiss das mit STRCMTCTL. Der Fehler tritt auf, sobald ich das Programm 2x aufrufe, d.h. irgendetwas passiert durch den 1. Aufruf.
    Wieso findet das Programm entweder das API nicht mehr oder im API irgendwelche aufgerufenen Programme?
    Wo ich mir auch sehr unschlüssig bin ist in der Definition der DS:
    Der Wert wird zwar ausgegeben, aber in anderen API's haben wir mit StartPos und Länge auch etwas gemacht.
    So sieht es aktuell aus:

    h DEBUG ACTGRP(*CALLER) DFTACTGRP(*NO) BNDDIR('*LIBL/SPE')
    d ds
    d w@lendta 1 4b 0
    d w@strpos 5 8b 0
    d w@splfx 9 12b 0
    d w@rcvle1 13 16b 0
    d w@filx 17 22
    d w@rcvle 23 26b 0

    d w@Rcvva ds
    d w@bytrtn 1 4b 0
    d w@bytval 5 8b 0
    d w@cmtsts 9 9
    d w@cmtstsAG 21 21

    d w@ErrorDta ds
    d w@bytrtne 1 4b 0
    d w@bytvale 5 8b 0
    d w@ExcepId 9 15
    d w@ResChar 16 16
    d w@ExcepDta 17 500

    c callp RtvCmtData(w@Rcvva:
    c w@RcvLe:
    c 'CMTI0100':
    c w@errorDta)

    Die Var w@RCVLE ist mir auch nicht so ganz klar, habe dies aus meinem altem Programm übernommen.

  6. #18
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn du schon ILERPG nimmst, kannst du auch übersichtliche DS'n erstellen und benötigst keine Byte-Zählerei mehr. Auch die INT-Datentypen sind dann effektiver.
    Desweiteren: Wenn Felder nur definiert sind, werden sie nicht automatisch initialisert. Die Error-Struktur muss im 1. Feld die Länge der DS enthalten, die du bereitstellst.

    Was den Pointer angeht, so weiß ich halt nicht was das API selber so treibt, aber:

    Beim 1. Aufruf eines Programmes werden die Pointer auf Programme intern initialisert.
    Wenn du keine Main-Prozedur hast, ist immer der Zyklus aktiv.
    D.h., beim Verlassen des Programmes solltest du *INLR = *ON setzen, damit das Programm aus dem Speicher entfernt wird.
    Beim nächsten Aufruf wird der Pointer auf ein Programm neu geladen.

    Übrigens: DEBUG in den H-Bestimmungen ist nur relevant, wenn du im Programm die DUMP-Anweisung verwenden willst. Ein debugging ist immer möglich.
    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

  7. #19
    Registriert seit
    Sep 2004
    Beiträge
    327
    Ich verlasse das Programm mit *INLR, daher sollte alles geschlossen sein.
    Die Error DS scheint zu stimmen, das habe ich getestet.
    Ich habe die Prozedur durch einen normalen CALL ersetzt, auch hier kommt der Fehler, dass das Objekt nicht mehr gefunden wird.

    Man findet auch im Netz kein Beispielprogramm.

    Eventuell liegt es auch daran:
    Any call to this API will also refresh cached commitment control settings for the current job. The following settings are cached:

    • The COMMITMENT_CONTROL_LOCK_LIMIT setting in the QAQQINI query options file to control maximum number of record locks.
    • The QIBM_TN_COMMIT_DURABLE environment variable setting to control soft commit.
    • The QTN_JRNSAVPT_* environment variable settings to control whether journal entries are sent for savepoint operations.


    Wenn ich das Programm neu umwandle, dann funktioniert es nach dem Fehler wieder 1x, also muss irgendetwas auch mit dem Aufruf Stack passieren.

  8. #20
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Irgendwie bleibt die interne Adresse zum aufrufenden Programm auch nach INLR = *ON erhalten.
    Was du probieren kannst, ist der Aufruf per Variable.
    Gib bei EXTPGM nicht den Namen sondern eine Variable an.

    Wenn eine Variable verwendet wird, wird der Pointer des Programmes erst zur Laufzeit ermittelt.
    Vor allem wird durch die Zuweisung der Variablen mit dem Namen der intern generierte Pointer grundsätzlich zurückgesetzt, so dass der CALL das Programm neu ermitteln muss.

    Noch ein Tipp:
    Verwende in Feldnamen nie @ oder #, da diese nicht CCSID-neutral sind.
    Bei Portierung kann das dann schon mal zu Problemen führen.
    Nimm lieber "_" wenn du Namen lesbarer gestalten möchtest.
    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

  9. #21
    Registriert seit
    Sep 2004
    Beiträge
    327
    Danke, hat leider nicht funktioniert. Auch mit der Variable in EXTPGM kommt der Fehler mit dem nicht gefundenen Objekt.

  10. #22
    Registriert seit
    Sep 2004
    Beiträge
    327
    So, wenn ich das Programm unter *NEW kompiliere, dann funktioniert es. Nur so kann ich es nicht gebrauchen.
    Ich breche das jetzt ab, würde aber mal die generelle Vorgehensweise in Verbindung mit Trigger und Commit wissen.
    Beispiel:
    PGM A RPG write in Tabelle A
    Trigger wird aufgerufen und schreibt Zusatzdaten in Tabelle B
    PGM A bricht ab und muss Daten Tabelle A und B zurückfahren
    Das ist mal die Mindestvoraussetzung.
    Nun wird es spannend für das Trigger Programm
    - Handling bei unterschiedlichen Aktivierungsgruppen *CALLER *NEW
    - Handling unter Commit und nicht Commit Umgebung

    Wie geht Ihr hier vor?
    Danke.

  11. #23
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Vielleicht sieh ich das mal wieder zu einfach!
    Ich würde einfach den CL-Befehl STMCMTCL ausführen. Wenn er klappt, war Commitment Steuerung nicht aktiv, dann beende ich die Commitemnt Control wieder.
    Ist die Commitment Control aktiv, geht STMCMTCL schief.
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  12. #24
    Registriert seit
    Sep 2004
    Beiträge
    327
    Zitat Zitat von B.Hauser Beitrag anzeigen
    Vielleicht sieh ich das mal wieder zu einfach!
    Ich würde einfach den CL-Befehl STMCMTCL ausführen. Wenn er klappt, war Commitment Steuerung nicht aktiv, dann beende ich die Commitemnt Control wieder.
    Ist die Commitment Control aktiv, geht STMCMTCL schief.
    hatte ich auch schon überlegt.

Similar Threads

  1. Antworten: 1
    Letzter Beitrag: 22-03-19, 17:52
  2. Journal auswerten
    By rr2001 in forum IBM i Hauptforum
    Antworten: 10
    Letzter Beitrag: 03-09-15, 08:37
  3. Journal Receiver
    By KingofKning in forum IBM i Hauptforum
    Antworten: 14
    Letzter Beitrag: 10-03-15, 15:29
  4. Journal abhängen
    By Mädele in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 26-12-05, 10:43
  5. Backup über Journal ?
    By Wirnitzer in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 17-10-01, 11:13

Berechtigungen

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