SPC System Programming C

Transkript

1 SPC System Programming C SPC System Programming C Lahnstein GSE z/os 91 Tomasz Cieplak DB Systems GmbH

2 Agenda Vorstellung System Programming C C Language Fakten Charakteristika Positionierung SPC Beschreibung Werkzeuge Editoren DSECT Beispiel - TWS Exit in DB Systems Problemdefinition Lösung 2

3 DB Systems GmbH Was wir tun Wir entwickeln und betreiben leistungsfähige IT-Systeme für den Reise- und Logistikmarkt sowie für branchenübergreifende Unternehmensabläufe 3

4 DB Systems GmbH Wo wir stehen Die DB Systems GmbH gehört zu den führenden IT-Service-Unternehmen in Deutschland (Lünendonk-Liste 2005) IT- und Management- Consulting Leistungen Consult: Beratung zu Strategien, Prozessen und Strukturen Hosting- und Application-Services IT Full Service Business Solutions Design: Gestaltung und Optimierung von IT-Architekturen und Prozesslandschaften Build: Realisierung, Integration und Weiterentwicklung von Software-Applikationen Infrastructure- und Desktop-Services Operate: Rechnersteuerung, Netz- und Systemüberwachung, Betrieb peripherer Geräte Maintain: Wartung und Pflege von Software- und Hardwaresystemen 4

5 Fakten über The C programming language Entwickelt in 1972 durch Dennis Ritchie; Nachfolger von B, de facto BCPL (Basic Combined Programming Language) Adaptiert als Assembler für die UNIX Betriebssysteme und dessen Derivate; Compiler für eine breite Palette von Prozessoren von 8 Bit embedded Systems bis zum Mainframe. Für das IBM MVS System mindestens seit Anfang der 80er Jahre; Nachfolgende Sprachen von C++ bis JAVA Bild Quelle: 5

6 Charakteristik von C Language POINTER und deren Arithmetik - Beispiel struct psa* p_psa = (struct psa*)0; /*ptr to Prefixed Save Area */ printf("jn = %s \n",p_psa->psatold->tcbtio->tiocnjob); Eine Reihe von Operatoren, die es erlauben Programme kompakt zu schreiben ++; --; +=;. Conditional Anweisung ( )? x: y; z.b. rc=(rc>12)?rc:12; Intensive Nutzung von nicht alphabetischen Symbolen { } [ ] \ ; 6

7 Charakteristik von C Language Daten Strukturen und Eigene Datentypen z.b. #define BUFLEN 120 typedef struct variable { struct variable *next; int name_len; /* len of name part */ int value_len; /* len of value part */ char buff[buflen+1]; /* buffer for name & value */ } TWSCTM_VAR; 7

8 C Language - Positionierung Fortran; Cobol ; PL/1 LE - Language Environment C Assembler 8

9 SPC: System programming C Fortran; Cobol ; PL/1 LE - Language Environment C SPC - System programming C System Exits Assembler 9

10 Fakten über SPC SPC ist ein Teil des z/os XL C/C++ (5694-A01) Produktes; Es ist dokumentiert in z/os V1R8.0 XL C/C++ Programming Guide (SC ), in Kapitel 40 Using the system programming C facilities und XL C/C++ Run-Time Library Reference (SA ); SPC Programme & Exits laufen in einer eigenen Laufzeitumgebung, (nicht unter LE); Man kann SPC als Alternative für ASSEMBLER, besonders für System Exits, betrachten; Man kann Applikationen entwickeln, die nur einmal eine Laufzeitumgebung erzeugen, und diese mehrfach nutzen; SPC ist mit vielen Restriktionen verbunden. Die wichtigsten davon sind: Keine C++ Sprachelemente sind erlaubt, z. B. Kommentarzeile mit // ; Keine Unterstützung für HFS (USS Files); Nicht 64 Bit fähig; SPC bietet aber auch eigene systemspezifische Funktionen z.b. xregs() Get Registers on Entry 10

11 Editoren 3270 Green Screen ; Syntaxhiliting in Farbe mit HILITE C IBM C/C++ Productivity Tools for OS/390 Nur ein Release vor Keine Synchronisation zwischen Host und Workstation Dateien Notepad ++ Autor Don HO GNU General Public Licence Eclipse OpenSource. Durch IBM stark favorisiert. C/C++ Plugin ist notwendig NetBeans OpenSource. SUN favorit WDz - WebSphere Developer for System z Ein Mercedes. Die Host Dateien können auf dem Host liegen IBM C/C++ Tools Notepad ++ Eclipse NetBeans 11

12 DSECT Utility Programm Mit Hilfe des DSECT Converion Utility man kann ASSEMBLER Dummy Sections DSECT als C Strukturen abbilden. Die Strukturen der Systemkontrollblöcke, die in Assembler Makro Bibliotheken definiert sind, sind dann auch für C Programme zugängig. DSECT nimmt als Input die ADATA Datei die ein Assembler Compiler schreibt. Achtung: Das SYSDATA Layout, dass HLASM 1.5 schreibt, wird aktuell durch C/C++ Version nicht unterstützt! Man muss einen extra Exit für HLASM kompilieren und beim Aufruf als Parameter übergeben. In sämtlichen Fällen ist die manuelle Nacheditierung notwendig und sinnvoll, aber es ist deutlich einfacher als die Eingabe vom SCRATCH. 12

13 Beispiel - Eingabe und Ausgabe aus dem Dsect Utility Assembler Input DSECT C output sturcture *************************************************************** * WORK AREA DSECT *************************************************************** STATWORK DSECT, SAVEAREA DS 18F SAVE AREA THISUSER DS CL8 THIS USER ID PARMPTR DS A POINTER FOR MVS CALLS ECBADS DS F CMD PROCESSOR ECB STATWLEN EQU *-STATWORK LENGTH OF LOCAL STORAGE AREA struct statwork { int savearea[18]; /* SAVE AREA */ unsigned char thisuser[8]; /* THIS USER ID */ void *parmptr; /* POINTER FOR MVS CALLS */ int ecbads; /* CMD PROCESSOR ECB */ }; 13

14 Anwendung von SPC bei der Migration des Job Schedulers CONTROL_M nach TWS bei der DB Systems Im Jahr 2002 (nach Einführung der IBM Z900 Systeme) hat sich die DB Systems entschieden den Job Scheduler CONTROL-M durch TWS 8.1 zu ersetzen. Ein Job Scheduler besteht in der Regel aus zwei Teilen: Jobnetz Definitionen und Verwaltung sowie JCL Makrogeneratoren, die z.b. datumsabhängige Jobdefinitionen generieren Eine Analyse zeigte, dass: mit Hilfe von OMA (OPC Migration Aids) die Migration von Contol-M Jobnetzen nach TWS nicht einfach ist, aber möglich; Umstellung von Jobdefinitionen, die mit Hilfe der Control-M Auto Edit JCL Erweiterungen erstellt sind, sind, je nach Umfang, innerhalb von ein paar Monaten unmöglich. Siehe Beispiele. P804fcha.txt P502relo.txt 14

15 TWS Exits als Lösung dieses Problems Die einzige Chance dieses Projekt in der vorgesehenen Zeit durchzuführen war das TWS so zu erweitern, dass es die Contol-M Variablen versteht und dynamisch auflöst. TWS bietet dafür einige Exits an. Der Exit 1 (Submit) wird durch den TWS Controller kurz vor der Submit Operation aufgerufen. Als Parameter bietet er ein Feld mit JCL (nach Auflösung der TWS Variablen) und ein zweites Feld, in dem die vom Exit modifizierte JCL steht. Es gab eine Möglichkeit die Control-M Variablen auch dynamisch aufzulösen. Die Entwicklung eines Contol-M Auto-Edit Funktion Interpreters innerhalb knapper Zeit in ASSEMBLER Sprache war auch nicht möglich. Auf Grund meiner C Erfahrungen hatte ich gezielt nach der Möglichkeit gesucht, den TWS Exit 1 in dieser Programmiersprache zu schreiben und ich habe den SPC gefunden. Das war die Lösung 15

16 Die Simulation der Auflösung der Auto-Edit CTM Variablen Zu Control-M gehört das Utility Programm CTMAESIM Auto-Edit Simulator. Mit Hilfe dieses Programms kann man in der JCL die Auto Edit Variablen für simulierte geplante und reale Laufdaten auflösen (endgültige JCL generieren). Wir haben uns entschieden die Control-M Variablen Interpreter Engine, die als DOLINE Routine programmiert ist, in zwei Umgebungen einzubetten. Eine Variante ist das SPC Programm TWSAESIM, die den Control-M Simulator nachmacht. Diese Variante ist freestanding. Die zweite Variante ist als Exit realisiert. Wir haben nun eine Möglichkeit alle für unsere Produktion relevanten Jobs (JCL Member) des alten (Contol-M) mit dem neuen Job Scheduler (TWS mit submit Exit) zu vergleichen. Die Entwicklung der DOLINE Funktion ist so lange gelaufen, bis die Ausgangsdateien sich nicht mehr unterschieden. Es sind auch unerwartete ( fehlerhafte) Situationen in Control-M entdeckt worden. Dank klarer C Programmstruktur war es möglich auch diese Fehler nachzuprogrammieren. Performance! Die in SPC geschriebene Version war in beiden Kategorien, CPU Zeit und Laufzeit (Start-Stopp), deutlich schneller als das Original ( Assembler?)!!! 16 Compr2.jcl

17 TWS Exits - Beschreibung Die online Lösung mit dem Control-M Auto-Edit Variable Interpreter ist als SPC Programm mit einmal initialisierter und mehrfach benutzter Laufzeitumgebung realisiert worden. TWS bietet ein 4 Byte Feld MCAUSERF in Parameterlisten, das in allen Exits vorhanden ist. Ich habe dieses Feld benutzt um die Laufzeitumgebung Handle in Exit 0 zu generieren, (call des EDCXHOTL SPC Moduls) und in Exit 1 immer wieder benutzt. Beim Runterfahren von TWS wird das Modul EDCXHOTT zur Freigabe des Runtime Environment benutzt. Der Assemblerteil des Exits 1 ruft ein SPC Modul EDCXHOTU mit einer Parameterliste auf, welche folgendes beinhaltet: die Laufzteitumgebung Handle vom User Field; die Entry Point Address der SPC Routine EQQUX01P und die Adresse der Exit 1 Parameterliste. Die erste C Routine EQQUX01P bereitet den Anruf der DOLINE Funktion vor. Inzwischen sind auch andere Funktionen realisiert, wie die Zuteilung von Berechtigungen in MVS und E2E Umgebungen oder revisionssichere Parameter in der JOB Karte. 17

18 Fazit Innerhalb des z/os Betriebssystems wird die Programmierung von Exits (SMF, JES, User Exits,...) und vom systemnahen Komponenten mit Assembler assoziiert. System Programming C als Programmiersprache mit seiner schlanken, an die Systemsbedürfnisse angepassten Laufzeitumgebung, bietet hierzu eine gute Alternative die man in Betracht ziehen sollte. Ich hoffe, dass das präsentierte Beispiel des TWS Exits diese These beweist. 18

19 Vielen Dank für Ihre Aufmerksamkeit Dr. Tomasz Cieplak Systemtechnik (D.IOP31) DB Systems GmbH Hahnstr Frankfurt am Main Tel.: Mobil: