java auf system z - amazon s3 · (db2-z/os) cobol upro z/os java upro cobol upro java upro ims - db...

Java auf System z

Überblick Infrastruktur, Betrieb und Erfahrungen

Ziel dieses Vortrags

§ Technische Darstellung „Warum untersuchen wir Java am Host“ – Bei Java pure – Bei Cobol/Java Mix unter IMS

§ Überblick der infrastrukturellen Anpassungen/Erweiterungen unserer Betriebslandschaft– Für Java Batch Jobs– Für den Betrieb von „Java enabled IMS-Online Regions“

JavaZ Überblick/Infrastruktur | Pascal Meyer, Alexander Trischler | JBFOne 2011 | Seite 2 Copyright 2010 © Fiducia IT AG

§ Einblick in die Technologie aus Entwicklersicht anhand unserer Prototypen – ein Java-pure-Job am Host,– eine IMS-Transaktion im Java-Cobol MixedMode

§ Ausblick über die weitere Vorgehensweise

Agenda

§ Motivation Java und Java/Cobol am Host aus Techniksicht

§ Erweiterungen für Java-Batch

§ Erweiterungen für IMS-Java



§ IMS-Online: Java- und Cobol-Zusammenspiel aus Entwicklersicht

§ Fazit/Zusammenfassung

§ Batch: Ein JZOS-Beispiel aus Entwicklersicht

„Warum setzen wir auf „Java am Host“ aus Techniksicht?

§ Der aktuelle Stand der Entwicklung von Java unter z/OS hat die Fiducia IT AG dazu veranlasst zu prüfen, ob diese Technologie für die Fiducia Vorteile bringt– Die neue IBM-Hardware bietet die notwendigen Ressourcen für den parallelen Betrieb

einer großen Anzahl von Java-Anwendungen– Ein Großteil der Java-Workload kann auf zIIPs ausgelagert werden – damit können

Java-Anwendungen MIPS-verträglich betrieben werden– Die Verarbeitung von Java und Cobol in derselben Region ist möglich. Programme

beider Sprachen können sich gegenseitig aufrufen und in einer Transaktion laufen


beider Sprachen können sich gegenseitig aufrufen und in einer Transaktion laufen– Der technologische Reifegrad der dazu notwendigen Software (JVM, Debugger,

Profiling) ist inzwischen gut

Von der Verwendung von Java unter z/OS erwartet man für die Fiducia IT AG Vorteile in Entwicklung und Betrieb

§ Plattformsprünge in Verarbeitungen (Verarbeitung mit dezentralen Java-Batches und in Cobol implementierten Verarbeitungsschritten am Host) können vermieden werden

§ Durch die Ausführung von Java-Batchläufen auf dem Host können die Batchläufe "nahe" an die Daten gebracht werden

§ Plattformunabhängigkeit: Batchläufe können von dezentral nach zentral und umgekehrt verlagert werden


§ In Java entwickelte Fremdanwendungen können unter z/OS deployed werden (Beispiel: ERK)

§ Da Programme der beiden Sprachen untereinander aufrufbar sind, können COBOL-Programme sukzessive durch Java-Programme ersetzt werden (ohne Big-Bang)

§ In Java entwickelte Businesslogik kann zentral und dezentral eingesetzt werden. Die Doppelentwicklung von Businesslogik in Java und Cobol entfällt

§ Mitttels einer technologisch modernen Sprache ist es nun möglich, Anwendungen am Host zu erstellen, für die auch ausreichend Programmierer verfügbar sind

Mögliche Verwendung Java/Z im Batch Java Jobs können am Host ausgeführt werden

Sche

dule

rO

PC Batchjob …

§ Pure Java Jobs (JJs) – Können sowohl am Host als auch am

Server produziert werden – Plattformspezifika werden im Framework

gekapselt – Technische Basis auf z/OS: JZOS– „Compute Grid“ oder Alternativen evtl.

ergänzend für kleine Jobs


Batchjob (Java Main)

RDBMS(DB2-z/OS)z/OS

Java UproJava UproJava Upro

Files

ergänzend für kleine Jobs

§ Der Betrieb kann wahlweise entscheiden, auf welcher Plattform die Jobs produziert werden

§ JJs am Host dienen in erster Linie dazu, Abläufe aus Betriebssicht schlank und einfach zu halten

§ Prototyp: FU306A

Komplexität bei Batchabläufen – Plattform-übergreifende Abläufe sind komplex und werden daher wenig genutzt

1 HOST: CobolFachliche Verarbeitung

z/OS File2. HOST: FU306, LOB + Scheduling

4. DEZENTRAL: Java

Lob

1. Verarbeitung am Host

2. Aufbereitung der Daten für Verarbeitung auf der anderen Plattform, Ablage der Daten an der vereinbarten Stelle

3. (Scheduling: Host zu Unix)

4. Dezentrale Verarbeitung: inklusive fachliche Verarbeitung

INPUTDB


6: HOST: FU306, LOB

4. DEZENTRAL: JavaFachliche Verarbeitung

z/OS File7 HOST: CobolFachliche Verarbeitung

Lob

Verarbeitung1. Einlesen File oder Blob inklusive Codepage-

Konvertierung2. Aufbereitung für Folgeverarbeitung am Host

(Codepage-Konvertierung und Ablage in File oder blob)

5. (Scheduling: Unix zum Host)

6. Aufbereitung der Daten für Verarbeitung auf der originären Plattform, Ablage der Daten an der vereinbarten Stelle

7. Weitere Verarbeitung am Host OUTPUTDB

Komplexität bei Batchabläufen: Die Verlagerung des dezentralen Teils (Pure-Java) auf den Host bringt schon eine Vereinfachung

I. HOST: CobolFachliche Verarbeitung

z/OS File

§ Die dezentrale Verarbeitung wird auf den Host verlagert (Verarbeitungsschritt 4 auf voriger Folie)

§ Die Verarbeitungsschritte 2, 3 und 5, 6 entfallen

§ Es besteht keine Notwendigkeit mehr, Daten über Plattformgrenze zu verschieben …

§ Der Verarbeitungsschritt 4 wird bei Bedarf angepasst, damit er mit den bestehenden Host-Files zurechtkommt II. HOST: Pure-JAVA

INPUTDB


Files zurechtkommt

§ Der Ablauf wird einfacher – weniger Schritte– Scheduler-Kopplung entfällt

§ Der Ablauf verbraucht insgesamt weniger Ressourcen– Umformatieren entfällt – Zwischenspeichern entfällt – Zugriff übers Netz entfällt

§ Aus Gesamtlaufzeitbetrachtung (elaps) wird der Ablauf schneller (bei passender Checkpoint Frequenz auf DBs …)

II. HOST: Pure-JAVAFachliche Verarbeitung

z/OS File

III. HOST: CobolFachliche Verarbeitung OUTPUT

DB

Cobol Java Mix: die Transaktionsklammer macht es erst schmackhaft

§ Cobol zu Java Parameter Übergabe: – Wie funktioniert das?– wie wird aus einer Copystrecke ein java

Object

§ Datenbank-Zugriffe:– Wie sieht es mit Datenbank-Zugriffen aus? – Wie wird der Mix unterstützt?

Cobol Programm

Java U-ProgrammKundeÄndern

1. Kunde ändern

2. Protokollieren

Update


RDBMS(DB2-z/OS)

z/OS

2. Protokollieren

Kana

l-N

eutra

l/

spez

ifisc

h

Mögliche Verwendung Java/Z OnlineIMS-Transaktionen beinhalten Java Services

JBF-Service

Clie

nt

BAP …

JBF Backend

§ JBF-Services am Server decken nicht die ganze Bandbreite der Technologie ab, die bei der Weiterentwicklung von agree benötigt wird. So kommt es häufig vor, dass Funktionalität als klassische Host-Transaktion (IMS-Cobol) implementiert wird

§ Zukünftig besteht die Möglichkeit, diese Funktionalität auch in Java zu


IMS Transaktion (Cobol Hauptprogramm)

RDBMS(DB2-z/OS)

Cobol Upro

z/OS

Java UproJava UproCobol Upro

IMS - DB

JBF Backend Communication

Funktionalität auch in Java zu implementieren

§ Prototyping (FU075): Payload Compression

Mögliche Verwendung Java/Z im Batch bestehende Batch Jobs können Java Services verwenden

Sche

dule

rO

PC Batchjob …

§ Write once, use everywhere: neue Java-Funktionalität kann zukünftig auch in bestehende Cobol Batchprogramme eingebunden werden


RDBMS(DB2-z/OS)z/OS Files

BMP Programm (Cobol Hauptprogramm)

Cobol Upro

Java UproJava UproCobol Upro

IMS - DB

Agenda








Java pure im Batch: Infrastrukturellen Anpassungen

§ Die Verprobung erfolgte an zwei Prototypen– Der ERK der ParcIT ist seit Februar im Parallelbetrieb produktiv – FU306: Die für "Nizza – Daten entgegennehmen" notwendige Funktionalität ist

implementiert und in Betrieb genommen

§ Die wichtigsten betriebsrelevanten Aspekte – z/OS Systeme wurden zur Unterstützung zAAP over zIIp erweitert– Standards/Namenskonventionen-Erweiterungen


– Standards/Namenskonventionen-Erweiterungen– Unix Filesysteme für Java-Programme, für Temp-Arbeitsplatz, für Logging– Security-Konzept ist abgeschlossen und umgesetzt– Überwachung & Alarmierung – Accounting (SMF basiert)-Erweiterung. Anpassungen am Verfahren sind erfolgt, z. B.

Auswertungen, die den Java-Ressourcenverbrauch aufzeichnen

Java pure im Batch: Infrastrukturelle Anpassungen

§ Entwicklung & Verwaltung von Programmen (Jarfiles) für Eigenentwicklung und Fremdsoftware– Entwicklung erfolgt dezentral mit

bestehenden Mitteln (RAD/RDZ)– Provisionierung Host-Transfer-Laufwerk

aus Build– Übergabe-/Übernahmeverfahren werden


– Übergabe-/Übernahmeverfahren werden mittels erweitertem Hostverfahren (PUU) realisiert

§ Interaktion mit dem Host auch notwendig z. B. bei Fehleranalyse – Entwickler muss ins „Host Log“ (JCL

Output) schauen– Kann am Host testen und debuggen mit

den bekanten Mitteln

Agenda









IMS-Java: die JVM ist persistent in den IMS-MPRs eingebettet

IMS MPR mit JVM 1.6 - 31bit

IMS Connect,

MQ,

…

LE Enclave

JVM : C-Programme Cobol -Pgm

Cobol -Pgm


Java-User-Code…

Infrastruktur: IMS Enabling für einen gezielten Einsatz von Java

§ Zwei zusätzliche Parameter in den MPR-Definitionen– Link zu den binaries: JVMOPMAS=DFSJVM61,


– Konfig: ENVIRON=DFSJVC35

IMS-Java: aktive JVM in IMS-MPRs Voraussetzungen und Nebenwirkungen

§ Die Aktivierung der JVM erfordert neue LE-Einstellungen– Posix (on), all31(on)– Alle Programme amode31– Alle Cobol-Module mit EnterpriseCobol compiliert

§ IMS/LE/JVM setzt voraus, dass alle Module IGZERRE unterstützen. Dies ist aktuell bei unseren hochvolumigen Transaktionen der Fall– Die aktuelle IMS-Implementierung deckt noch nicht alle Konstellationen ab


– Die aktuelle IMS-Implementierung deckt noch nicht alle Konstellationen ab– Der gemeinsam konzipierte Lösungsansatz befindet sich seitens IBM in der

Umsetzung

§ Die Defizite bei den aktuell verwendeten Debugging- und Abend-Handling-Werkzeugen von Compuware verhindern deren Einsatz.– Xpediter kann nicht eingesetzt werden (bekommt keine Kontrolle)– AbendAid kommt mit der LE-Einstellung „posix(on)“ nicht zurecht– Compuware ist bemüht eine Lösung zu finden – DebugTool und FaultAnalyzer aus der IBM-PDT-Suite wären eher geeignet

Infrastruktur: Globale Auswirkungen bei Breiteneinsatz

Die Verwendung von Java führt zur Veränderung der Infrastruktur. Die Hardware muss auf die neuen Belange ausgelegt werden

§ Der Java Workload wird auf zIIP-Prozessoren ausgelagert– Aktivierung weiterer CPUs einplanen

§ Auch der Speicherbedarf verändert sich– Mehrbedarf-Prognose und bei Bedarf Erweiterung vorsehen


– Mehrbedarf-Prognose und bei Bedarf Erweiterung vorsehen

§ Monitoring

Agenda









Pure JavaJava-Batch

JZOS

§ JZOS ist ein Programmpaket für den Support der z/OS-Spezifika für Java

§ Zu JZOS gehören– Batch-Runner

• Unterstützt den Start einer JVM unter Job-Control-Language• Mappt den Java-Exit-Code auf den System Returncode


• Mappt den Java-Exit-Code auf den System Returncode• Lenkt den Java out-Stream auf SYSOUT

– Klassenbibliothek• IO-Klassen für z/OS-Dateien (PS, PO)• Klassen für DFSort unter Java• Mapping-Framework für Copystrecken nach Java-Datentypen

JZOS Job - Sample

//JAVA EXEC PROC=PROC6SR8,VERSION='60',// JAVACLS='de.basisagree.lobtab.service.impl.batchjob.LobChecker',// ARGS='MOD13_JBF00 compareDefault'

//STDENV DD DISP=SHR,DSN=XCK10.JAVA.CNTL(JDK1601)// DD *# JUNIT und Compression ergänzenAPP_HOME=/mvsr/home/xk07210


APP_HOME=/mvsr/home/xk07210CLASSPATH="$CLASSPATH":"$APP_HOME/FU306.jar"CLASSPATH="$CLASSPATH":"/entw/appl/imsu/jbf/lib/ojdbc14.jar"CLASSPATH="$CLASSPATH":"$APP_HOME"export CLASSPATH="$CLASSPATH":/*//E0000S1 DD *<EmpfaengerCustom_ID="0000008603"Path="/horizon/zvaus"FileName="zvaus.ezv.0000008603.d20110926.t12413228000.txt"DSName="PC265K.F7149L2.WR2.IMSQTDBO.ZV25.D260911.L07"/>

Support von z/OS-Dateien

Die JZOS-Klassenbibliothek unterstützt die unterschiedlichen z/OS-Dateitypen

§ So kann mittels ZFile von einem DD-Statement gelesen werden:


Java-Pure Batch: FU306 Oracle-Lob Filetransfer

§ Für die Pilotierung eines Java-Batches wurde die Oracle-Lob-API FU306A ausgewählt

§ Um Aufwand zu reduzieren, wurden allerdings in der ersten Stufe nur Teile der Funktionalität von FU306A in Java reimplementiert


reimplementiert

§ Die Java-Implementierung läuft aktuell parallel zur produktiven Cobol-Implementierung. Die Ergebnisse werden maschinell verglichen

§ Als Ziel wollen wir ein Gefühl dafür bekommen, wie sich Java auch für kleine Batches eignet. Besonderes Augenmerk liegt auf den „Rüstzeiten“ für den JVM-Start bei Leer-Datei-Verarbeitung

Agenda









Java<->CobolInterlanguage-Communication (ILC)

Die Aufrufe von Cobol nach Java und Java nach Cobol unterscheiden sich geringfügig in der Art der zu verwendenden Technik. Die Mechanismen der Datenübergabe und Konvertierungen sind aber auf Basis von JNI prinzipiell gleich

§ Cobol à Java– Der Aufruf der Java-Methode erfolgt über OO-Cobol-Spracherweiterung– Java kann nur aus DLLs gerufen werden– DLLs können aber nicht dynamisch aus Cobol gerufen werden


– DLLs können aber nicht dynamisch aus Cobol gerufen werden

§ Java à Cobol– Java kann nur eine in OO-Cobol-implementierte Klasse aufrufen– Diese Klasse muss zu einer DLL gelinkt sein– Eine DLL kann aber keinen dynamischen Call auf ein Unterprogramm machen

Cobol ruft Java

Die Konventionen der DLL erfordern kleine Klimmzüge

§ Um die Sprachübergänge in Richtung Java mit dynamischen Calls zu unterstützen verwenden wir statisch gelinkte OO-Cobol-Stubs– Ein kleines Cobol-PGM, das nur den Cobol-Stub

CALL „OO-

Cobol-PgmCALL Cobol-Stub

DynamischerCall


– Ein kleines Cobol-PGM, das nur den statischen Call der OO-Cobol DLL beinhaltet, wird zu einem Lademodul zusammengelinkt

– Dieses Lademodul kann mittels dynamischer Calls gerufen werden

Java-LibraryXY.jarJava-LibraryXY.jar

OO-CobolInvoke …

CALL „OO-COBOL“

StatischerCall

Cobol ruft Java – Cobol Stub und OO-Cobol

Der Cobol-Stub ist keine Hexerei


Ein OO-Cobol-PGM sieht etwas anders aus

Beispiel: Aufruf einer Java-Methode aus CobolDie Java-Methode

CompressionWrapperCompressionWrapper


Der zugehörige Cobol-Aufruf (1)FU382IFU382I

1. Neues Byte-Array anlegen


2. Daten aus Cobol in das Byte-Array in die JVM übertragen

Der zugehörige Cobol-Aufruf (2)FU382IFU382I3. Aufruf der Methode compress()


4. Ergebnis aus der JVM nach Cobol übertragen

Java ruft Cobol

In dieser Richtung muss mit zwei Stubs gearbeitet werden

§ Die Java-Klasse nutzt einen Java-Stub, um den Aufruf der „Cobol-Methode“ zu ermöglichen

§ Der Java-Stub entsteht beim Cobol-Compile!

Java-Klasse

Java-Stub


§ Um dynamische Calls aus der OO-Cobol Methode in Richtung „klassischem Cobol“ zu unterstützen, greifen wir auch hier auf den Trick mit der statisch gelinkten Stub zurück

Cobol-PGM XYCobol-PGM XYCobol-StubCall XY

OO-CobolCALL „Cobol-Stub“

Dynamischer Call

StatischerCall

Java ruft Cobol, OO-CobolEine Klasse muss mit Methoden in Cobol geschrieben werden

§ Im Beispiel links wird eine Klasse mit einer Methode display(byte[]) dargestellt

§ Beim Cobol-Compile wird der Java-Stub erzeugt:


Cobol-Compile

Datentypen und Konvertierungen

Zugeständnisse an die Performance und die Nerven der Entwickler haben zu folgenden Vereinbarungen geführt

§ Folgende Datentypen werden zwischen Cobol und Java ausgetauscht:– int, long, byte[]– Komplexe Daten werden auf Basis von Copy-Strecken mittels byte[] ausgetauscht

§ Das Mapping der Copy-Strecken auf die Java-Objekte erfolgt immer in Java


§ Das Mapping der Copy-Strecken auf die Java-Objekte erfolgt immer in Java

§ Ebenfalls werden die Konvertierungen von Ebcdic nach Unicode auch immer in Java durchgeführt

FU075U Prototyp/Komprimierung

§ JBCImsConnect komprimiert die Daten bevor sie zum IMS geschickt werden

§ Als Gegenstück werden die Daten von dem Gegenstück auf dem Host (FU075U) dekomprimiert. Die Komprimierung erfolgt in beiden Richtungen

§ Der zugehörige Komprimierungsalgorithmus wurde im Rahmen von BAP4.0 sowohl in


§ Der zugehörige Komprimierungsalgorithmus wurde im Rahmen von BAP4.0 sowohl in Java als auch in Assembler implementiert

§ Aus diesem Umstand resultiert die Idee, die in Assembler implementierte Komprimierungsroutine durch die Java-Implementierung zu ersetzen und prototypisch zu einzusetzen

Unser FU075U Prototyp/Komprimierung

§ Ausgangslage: Implementierung der Komprimierung in Assembler

XY001T

(Anwendungs-PGM)

FU075UIMS I/O Queue


FU075C FU075D

Ausgangslage FU075U Compression

Unser FU075U Prototyp/Komprimierung

§ Implementierung Komprimierung in Java

XY001T

(Anwendungs-PGM)

FU075UIMS I/O Queue


FU075C FU075D FU382I

CompressionWrapper

JESCompressor JESDecompressor

Compression-service-api__VX.YY-ZZ.jarCompression-service-impl__VX.YY-ZZ.jar

Agenda









Fazit/Zusammenfassung

§ In Bezug auf Java pure unterscheidet sich der Host nicht von anderen Plattformen

§ Java pure ist mittlerweile eine echte Variante und Ergänzung des Portfolios – Der Betrieb von Java auf Z kann einen erheblichen Mehrwert im Sinne von Einfachheit

der Abläufe, Durchlaufzeit und Wiederverwendung von Code und Skill erbringen

§ Es gibt noch einige Hürden beim Cobol/Java Mix unter IMS, die vor einer Nutzung gemeinsam mit dem Hersteller zu beseitigen sind


gemeinsam mit dem Hersteller zu beseitigen sind

Fragen? – Diskussion?

Alexander TrischlerFiducia IT AG


Fiducia IT AG

[email protected]/4004-5139

Pascal MeyerFiducia IT AG

[email protected]/4004–2834

mailto:[email protected]

mailto:[email protected]

Ihr IT-Partner

Vielen Dank

java auf system z - amazon s3 · (db2-z/os) cobol upro z/os java upro cobol upro java upro ims - db...

Documents