Chef, wir haben den Mainframe geschrumpft. RDz Unit Test Environment: Mainframe-Entwicklung ohne Mainframe?

Transkript

1 Chef, wir haben den Mainframe geschrumpft Unit Test Environment: Mainframe-Entwicklung ohne Mainframe?

2 Agenda Was ist eigentlich? Architekturszenarien Systemvoraussetzungen Lizenzierung Demo Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 2

4 Einschränkungen in der Mainframe-Entwicklung heute Die Bereitstellung eines Testsystems dauert bis zu zwei Tagen. Wie kann ich ohne Konsequenzen neue CICS Versionen testen? Das Testen von Applikationen ist nur zu Offline-Zeiten möglich. Online -Anwendungen verbrauchen zu viele Ressourcen zu Online-Zeiten Für junge Leute ist es schwierig, den Umgang mit dem Mainframe zu erlernen, da sie durch Systemrestriktionen, wie z. B. RACF Definitionen, eingeschränkt werden. Um weitere Ressourcen zum Testen am Mainframe bereit zu stellen, haben wir kein Kapital verfügbar. Die Produktionsworkload ist Montags so hoch, dass effizientes Arbeiten kaum mehr möglich ist. Die Entwicklung auf dem Mainframe wird den modernen Ansprüchen junger Entwickler nicht mehr gerecht. Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 4

5 Mainframe-Entwicklungsumgebung der Status Quo ISPF user ISPF user ISPF user ISPF user ISPF user ISPF user Nachteile Konstante Verbindung mit dem Mainframe wird vorausgesetzt Parallele Nutzung der Mainframe-Ressourcen von Entwicklung und Produktivumgebung Die Entwicklung ist meist niedriger priorisiert ISPF green screen UI ist nicht sexy genug für junge Entwickler MIPS-Verbrauch für die Entwicklung vs. Produktivumgebung Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 5

6 Mainframe-Entwicklungsumgebung mit und ISPF user user ISPF user user ISPF user ISPF user Pluspunkte moderner IDEs Produktivitätssteigernd und verbesserte Attraktivität für junge Entwickler Auslagerung von Entwicklungsworkload und somit Senkung des MIPS-Verbrauchs Integration mit Application-Lifecycle-Tools und PDTools Verbleibende Punkte Zunehmender Druck, den MIPS-Verbrauch für die Entwicklung weiter zu senken Abhängigkeiten vom Host-Sysprog-Team können zu zeitlicher Verschiebung von Unit Tests führen Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 6 6

7 Das Unit Test feature Die neue Lösung für flexible Mainframe-Entwicklung COBOL, PL/I, C++, Java, EGL, Batch, Assembler, Debug Tool IMS WAS CICS DB2 MQ user user z/os x86 PC running Linux user ISPF user & ISPF user user Erhöhte Freiheit für Entwickler, neue Applikationen zu entwicklen Entwicklung und Testen von System z-applikationen zu jeder Zeit an jedem Ort! Kein Verbrauch von MIPS. Diese stehen somit der Produktivumgebung uneingeschränkt zur Verfügung Reduzierung von den Abhängigkeiten des Host-Sysprogs Vermeidung von zeitlichen Verzögerungen/Erhöhung der Kosten Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 7

8 Unit Test im Detail Das Unit Test Feature besteht aus RTCz Agent Unit Test System z S/W Stack Debug Tool CICS DB2 WebSphere/z Agent IMS Assembler COBOL C/C++ PL/I z/os Unit Test Environment (basierend auf dem zpdt) Unit Test Environment ist eine System z Entwicklungsplattform auf einem normalen PC ADCD Software stack (ist eine Auswahl von IBM Middleware Testumgebungen) aktuelle Middleware Software (incl. z/os) Aktuelle Enterprise Compilers keine API-Simulationen und RTCz agents -Lizenz wird zur Aktivierung benötigt Unit Test Environment x86 PC running Linux <USB License Key> Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 8

9 Der ADCD Software Stack z/os MLC Products IMS V10.1 Database Manager IMS V10.1 Transaction Manager DB2 for z/os V9.1 WS MQ Base for z/os V7.0 Enterprise COBOL V4.2 Enterprise PL/I z/os V3.9 CICS TS for z/os V4.1 CICS TS for z/os V3.2 z/os V1.11 Base z/os V1.11 C/C++ without Debug z/os V1.11 DFSMS dss z/os V1.11 DFSMS rmm z/os V1.11 DFSORT z/os V1.11 RMF z/os V1.11 SDSF z/os V1.11 Security Server z/os V1.11 ISPF (all sub features) z/os V1.10 Base (all sub features) z/os OTC Products WebSphere for z/os 7.0 DB2 Utilities Suite V9 WebSphere Portal Enable z/os Debug Tool Other Tools pre-installed RTCz file/build agents RSE and Job Monitor Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 9

10 Der Zündschlüssel oder auch das Dongle Unit Test wird mit dem USB Key aktiviert Steckt der Schlüssel, rennt das System Wird er herausgezogen, fährt es herunter USB key ist die User Lizenz Lizenziert für einen einzigen User oder Server Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 10

12 Build Wo wird der Build durchgeführt? Kompilieren: sowohl auf als auch Mainframe möglich Production builds sollten jedoch nur auf dem Mainframe stattfinden Wo sollte sich der Source Code befinden? es kommt darauf an (Designfrage). Daten können manuell, halbautomatisch oder automatisiert verschoben werden. Wie bekommt man die Daten in bzw. aus dem? drag and drop, FTP, sftp, XMIT, NFS, DFS, etc. Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 12

13 Architekturbeispiele Scenario Source Location Build Location Description Mainframe Build Mainframe Mainframe Build Output wird zu kopiert. Source updates auf dem Host Build Mainframe und Source wird auf kopiert und geändert (local development). Source muss zum Host SCM zurück übertragen werden Distributed Build Mainframe / und auch an anderen Stellen Abhängig vom SCM SCM bestimmt die Orte für Source und Build Lokation. Build Anfragen werden von, Host etc entgegengenommen. Outputs werden zum testen bereitgestellt Automatisiert die ersten zwei Szenarios. Am wenigsten anfällig für Synchronisationsfehler Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 13

14 Mainframe build Unit Test von Code, der auf dem Host gewartet wird Entwicklung des Codes auf dem Mainframe Kompilierter Code und benötigte Daten werden zum kopiert Testen auf dem Host Web Service Explorer CICS Host Connect MVS CICS Remote Projects RSE Client RSE Server MVS SCM Build tools Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 14

15 based build Entwicklung auf dem mit Host basiertem SCM Code und Daten werden auf das kopiert Kompilieren und debuggen mit Nach dem Entwickeln und Testen werden Änderungen auf den Host zurück übertragen Host Web Service Explorer CICS Host Connect MVS CICS Remote Projects RSE Client RSE Server Build tools MVS SCM Build tools Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 15

16 Distributed SCM and Build Entwicklung mit mit verteiltem SCM SCM verwaltet das Übertragen von Code von und zum Mainframe Builds entweder auf oder dem Mainframe Kompilieren und debuggen mit Host Web Service Explorer CICS Host Connect MVS CICS Remote Projects Rational Team Concert /z Client RSE Client RSE Server RTCz Miner RTCz Build Toolkit MVS RTCz Build Toolkit RTCz Server Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 16

18 host machine specifications Linux Plattform Red Hat Enterprise Linux 5.3 (RHEL 5.3) OpenSUSE 10.3, 11.0, and 11.1 Rechner benötigt mindestens 3 GB Hauptspeicher: 1 GB für die 64-bit Red Hat/OpenSUSE Linux 1-2 GB für System z (Abhängig von der Größe des Entwicklungssystems) mindestens 80 GB freien Festplattenspeicher Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 18

20 Lizenzierung Rational Developer for System z Unit Test ist in zwei Lizenzmodellen erhältlich Standard: für eine einzelne virtuelle Entwicklungsumgebung Für kleine Rechner (Entwickler-Workstation) Geeignet für die meisten System z Application-Tests wie Batch, CICS, IMS, DB2, COBOL, PL/I, and Assembler Specialty: für drei Unit Test Engines Geeignet für Server (mit mehreren Entwicklern oder spezieller Workload) Die drei Engines können zum Testen der Einsetzbarkeit des Codes auf zaap oder ziip konfiguriert werden Weitere Testmöglichkeiten, wie z. B. das Testen von Java, WebSphere und datenintensiveren Operationen mit DB2 Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 20

21 Standard vs. Specialty Beispiel Standard arbeitet nur mit einem (1) x86 core Specialty arbeitet mit drei (3) x86 cores Mehr cores mehr User, Workload, Performance, Multitasking etc. 1 CP Standard 3 CP Specialty assigned to assigned to 1 core 3 cores x86 x86 Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 21

22 Lizenzierungsbeispiele 10 Entwickler Konfiguration: Jeder will eigenes Empfehlung 10 1 für jeden Entwickler 10 Standard Lizenzen 1 für jeden Entwickler 10 USB keys 1 für jeden Desktop Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 22

23 Lizenzierungsbeispiel (Server) 20 Developers Konfiguration: 2 Server für 10 Users Empfehlung 20 1 für jeden Entwickler 20 Specialty Lizenzen 1 für jeden Entwickler 2 USB keys 1 für jeden Server Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 23

24 Lizenzierungsbeispiel (mixed) 10 Entwickler Konfiguration: 1 shared Server für alle 10 User 5 Desktop Installationen für 5 individuelle User Empfehlung 10 1 für jeden Entwickler 15 Lizenzen 10 Specialty (für server) 5 Standard (für desktop) 6 USB keys 1 für Server 5 für Desktop Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 24

25 Fragen? Diskussion? Tobias Braun IBM Deutschland GmbH Wilhelm Alexy AEW6SE 0 89 / Chef, wir haben den Mainframe geschrumpft Tobias Braun, Wilhelm Alexy JBFOne 2010 Seite 25

26 Ihr IT-Partner Vielen Dank