Als 'Debugging' wird der Prozess bezeichnet, bei dem die Ausführung eines Programms überwacht wird, um die Ursache von Fehlern zu ermitteln. Mit dem EGL-Debugger können Sie Unterbrechungspunkte (also Positionen für das Anhalten der Ausführung) festlegen, Variablen untersuchen bzw. ändern und schrittweise das Programm durcharbeiten. Das Debugging kann für den folgenden Code ausgeführt werden:
- JSF-Handler
- Programme
- Webtransaktionen
- Rich-UI-Handler
Die einfachste Form des Debuggings umfasst die folgenden Schritte:
- Wählen Sie eine Benutzervorgabe für das Aussetzen des Programms aus. Klicken Sie hierzu auf .
Klicken Sie unter Ausführung aussetzen auf Bei der ersten Zeile
der Ausführungseinheit stoppen.
- Wählen Sie die zu startende Datei basierend auf der Benutzerschnittstellentechnologie aus:
- Klicken Sie bei JSF mit der rechten Maustaste auf die Datei '.jsp', die dem JSF-Handler zugeordnet ist, und klicken Sie dann auf .
- Klicken Sie bei Webtransaktionen mit der rechten Maustaste auf die Datei EGLWebStartup.jsp und klicken Sie dann auf .
- Klicken Sie bei Stapelverarbeitungsprogrammen mit der rechten Maustaste auf die Datei '.egl' und klicken Sie dann auf .
- Klicken Sie bei Rich-UI mit der rechten Maustaste auf die Datei '.egl' und klicken Sie dann auf . Weitere Information finden Sie in Debugging für Rich-UI.
- Starten Sie das Programm.
- Der Code wird bei der ersten Zeile der Ausführungseinheit ausgesetzt. EGL gibt die Frage aus, ob Sie in die Perspektive 'Debug' wechseln wollen. Klicken Sie auf Ja.
- Klicken Sie auf die Schaltfläche Step-Into, um sich im Programm zu bewegen.
Debug mit JDBC für SQL-Zugriff
Der Debugger verwendet JDBC für den SQL-Zugriff. Hierdurch ergeben sich die folgenden Unterschiede zur Ausführung bei Umgebungen, in denen JDBC nicht eingesetzt wird:
- JDBC unterstützt das zweiphasige Commit nicht. Es gibt für Commit und Rollback separate Aufrufe an den
SQL-Manager und den WebSphere MQ-Manager
(früher MQSeries). Falls ein Programm auftritt, ist es daher möglich, für eine einzelne Ressource ein Commit oder ein Rollback ohne das entsprechende Commit oder Rollback für die andere Ressource durchzuführen.
- JDBC führt immer dynamisches SQL aus. Das generierte COBOL verwendet statisches SQL, es sei denn, es wird
die EGL-Anweisung prepare oder eine Hostvariable für den Tabellennamen
(Eigenschaft tableNameVariables in der Definition von SQLRecord) verwendet. Daher bestehen die folgenden Unterschiede:
- Im dynamischen Modus kann die Auswahl einer Einzelzeile zur Rückgabe mehrerer Zeilen führen, ohne dass
sysVar.sqlData.sqlCode auf
-811 gesetzt ist. Solange es nur eine einzige Zeile gibt, die die Kriterien erfüllt, ist kein Unterschied erkennbar. Im folgenden Beispiel wird ein Verfahren beschrieben, mit dem Sie diese Unterscheidung sichtbar machen können, wenn dies für Sie wichtig ist.
- JDBC konvertiert Daten, die auf dem Host als SQL-Spalte des Typs CHAR, DBCHAR,
oder MBCHAR definiert sind, mit der Option 'FOR BIT DATA'. Tritt diese Situation auf Ihren Fall zu,
geben bei der Eigenschaft asBytes für das Feld, das der als 'FOR BIT DATA' definierten SQL-Spalte entspricht, YES an.
Die folgenden Einschränkungen gelten gleichermaßen für das Debug und für Java™-Programme. Es gibt einen Unterschied zwischen Debug und generierten COBOL-Programmen, jedoch keinen Unterschied zwischen Debug und generierten Java-Programmen:
- Achten Sie darauf, die Basiselementtypen DATE, TIME und TIMESTAMP beim Definieren von Feldern für SQL-Spalten zu verwenden, die diese Typen enthalten. Sie können den Basiselementtyp CHAR verwenden, solange
für die Variable CHAR die Eigenschaft sqlDataCode festgelegt ist, um den Typ der SQL-Spalte anzugeben. Sie können CHAR auch ohne die Eigenschaft sqlDataCode verwenden. Wenn Sie die Eigenschaft
sqlDataCode nicht angeben, müssen die Daten jedoch vom JDBC-Treiber in das CHAR-Format konvertiert werden. Weitere Informationen zur Eigenschaft sqlDataCode finden Sie unter sqlDataCode.
- Bestimmte SQL-Informationen werden von JDBC nicht unterstützt:
- sqlLib.sqlData.sqlerrmc
- sqlLib.sqlData.sqlwarn[n]
- sysVar.sqlData.sqlerrmc
- sysVar.sqlData.sqlwarn[n]
Beim ausgereifteren Debugging kommen Startkonfigurationen, Unterbrechungspunkte, Datenbankverbindungen, die Festlegung von Variablenwerten und weitere Konzepte zum Einsatz.
Eine Übersicht finden Sie unter Anwendung im EGL-Debugger schrittweise durchgehen.
Andere Debugumgebung als Host
Es gibt ein Verfahren, das Sie nutzen können, wenn sich die Debugumgebung von der Hostumgebung unterscheidet: Wählen Sie bei den Benutzervorgaben
EGL >
Debug die Option
systemType auf DEBUG setzen aus. Im EGL-Programm können Sie Logik wie beispielsweise die Folgende einschließen:
if (sysVar.systemType is debug)
// do nothing
else
// check for sysVar.sqlData.sqlCode = -811
end
Dies ermöglicht die Aufnahme von systemspezifischer Logik, die nur auf dem Hostsystem gültig ist.
Informationen zu den Unterschieden bei der Tastatur enthält die Zuordnungstabelle für EGL-Funktionstasten im Abschnitt
validationBypassKeys oder helpKey.
Falls in der Hostumgebung eine andere Codepage als auf der Workstation verwendet wird, kann es sinnvoll sein, auch die im Debugger verwendete Codepage zu ändern.
Details können Sie unter Zeichencodierungsoptionen für den EGL-Debugger nachlesen.
Debug für Programme durchführen
Zum Durchführen des Debugs für Programme, die nicht unter JEE ausgeführt werden, können Sie die Debugsitzung
wie unter Anwendung im EGL-Debugger schrittweise durchgehen beschrieben starten.
Informationen zu EGL-Debuggerbefehlen enthält der Abschnitt Steuerelemente für den EGL-Debugger. Weitere Angaben über die Auswirkungen von Builddeskriptoreinstellungen auf den EGL-Debugger
finden Sie unter Auswirkungen von Builddeskriptoreinstellungen auf den EGL-Debugger.