Debug Stored Procedure

[lorenzen]

Im WDSC ist für Stored Procedures (in SPL) die Debugauswahl inaktiv. Ich vermute, das der fehlende Befehl: Set Option DBGVIEW = = *STMT, die Ursache ist.
Damit läßt sich jedoch die SP nicht kompilieren, bzw. meldet sich der Syntaxcheck!

Auch das Ändern des CRTSQLCI-Commandefaults auf *SOURCE hilft nicht. Diese Einstellungen werden scheinbar sowieso ignoriert.
Was mache ich falsch?

Gruß
Sven Lorenzen

[Fuerchau]

Die Debug-Sicht ist keine SQL-Option sondern eine Umwandlungsoption !
Wo das im WDSC allerdings eingestellt wird weiß ich nicht.

[lorenzen]

Deshalb habe ich ja auch versucht, beim Compile-Command den Parameter entsprechend einzustellen.
Im Redbook steht auch "Set Option ..." als entsprechender Befehl dafür. Ich habe den Code daraus 1:1 übernommen:
CREATE PROCEDURE SP1()
LANGUAGE SQL
SET OPTION OUTPUT = *PRINT, DBGVIEW = *STMT
BEGIN
...
END

Aber damit läßt sich die SP eben nicht wandeln.
Im WDSC kann man das, glaube ich, auch gar nicht einstellen.
Es ist aber das einzige mir bekannte Interface, mit dem man SP's überhaut debuggen kann.
Gruß
Sven Lorenzen

[Chrissi]

Versuch mal mit :
SET OPTION DBGVIEW = *SOURCE

Die Stored Procedures kann man auch komfortabel mit dem Graphical Debugger testen :

http://www-919.ibm.com/developer/edu...bug/index.html

Gruß
Chrissi

[BenderD]

Hallo Sven,

Der set option muss direkt for dem SQL Statement kommen, sitzt also an der richtigen Stelle. Ob das mit der Liste geht, weiss ich nicht aus dem Kopf, aber falls es nicht funktioniert nach weglassen des *PRINT sieht es nach PTF Problem aus, da habe ich schon mal ein Posting nach einem Artikel gehabt von jemand bei dem es nicht ging..
Das ändern des Command defaults funzt nicht, da ein "interner" C Compiler benutzt wird.

mfg

Dieter Bender

Deshalb habe ich ja auch versucht, beim Compile-Command den Parameter entsprechend einzustellen.
Im Redbook steht auch "Set Option ..." als entsprechender Befehl dafür. Ich habe den Code daraus 1:1 übernommen:
CREATE PROCEDURE SP1()
LANGUAGE SQL
SET OPTION OUTPUT = *PRINT, DBGVIEW = *STMT
BEGIN
...
END

Aber damit läßt sich die SP eben nicht wandeln.
Im WDSC kann man das, glaube ich, auch gar nicht einstellen.
Es ist aber das einzige mir bekannte Interface, mit dem man SP's überhaut debuggen kann.
Gruß
Sven Lorenzen

[lorenzen]

Hallo Herr Fuerchau, Dieter, Chrissi,
danke für die Antworten.
Mit neuesten PTF Stand (23.06.04) seit heute, läßt sich die SP mit "Set Option DBGVIEW = *Source" schon mal Generieren.
Die Debug-Funktion im WDSC wird dadurch aber leider immer noch nicht aktiv.
Interessant: In den SQL Erläuterungen zur SP steht nur :
OPTION(*SYS *PERIOD *NOCNULRQD). Also das DBGVIEW *Source wird scheinbar ignoriert.

Chrissi: Ich habe die Seite mit dem graphischen Debugger besucht. Sieht nicht schlecht aus, aber läuft bei mir noch nicht, weil das Debug Management Programm fehlt. Das muss ich erstmal suchen, bzw. die korrekte Java-Toolbox laden, obwohl ich iSeries Navigator, WDSC und DB2 UDB for Windows vollständig installiert habe.
Jedoch muss damit mit AS/400 Session und Client hantiert werden, während im WDSC eine einheitliche Debugging-Oberfläche für alles vorhanden ist.
Außerdem steht auf der IBM Seite und im Redbook immer ein Beispiel OHNE Result Set. Davon haben wir aber gerade über 400 Stück, die wir debuggen wollen.

Ich werde es halt weiter versuchen.

Weiß vielleicht jemand ein deutsches Forum für WDSC insbesondere für RSE?
Wir machen mit WDSC nämlich im Moment keine Web-applications, sondern nutzen nur die Entwickleroberfläche für RPG, SQL, CMS und DB.

Gruß
Sven Lorenzen

[BenderD]

Hallo Sven,

Mit neuesten PTF Stand (23.06.04) seit heute, läßt sich die SP mit "Set Option DBGVIEW = *Source" schon mal Generieren.
Die Debug-Funktion im WDSC wird dadurch aber leider immer noch nicht aktiv.
Interessant: In den SQL Erläuterungen zur SP steht nur :
OPTION(*SYS *PERIOD *NOCNULRQD). Also das DBGVIEW *Source wird scheinbar ignoriert.

Sven Lorenzen

Der Eintrag beim Precompile ist wohl ziemlich schnurz, in der C Umwandlungsliste sollte der Debug Eintrag sich auswirken. Und ich würde mal den normalen Debug ausprobieren, der sollte eigentlich gehen.

mfg

Dieter Bender

[Sven Schneider]

Nur der green screen debugger (STRDBG) und der iSeries System Debugger (aus der IBM Toolbox for Java) kann mit DBGVIEW(*Source) etwas anfangen, nicht jedoch der in WDSC integrierte Debugger.
(Hintergrund : DBGVIEW(*Source) erstellt immer eine Sourcefile mit Namen QSQDSRC mit SP als Member und nur diese beiden Debugger können diese verarbeiten - im Gegensatz dazu wird beim Compile eines "normalen" z.B. RPG oder C Programms mit Option *source die Source im *PGM-Objekt abgelegt.)
Wie das bei dem neuen WDSC V5.1.2 (ab 16. Juli 2004) aussieht, konnte ich noch nicht in Erfahrung bringen.

Du müsstest dir also selbst einen Kontexteintrag in Eclipse erstellen, um den iSeries System Debugger (tes.jar) direkt aus Eclipse aufzurufen.
Dieser lässt sich auch sehr gut im RSE einbinden, analog der Benutzeroptionen im GreenScreen PDM.
Einen 5250-Sitzung benötigst du für den iSeries System Debugger nur, wenn du interactive Programme (mit DSPF) debuggen willst.

Siehe auch :

http://www-1.ibm.com/support/docview...07624f5&rs=110


Zum Thema Fehler bei OUTPUT(*print) DBGVIEW(*source) steht hier noch was :

http://www-912.ibm.com/n_dir/nas4apa...dbgview,source

Zum iSeries System Debugger findest du alles hier :

http://publib.boulder.ibm.com/infoce...zamq/rzamq.pdf

[BenderD]

Hallo,

was habt ihr bloß immer mit dem Debugger??? ein gutes Programm braucht man nicht zu debuggen, das läuft!!! </FLAME>

Dieter,

der gerade ein paar Amis in der Java400-l auf die Palme gebracht hat.

Nur der green screen debugger (STRDBG) und der iSeries System Debugger (aus der IBM Toolbox for Java) kann mit DBGVIEW(*Source) etwas anfangen, nicht jedoch der in WDSC integrierte Debugger.
(Hintergrund : DBGVIEW(*Source) erstellt immer eine Sourcefile mit Namen QSQDSRC mit SP als Member und nur diese beiden Debugger verarbeiten diese)

Du müsstest dir also selbst einen Kontexteintrag in Eclipse erstellen, um den iSeries System Debugger (tes.jar) direkt aus Eclipse aufzurufen.
Diser lässt sich auch sehr gut im RSE einbinden analog, der Benutzeroptionen im GreenScreen PDM.

Siehe auch :

http://www-1.ibm.com/support/docview...07624f5&rs=110


Zum Thema Fehler bei OUTPUT(*print) DBGVIEW(*source) steht hier noch was :

http://www-912.ibm.com/n_dir/nas4apa...dbgview,source

Zum iSeries System Debugger findest du alles hier :

http://publib.boulder.ibm.com/infoce...zamq/rzamq.pdf

[Fuerchau]

@Dieter

Vielleicht arbeitet ja Microsoft bei seiner Entwicklung ohne Debugger (MS-Programme sind ja alle fehlerfrei), jedenfalls habe ich oft das Gefühl.

[BenderD]

@Baldur:
Peter Sault says:
Java is only the hope for lazy programmers!
Joe Pluta says:
> Let's be clear: PROGRAMMER ERROR IS NOT A VALID REASON FOR COMMITMENT
> CONTROL. *If anything, it becomes a crutch that lazy programmers rely on
> as opposed to actually testing their code.
Dieter Bender sagt: Der Debugger ist nur die Hoffnung des schlechten Programmierers!

Dieter,
mit einem gehässigen Grinsen auf dem Gesicht

@Dieter

Vielleicht arbeitet ja Microsoft bei seiner Entwicklung ohne Debugger (MS-Programme sind ja alle fehlerfrei), jedenfalls habe ich oft das Gefühl.

[lorenzen]

Danke an alle, die sich mit diesem Thema beschäftigt haben.

Hier der Stand:
1. Mit neuem PTF Stand geht Set Option.
2. Mit DBGVIEW = *Source die SP generieren
3. Der Debug im WDSC geht dann auch: "Debug als iSeries Job" aufrufen -> Job auswählen (Client Applikation) -> Bibliothek und SP auswählen (Name des CLE-Programms) -> Debug startet -> SP im Client Programm aufrufen -> Debug läuft.

Was nach wie vor nicht geht, ist der direkte Debugaufruf über das Kontextmenü in den Datendefinitionen.
Macht aber nichts, da es ja wie oben beschrieben nun funktioniert.

Gruß
Sven Lorenzen