[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Nov 2012
    Beiträge
    47

    Triggerprogramm debuggen

    Hallo,

    lang, lang ist es her, dass ich mal ein Triggerpgm debuggen musste - und jetzt weiss ich nicht mehr, wie das ging...

    Kann mir hier mal wieder jemand auf die Sprünge helfen...

    Danke schonmal vorab.

    harbir

  2. #2
    Registriert seit
    Jun 2001
    Beiträge
    2.044
    Ämmm ...

    STRDBG TriggerPgmName UPDPROD(*YES)
    Breakpoint (F6)
    ...


    oder im Batch

    Job anhalten,
    STRSRVJOB derJob

    dann
    STRDBG ...

    Job starten
    F10
    DSPMODSRC
    Breakpoint ...


    Oder was meinst Du ?

    Robi
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  3. #3
    Registriert seit
    Jan 2012
    Beiträge
    1.199
    Hallo,

    möglicherweise ist ja der Job nicht bekannt oder kann nicht angehalten werden. In dem Fall kann man im Debugger mit dem Befehl sbreak einen Service-Entry-Point setzen setzen. Es spielt dann keine Rolle, welcher Job das ausführt.

    Dieter

  4. #4
    Registriert seit
    Nov 2012
    Beiträge
    47
    Zitat Zitat von dschroeder Beitrag anzeigen
    Hallo,

    möglicherweise ist ja der Job nicht bekannt oder kann nicht angehalten werden. In dem Fall kann man im Debugger mit dem Befehl sbreak einen Service-Entry-Point setzen setzen. Es spielt dann keine Rolle, welcher Job das ausführt.

    Dieter
    Hallo,

    ja, der Job ist nicht bekannt...
    Kannst Du mir das etwas ausführlicher mit dem Service-Entry-Point erklären?

    Danke
    harbir

  5. #5
    Registriert seit
    Nov 2012
    Beiträge
    47
    Zitat Zitat von Robi Beitrag anzeigen
    Ämmm ...

    STRDBG TriggerPgmName UPDPROD(*YES)
    Breakpoint (F6)
    ...


    oder im Batch

    Job anhalten,
    STRSRVJOB derJob

    dann
    STRDBG ...

    Job starten
    F10
    DSPMODSRC
    Breakpoint ...


    Oder was meinst Du ?

    Robi
    danke... , aber das normale debuggen beherrsch ich...

  6. #6
    Registriert seit
    Jan 2012
    Beiträge
    1.199
    Zur Definition eines Service-Entry Points startet man den Debugger für das gewünschte Programm ganz normal mit STRDBG < Programmname>. Dann setzt man auf die gewünschte Zeile einen Breakpoint. Das macht man aber nicht mit der F6-Taste, sondern man gibt auf der Befehlszeile im Debugger sbreak user ein. (Z.B. "SBREAK 82 user meier"). In diesem Fall wird das Programm in der Zeile 82 gestoppt, sobald der User Meier in irgendeinem Job das Programm aufruft. Wenn das passiert, bekommt man in der Sitzung, in der man den Debugger gestartet hat, eine Meldung "Der Service-Eingangspunkt stoppte bei Zeile 20 in Programm SCR/A in Job ...". Auf diese Meldung geht man dann mit F1. Im Text kann man dann den genauen Job ablesen. In einer 2. Sitzung kann man dann für diesen Job einen STRSRVJOB durchführen und normal debuggen.

    Das ist ein wenig umständlich. Einfacher geht es, wenn man RDP einsetzt. Da ist das ganze in der grafischen Oberfläche etwas benutzerfreundlicher gemacht. Aber es ist das gleiche Verfahren.

    Gruß,
    Dieter

  7. #7
    Registriert seit
    May 2002
    Beiträge
    1.121
    Cool

    Wieder was dazu gelernt. Das hätte mir bei so manchen batch-programm schon weiter geholfen....

    Danke
    Ronald

  8. #8
    Registriert seit
    Jan 2007
    Beiträge
    189
    Zitat Zitat von dschroeder Beitrag anzeigen
    Zur Definition eines Service-Entry Points startet man den Debugger für das gewünschte Programm ganz normal mit STRDBG < Programmname>. Dann setzt man auf die gewünschte Zeile einen Breakpoint. Das macht man aber nicht mit der F6-Taste, sondern man gibt auf der Befehlszeile im Debugger sbreak user ein. (Z.B. "SBREAK 82 user meier"). In diesem Fall wird das Programm in der Zeile 82 gestoppt, sobald der User Meier in irgendeinem Job das Programm aufruft. Wenn das passiert, bekommt man in der Sitzung, in der man den Debugger gestartet hat, eine Meldung "Der Service-Eingangspunkt stoppte bei Zeile 20 in Programm SCR/A in Job ...". Auf diese Meldung geht man dann mit F1. Im Text kann man dann den genauen Job ablesen. In einer 2. Sitzung kann man dann für diesen Job einen STRSRVJOB durchführen und normal debuggen.

    Das ist ein wenig umständlich. Einfacher geht es, wenn man RDP einsetzt. Da ist das ganze in der grafischen Oberfläche etwas benutzerfreundlicher gemacht. Aber es ist das gleiche Verfahren.

    Gruß,
    Dieter
    Wo ist das "Like" button?

    Also, if you don't know what job it is and it is not yet submitted (z.B. if a job is only submitted when a DTAQ entry is received), you can hold the JOBQ until the required job gets submitted.
    mfg

    Kit
    www.ecofitonline.com
    DeskfIT - ChangefIT - XrefIT

  9. #9
    Registriert seit
    Nov 2012
    Beiträge
    47
    Zitat Zitat von dschroeder Beitrag anzeigen
    Zur Definition eines Service-Entry Points startet man den Debugger für das gewünschte Programm ganz normal mit STRDBG < Programmname>. Dann setzt man auf die gewünschte Zeile einen Breakpoint. Das macht man aber nicht mit der F6-Taste, sondern man gibt auf der Befehlszeile im Debugger sbreak user ein. (Z.B. "SBREAK 82 user meier"). In diesem Fall wird das Programm in der Zeile 82 gestoppt, sobald der User Meier in irgendeinem Job das Programm aufruft. Wenn das passiert, bekommt man in der Sitzung, in der man den Debugger gestartet hat, eine Meldung "Der Service-Eingangspunkt stoppte bei Zeile 20 in Programm SCR/A in Job ...". Auf diese Meldung geht man dann mit F1. Im Text kann man dann den genauen Job ablesen. In einer 2. Sitzung kann man dann für diesen Job einen STRSRVJOB durchführen und normal debuggen.

    Das ist ein wenig umständlich. Einfacher geht es, wenn man RDP einsetzt. Da ist das ganze in der grafischen Oberfläche etwas benutzerfreundlicher gemacht. Aber es ist das gleiche Verfahren.

    Gruß,
    Dieter
    Hallo,

    danke für die Erklärung.

    Noch eine kurze Frage:
    Welcher User führt standardmäßig das Triggerpgm aus?
    ist das immer der User, der den Trigger auslöst oder ist das ein Systemuser?

    VG
    harbir

  10. #10
    Registriert seit
    Jan 2012
    Beiträge
    1.199
    Bei "normalen" interaktiven iSeries Jobs müsste das der angemeldete User sein. Bei Batch-Jobs kann das ein anderer User sein. Das kann man ja beim SBMJOB mitgeben. Beim Aufrufen von iSeries-Programmen vom PC aus bin ich mir nicht sicher. Dort ist es ja normalerweiser der QUSER. Aber möglicherweise wird dort auch der Current User verwendet.

    Dieter

  11. #11
    Registriert seit
    Nov 2012
    Beiträge
    47
    Zitat Zitat von dschroeder Beitrag anzeigen
    Bei "normalen" interaktiven iSeries Jobs müsste das der angemeldete User sein. Bei Batch-Jobs kann das ein anderer User sein. Das kann man ja beim SBMJOB mitgeben. Beim Aufrufen von iSeries-Programmen vom PC aus bin ich mir nicht sicher. Dort ist es ja normalerweiser der QUSER. Aber möglicherweise wird dort auch der Current User verwendet.

    Dieter
    Hallo,

    danke, das hat mir sehr weitergeholfen.

    Die Daten in der getriggerten Datei kommen über einen Webservice auf die iSeries und ja, es wird hier der QUSER verwendet.

    VG
    harbir

  12. #12
    Registriert seit
    Feb 2001
    Beiträge
    20.696
    QUSER ist nur Bestandteil des Jobnamens.
    Die SQL-Funktion Current_User bzw. USER liefert den aktuellen User aus der Anmeldung.
    Wenn ein Trigger-Pgm nur den Job-User abfragt (SDS im RPG, RTVJOBA im CL) wird QUSER geliefert.

    Wenn man den richtigen User haben will, sollte man diesen per API/SQL abfragen.

    Diese Information ist nicht statisch!

    Durch die Wiederverwendung von QZDA-Jobs kann der User auch gewechselt werden.
    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. Debuggen von SQL-Sitzungen
    By Fuerchau in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 01-06-12, 14:58
  2. Debuggen im Batchmodus
    By M Scheid in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 07-11-05, 10:22
  3. SQLCBL debuggen?
    By Cobolaner in forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 23-09-05, 09:13
  4. Problem beim Debuggen
    By Flappes in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 21-07-05, 11:14
  5. Trigger Triggerprogramm Objektlock
    By kuempi von stein in forum NEWSboard Programmierung
    Antworten: 8
    Letzter Beitrag: 01-03-05, 12:41

Berechtigungen

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