System z Millicode Debugger

Inhaltsverzeichnis

1 Einleitung

1.1 Umfeld der Arbeit

1.2 Einordnung der Aufgabenstellung

1.3 Problemstellung

1.4 Ist-Stand

1.5 Einführung zu System z Mainframes

1.5.1 Bedeutung der System z Mainframes - Historisch und gegenwärtig

1.5.2 System z Hardware - Überblick über die Prozessor Hardware

1.5.3 System z Firmware

2 Grundlagen

2.1 System z Millicode

2.1.1 Aufgaben des System z Millicodes

2.1.2 System z Millicode Funktionsweise

2.1.3 System z Millicode Assembler

2.2 Einführung zum Millicode Emulator

2.3 Was ist Eclipse?

2.3.1 Konzepte der Eclipse Oberfläche

2.3.2 Erweiterbares Framework hinter Eclipse

2.3.3 Extension Points

2.3.4 Deployment von Eclipse Plug-ins

2.3.5 Debug Framework

3 Anforderungen und Fachkonzept

3.1 Anforderungen

3.2 Reflexion zu den Anforderungen

3.3 Fachkonzept

3.3.1 Konfiguration einer Debug Session

3.3.2 Der Eclipse Launch Dialog

3.3.3 Bedienung während des Debuggens

3.3.4 MDB Status View

4 Systemarchitektur

4.1 Millicode Emulator Erweiterung

4.1.1 Anbindung neuer Funktionen an bestehenden MCE-Code

4.1.2 Kommunikationsschnittstelle und Kommunikationsprotokoll

4.1.3 Konzeptueller Paketaufbau

4.2 Millicode Debugger Eclipse Plug-ins

4.2.1 Aufteilung in mehrere Plug-ins

4.2.2 MDB Core Plug-in

4.3 Architektur der Connector-Schicht

4.3.1 Lösungsalternativen bei der Umsetzung des Connectors

4.3.2 Wahl der Connector-Architektur

5 Vorgehensmodell

5.1 Selektion von Methoden aus dem “Methodenbaukasten” des Agile Developments

5.2 Beschreibung des entworfenen Entwicklungsprozesses

6 Konzepte und Implementierungsdetails ausgewählter Features des Millicode Debuggers

6.1 MDB Launcher

6.1.1 Das Eclipse Launching Framework - Eine kurze Einführung

6.1.2 Implementierung des MDB Launch Delegates

6.2 Software-Design der Connector-Schicht

6.2.1 Schnittstelle zwischen Connector und MDB Core Plug-in

6.2.2 Kommunikationsablauf

6.2.3 Source Lookup

6.3 Breakpoints

6.3.1 Überblick zu Breakpoint-Typen

6.3.2 Umsetzung von Breakpoints im MCE

6.3.3 Breakpoints im GDB Remote Serial Protocol

6.3.4 Eclipse Extension zur Erweiterung von Eclipse mit eigenen Breakpoint-Typen

6.4 Register im MDB

6.4.1 Definition des Registersatzes

6.4.2 Register über den GDB Server auslesen und schreiben

6.4.3 Behandlung der Register in der GDB Server Erweiterung zum MCE

6.4.4 Interne Repräsentation eines Registers im MDB Core Plug-in

6.4.5 Anzeige der Register

7 Ausblick und Reflexion

7.1 Ausblick

7.2 Reflexion

Zielsetzung & Themen

Das primäre Ziel dieser Bachelorarbeit ist die Entwicklung eines grafischen Debuggers für den IBM System z Millicode, welcher nahtlos in die Entwicklungsumgebung Eclipse integriert wird. Hierbei liegt der Fokus auf der Schaffung einer interaktiven Schnittstelle, die es Entwicklern ermöglicht, den bisher im Batch-Betrieb arbeitenden Millicode Emulator (MCE) effizienter zu analysieren, Fehler zu lokalisieren und den Programmlauf gezielt zu steuern.

• Integration einer interaktiven Benutzeroberfläche in Eclipse zur Millicode-Fehlersuche.
• Erweiterung des bestehenden MCE um eine Kommunikationsschnittstelle basierend auf dem GDB Remote Serial Protocol.
• Implementierung von Debugging-Funktionen wie Single Step, Breakpoints und Register-Manipulation.
• Entwurf einer modularen Drei-Schichten-Architektur zur Entkopplung von GUI, Connector und Emulator.
• Anwendung agiler Entwicklungsmethoden zur iterativen Verbesserung und Priorisierung der Features.

Auszug aus dem Buch

Zusammenfassung der Kapitel

1 Einleitung: Beschreibt das Umfeld der Arbeit bei der IBM, die Zielsetzung zur Entwicklung einer IDE-gestützten Umgebung für den Millicode und die aktuelle Problematik des Batch-Betriebs des Emulators.

2 Grundlagen: Erläutert die technischen Aspekte des System z Millicodes, des Millicode Emulators (MCE) sowie die Funktionsweise der Eclipse-Plattform als Basis für die Plugin-Entwicklung.

3 Anforderungen und Fachkonzept: Definiert die funktionalen Anforderungen an den Debugger und beschreibt das Bedienungskonzept innerhalb der Eclipse-Oberfläche sowie die Status-View.

4 Systemarchitektur: Detailliert die modulare Drei-Schichten-Architektur des Debuggers und die notwendigen Erweiterungen am MCE sowie die Wahl der GDB-basierten Kommunikationsschicht.

5 Vorgehensmodell: Beschreibt den agilen Entwicklungsprozess, der aus Methoden von SCRUM und Extreme Programming abgeleitet wurde, um auf Stakeholder-Feedback reagieren zu können.

6 Konzepte und Implementierungsdetails ausgewählter Features des Millicode Debuggers: Bietet tiefgehende Einblicke in die Implementierung des Launchers, des Connector-Designs, der Breakpoint-Verwaltung und der Register-Zugriffe.

7 Ausblick und Reflexion: Fasst die Ergebnisse der Arbeit zusammen, bewertet das erreichte Ziel einer einsatzfähigen Debugger-Lösung und gibt einen Ausblick auf zukünftige Erweiterungsmöglichkeiten.

Schlüsselwörter

System z, Millicode, Debugger, Eclipse, MCE, GDB Remote Serial Protocol, Plugin-Entwicklung, Softwarearchitektur, Agile Entwicklung, Breakpoints, Registerverwaltung, Connector, Emulation, Firmware, Java

Häufig gestellte Fragen

Worum geht es in der Arbeit grundsätzlich?

Es geht um die Entwicklung eines grafischen Debuggers für den IBM System z Millicode, der direkt in die Eclipse-Entwicklungsumgebung integriert wird.

Was sind die zentralen Themenfelder?

Die Themen umfassen System z Firmware, Eclipse-Plugin-Programmierung, Emulator-Erweiterung sowie die Implementierung einer Kommunikationsschicht zwischen Java-UI und C-basiertem Emulator.

Was ist das primäre Ziel der Arbeit?

Das Ziel ist der Übergang von einer batch-basierten Fehlersuche hin zu einer interaktiven Debugging-Lösung, um die Entwicklungseffizienz bei der Millicode-Wartung zu steigern.

Welche wissenschaftliche Methode wird verwendet?

Es wird eine modulare Software-Architektur entworfen und nach einem agilen Vorgehensmodell (angelehnt an SCRUM) implementiert, um Stakeholder-Feedback kontinuierlich zu integrieren.

Was wird im Hauptteil behandelt?

Der Hauptteil gliedert sich in die Anforderungsanalyse, das System-Fachkonzept, die Architekturplanung (Drei-Schichten-Modell) sowie die spezifische Implementierung von Features wie Launch-Dialogen, Breakpoints und Registerzugriffen.

Welche Schlüsselwörter charakterisieren die Arbeit?

Millicode, Eclipse, Debugger, System z, MCE, Connector, GDB-Protokoll und agile Entwicklung sind die zentralen Begriffe.

Warum wurde das GDB Remote Serial Protocol gewählt?

Es bietet ein standardisiertes, erprobtes Format für die Kommunikation zwischen Debugger-Client und Server, was die Flexibilität erhöht und die Wartbarkeit des MCEs durch Wiederverwendung bewährter Konzepte sichert.

Welchen Vorteil bietet die modulare Architektur?

Sie ermöglicht eine klare Trennung zwischen Benutzeroberfläche und Connector, wodurch der Debugger wartungsfreundlicher wird und zukünftige Änderungen am Emulator oder der IDE mit geringerem Aufwand möglich sind.