Debugging für EGL-Anwendungen

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 Fenster > Benutzervorgaben > EGL > Debug. 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 Debug ausführen als > Debug auf Server ausführen.
    • Klicken Sie bei Webtransaktionen mit der rechten Maustaste auf die Datei EGLWebStartup.jsp und klicken Sie dann auf Debug ausführen als > Debug auf Server ausführen.
    • Klicken Sie bei Stapelverarbeitungsprogrammen mit der rechten Maustaste auf die Datei '.egl' und klicken Sie dann auf Debug ausführen als > EGL-Programm.
    • Klicken Sie bei Rich-UI mit der rechten Maustaste auf die Datei '.egl' und klicken Sie dann auf Debug ausführen als > EGL-Rich-UI-Anwendung. 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.