Releaseinformationen zu IBM Compiled Language Debugger 7.5

Vorgabe für Dämon-Port ändern

Der vom Debug-Dämon verwendete Port wird jetzt im Arbeitsbereich gespeichert, so dass jeder Arbeitsbereich einen anderen Debug-Dämon-Port haben kann.

Bei Auswahl der Aktion Port ändern... im Debug-Dämon wird die Vorgabenseite für den Debug-Dämon angezeigt, auf der Sie den Port ändern, aber auch einen neuen Standard-Port festlegen können. Über die Schaltfläche "Als Standard festlegen" wird der Port-Wert als neuer Standard gespeichert, der fortan von neuen Arbeitsbereichen verwendet wird.

Pfad der Steuerkomponente im Dialog 'Quellensuchpfad bearbeiten'

Wenn Sie den Pfad einer Steuerkomponente hinzufügen, wird der von der Debug-Steuerkomponente verwendete Standardpfad aktualisiert.

Sie können den aktualisierten Pfad wie folgt auf den vorherigen Standardpfad der Steuerkomponente zurücksetzen:
  1. Fügen Sie einen leeren Pfadeintrag für die Steuerkomponente hinzu.
  2. Entfernen Sie den leeren Eintrag.

Neue Unterstützung für Standardeditor

In früheren Releases von RationalR Developer für System zTM hat der Debugger für Compilersprachen die Quellen- oder Listenansichten des Programms in einem speziellen Debugger-Editor angezeigt. Jetzt unterstützt Rational Developer für System z beim Debug von COBOL- oder PL/I-Programmen (lokal oder auf dem Host) den Standardeditor. Diese Unterstützung gilt für Programme mit einer Quellenansicht. Alle anderen Ansichten (zerlegte Ansicht oder Listenansicht) verwenden weiter den Debugger-Editor.

Wichtige Hinweise zur Nutzung der Standardeditorunterstützung:
  • Sie können die Unterstützung mit folgender Vorgabe aktivieren/inaktivieren:

    Ausführung/Debug -> Kompiliertes Debug -> Beim Debug immer Debugger-Editor verwenden

    Wenn die Vorgabe ausgewählt (markiert) ist, wird der interne Debugger-Editor verwendet. Ist die Vorgabe nicht ausgewählt (nicht markiert), öffnet der Debugger den Standardeditor für die Sprache des Programms, das gedebugged wird.

  • Der Standardeditor für eine Sprache wird mit der folgenden Vorgabe definiert:

    Allgemein -> Editoren -> Dateizuordnungen

    Dateierweiterungen bestimmen, in welchem Editor die Quelle eines Programms, das gedebugged wird, angezeigt wird. Der Debugger ordnet einer von der Debug-Steuerkomponente abgerufenen Quelle eine Dateierweiterung zu, die der Programmiersprache des Programms entspricht.

  • Rational Developer für System z Version 7.5 unterstützt die folgenden Standardeditoren:
    • LPEX-Editor für System z
    • Remote C/C++ Editor
  • Wenn die Debug-Steuerkomponente die Quelle abgerufen hat, kopiert sie sie vollständig in eine temporäre Datei im Arbeitsbereich des Benutzers. Die temporäre Datei wird mit dem Standardeditor im Lesezugriffsmodus geöffnet. Nach Abschluss der Debug-Sitzung wird die temporäre Datei gelöscht.
  • Wenn es sich um eine lokale Quelle in einem Arbeitsbereichsprojekt oder im lokalen Dateisystem handelt, lädt der Standardeditor die lokale Datei im Lesezugriffsmodus. Falls die lokale Datei im Bearbeitungsmodus geöffnet werden kann, enthält das Pop-up-Menü des Editors eine Option, über die die Datei modifiziert werden kann. Werden Quellenzeilen hinzugefügt, entfernt oder modifiziert, hebt der Debugger beim Stepping oder beim Stoppen an einem Breakpoint möglicherweise nicht die richtige Zeile hervor.
  • Die sprachsensitiven Features des Editors stehen zur Verfügung. Dazu gehört die Gliederungsansicht, sofern vom Editor unterstützt.

Content Assist in der Debug-Konsole für Befehle des Debug Tool

Die Debug-Konsolansicht stellt jetzt Basisunterstützung für Content Assist bereit. Wenn sich der Cursor im Befehlseingabefeld befindet und Sie die Tastenkombination Strg + Leertaste drücken, werden alle unterstützten Befehle des Debug Tool aufgelistet. Die Liste hängt von der Version des verbundenen Debug Tool hab. Wenn Sie Zeichen eingeben, wird die Liste entsprechend gefiltert und zeigt passende Befehle an.

Unterstützung für Breakpoints bei Ausführung von Befehlen des Debug Tool

Neuere Versionen der Debug-Tool-Steuerkomponente unterstützen die Ausführung von Debug-Tool-Befehlen, wenn ein Breakpoint festgestellt wird. Besteht eine Verbindung zu einer Debug-Tool-Steuerkomponente, die Befehle für einen Breakpoint unterstützt, erscheint auf der Seite 'Optionale Parameter' des Breakpoint-Assistenten ein neues Feld. Für den Breakpoint eingegebene Befehle des Debug Tool werden ausgeführt, wenn der Breakpoint festgestellt wird.

Batch-Programme

Das Debug für ein Batch-PL/I-Programm funktioniert nicht, wenn die Quelle in die JCL eingebettet ist. Der Debugger erfordert eine Quellendatei.

Wenn Sie 'Debug für Anwendung' für eine ferne ausführbare Datei ausführen, startet diese Aktion eine Batch-Debug-Sitzung. Da die Anwendung im Stapelbetrieb ausgeführt wird, können Sie an der TSO-Eingabeaufforderung keine Programmeingaben bereitstellen. Sie können diesen Fehler umgehen, indem Sie die erforderlichen Benutzereingaben im Feld 'Zusätzliche JCL' auf der Merkmalseite mit den Laufzeitoptionen des Projekts angeben.

Fernes CICS-Debug

Für das Debug einer fernen Transaktion steht bei Verwendung von CICS TXSeries neben der Transaktion DTCN die Transaktion CADP zur Verfügung. Weitere Informationen hierzu können Sie dem Benutzerhandbuch zum Debug Tool entnehmen.

Der Debugger stellt zwei Schnittstellen für das Einfügen des Debug-Codes in ein CICS-Programm während des Link-Schritts bereit:
  • Bei Auswahl von EQADCCXT können Sie als Ziel der Debugger-Liste dynamisch eine andere Workstation angeben.
  • Bei Auswahl von CEEUOPT fügt z/OS eine statische IP-Adresse und Port-Nummer in das CICS-Programm ein.
Das nachfolgende Beispiel zeigt, wie die Schnittstelle EQADCCXT per 'Link Edit' in die CICS-Programme eingefügt wird:
  • INCLUDE SYSLIB(EQADCCXT)
  • INCLUDE SYSLIB(DFHELII)
  • INCLUDE SYSLIB(DSNCLI)

Wenn Sie sich für die Schnittstelle EQADCCXT entscheiden, stellt der Debugger ein CICS-Programm (Debug Tool Control Panel) für die dynamische Änderung Ihrer Debug-Testumgebung bereit. Die Debug-Sitzung kann nur in der CICS-Region mit dem MFI-Protokoll getestet oder mit dem Protokoll TCP an eine Workstation umgeleitet werden, auf der Rational Developer ausgeführt wird.

Das Programm 'Debug Tool Control Panel' kann durch die Eingabe von DTCN auf dem CICS-Terminal gestartet werden. Wenn die Anzeige 'Control Panel' erscheint, geben Sie als Protokoll TCP ein, die Port-Nummer, an der das Debugger-Serverprogramm von Rational Developer für System z auf der Workstation empfangsbereit ist (normalerweise Port 8001) und die IP-Adresse der Workstation. Geben Sie die Transaktions-ID für Ihre Programmdefinition ein. Drücken Sie zum Speichern die Taste PF4 und dann zum Beenden die Taste PF3. Überprüfen Sie nun in Rational Developer für System z, ob der Debugger-Server am richtigen Port empfangsbereit ist. Sie können das CICS-Programm (mit der Transaktions-ID) aufrufen. Die Debug-Perspektive müsste in Rational Developer für zSeries auf Ihrer Workstation angezeigt werden.

Debug für Quellendateien mit identischen Namen

Es ist bekannt, dass der dezentrale Workstation-Debugger durch einen Fehler das Debug für die falsche Quellendatei durchführt. Hat die Quellendatei zweier lokaler Projekte denselben Namen, wird das Debug für die falsche Anwendung durchgeführt. Wenn Sie Breakpoints in der Quellendatei des einen Projekts setzen, stoppt der Debugger bei der Verarbeitung der anderen Quellendatei, als wären für diese ebenfalls Breakpoints gesetzt. Dieser bekannte Fehler wird in einem der künftigen Releases für dieses Produkt behoben. Sie können den Fehler umgehen, indem Sie in Ihrem Arbeitsbereich nur Quellendateien mit unterschiedlichen Namen verwenden. Den Fehler mit den Breakpoints können Sie umgehen, indem Sie im dezentralen Debugger wiederholt auf 'Ausführen' klicken, um die unerwünschten Breakpoints zu überspringen.

Projektnamen mit mehr als 80 Zeichen verursachen Fehler beim lokalen Debug

Ein lokales Debug für eine ausführbare Datei, die in einem Projekt enthalten ist, dessen Name länger als 80 Zeichen ist, kann zu einem Übertragungsfehler im Debugger und zur Beendigung der Debug-Sitzung führen.

Debug für ein COBOL-Programm mit einer Anweisung XML PARSE

Wenn Sie ein Debug für ein COBOL-Programm mit einer Anweisung XML PARSE durchführen, werden Variablen möglicherweise nicht in der Variablenansicht angezeigt und können unter Umständen nicht überwacht werden. Wenn Sie alle Variablen in der Variablenansicht anzeigen möchten, klicken Sie im Stack auf das COBOL-Programm mit dem Namen, den das COBOL-Programm im Debug-Fenster hat. Wenn Sie beispielsweise ein Debug für ein COBOL-Programm mit dem Namen XML1 ausführen, sehen Sie im Stack XML_XML1 und XML1. Sie müssen auf XML1 klicken und dann auf das Register 'Variablen'.

Falls Sie eine Variable überwachen möchten, klicken Sie im Quellenfenster auf die Zeile mit der PROGAMM-ID. Fügen Sie dann im Monitorfenster das Datenfeld hinzu, das Sie überwachen möchten.

Änderung im ADATA-Format von HLASM

Das von HLASM (High Level Assembler) erzeugte ADATA-Format hat sich mit dem Wechsel von Version 1 Release 4 zu Version 1 Release 5 geändert. Das für das Debug von Symbolic Assembler erforderliche Debug Tool EQALANGX kann nur das ADATA-Format von Version 1 Release 4 lesen. Zu HLASM wird der optionale ADATA-Exit ASMAXADR geliefert, der die ADATA-Datei vom Format des Release 5 auf das Format von Release 4 konvertiert. Sie müssen diesen Exit für das HLASM-Debug für Symbolic Assembler installieren und aktivieren. Wenn Sie die ADATA-Datei nicht in das Format von Release 4 konvertieren, scheint das Dienstprogramm EQALANGX zunächst fehlerfrei zu arbeiten. Das Problem tritt dann erst während der Debug-Sitzung auf.