Mainframe Rehosting

Abstract

Zusammenfassung Das Mainframe Rehosting hat zum Ziel den bestehenden Mainframe durch einen Verbund von leistungsstarken UNIX Rechnern zu ersetzen. Damit sind erhebliche Kosteneinsparungen möglich. Dieser Beitrag zeigt, wann die Gewinnschwelle erreicht wird, welche Hersteller sich in diesem Markt bewegen und welches Vorgehen anzusetzen ist bevor man mit einem solchen Projekt startet.

Full text

Mainframe Rehosting
Elmar Klausmeier, Steria Mummert Consulting AG
14. August 2011
Zusammenfassung
Das Mainframe Rehosting hat zum Ziel den beste-
henden Mainframe durch einen Verbund von lei-
stungsstarken UNIX Rechnern zu ersetzen. Damit
sind erhebliche Kosteneinsparungen m¨
oglich. Die-
ser Beitrag zeigt, wann die Gewinnschwelle erreicht
wird, welche Hersteller sich in diesem Markt be-
wegen und welches Vorgehen anzusetzen ist bevor
man mit einem solchen Projekt startet.
1 Einleitung
Banken und Finanzdienstleister besch¨
aftigen sich
intensiv mit der Renditeoptimierung ihrer Anlagen
am Finanzmarkt. Die Darlehnsvergabe bei Banken
ist ebenfalls stark renditeorientiert. Der Rendite
wird allerdings beim Betrieb des eigenen Rechen-
zentrums nicht die Aufmerksamkeit geschenkt, wie
anderen Finanzanlagen. Dieser Beitrag zeigt, dass
die Abl¨
osung der Rechenanlagen vom Monopolan-
bieter erhebliche Einsparungen erbringt und zu an-
sehnlichen Renditen f¨
uhrt.
Beim Mainframe Rehosting wird der Mainf-
rame komplett durch einen Verbund aus UNIX
(ggf. Windows) Rechnern ersetzt. F¨
ur die Endan-
wender ¨
andert sich nichts. Die Entwicklerproduk-
tivit¨
at steigt, da die dezentralen Plattformen mit
modernen Entwicklungs- und Testwerkzeugen auf-
warten. Die Kosten werden signifikant gesenkt. Die
Performance der Anwendungen wird stark verbes-
sert. Die Auswahl an k¨
auflichen und freien Software
Produkten ist im UNIX und Windows Bereich er-
heblich umfangreicher als im Monopolbereich.
Statt von Mainframe Rehosting wird auch von
Replattforming, Mainframe Migration oder Mainf-
rame Replacement gesprochen.
Der besondere Charme von Mainframe Reho-
sting ist, dass im Gegensatz zu einer Neuentwick-
lung keine aufwendige Konzeptphase vonn¨
oten ist.
Das Rehosting Projekt startet direkt bei der Pha-
se Implementierung und k¨
urzt diese durch Verwen-
dung des bisherigen Quellcodes stark ab. Die In-
tegration mit modernen Technologien (C++, Java,
PHP, SOA, etc.) ist nach dem Rehosting besonders
einfach. Rehosting bietet auch eine L¨
osung f¨
ur das
Problem, dass erfahrenes und qualifiziertes Mainf-
rame Personal langsam knapp wird.
2 Kostenbetrachtung
Es seien KU>0 die Kosten f¨
ur UNIX und zwar f¨
ur
Hard- und Software und f¨
ur das Migrationsprojekt.
Es seien WH>0 die j¨
ahrlichen Wartungskosten
f¨
ur den Host und zwar Hard- und Software (Li-
zenzkosten), sowie einkalkuliert der Verkaufserl¨
os
der Host Anlage nach Projektende. Ferner bezeich-
ne WU≥0 die j¨
ahrlichen Wartungskosten f¨
ur UN-
IX, die nach Projektende anfallen. Von Interesse
ist der Fall WU< WH. Der Fall WU= 0 tr¨
ate bei-
spielsweise bei ausschließlicher Nutzung von freier
Software (open source) ein. Mit Twerde die Pro-
jektdauer in Jahren bezeichnet. Beispielsweise be-
deutet T= 1.5 eine Projektlaufzeit von anderthalb
Jahren. Die Variable tsei die Zeit.
Die Momentankosten f¨
ur UNIX sind dann
u(t) = KU/T +WH,f¨
ur 0 ≤t<T,
WU,f¨
ur t≥T,
und die Momentankosten f¨
ur den Host sind
h(t) = WH,f¨
ur t≥0.
Die UNIX Kosten summieren sich auf zu
U(t) = Zt
0
u(x)dx
=(KU/T +WH)t, 0≤t<T,
KU+WHT+WU·(t−T), t ≥T,
1

und die Host Kosten summieren sich auf zu
H(t) = Zt
0
h(x)dx =WHt.
Die Gewinnschwelle tB(break-even) wird nur f¨
ur
tB> T erreicht, da KU/T > 0. Die Gewinnschwelle
ergibt sich aus
U(tB) = H(tB).
Au߬
osung nach tBliefert
tB=T+KU
WH−WU
.
Die nachfolgende Zeichnung zeigt die Graphen
von U(t) und H(t).
0
2
4
6
8
10
0 1 2 3 4 5
Rehosting
Mainframe
Beispielsweise liegt f¨
ur T= 1.5, KU= 3.5,
WU= 0.3 und WH= 2 der break-even bei tB=
3.5588 . . . . M.a.W., nach weniger als vier Jahren
ist die Gewinnschwelle erreicht, wenn die j¨
ahrlichen
Host Leasing- und Wartungsgeb¨
uhren zwei Millio-
nen Euro betragen, und das Projekt nach andert-
halb Jahren mit einer Investitionssumme von drei-
einhalb Millionen Euro abschließt und anschließend
300 Tausend Euro j¨
ahrliche Wartungsgeb¨
uhren im
UNIX Umfeld f¨
allig sind. Verschiebt sich die Pro-
duktivsetzung um ein halbes Jahr, dann verschiebt
sich der Break-Even Zeitpunkt um die gleiche Zeit-
spanne, wenn man voraussetzt, dass keine h¨
oheren
Kosten KUanfallen. Dies tritt auf, wenn man ei-
nem anderen Projekt Vorrang beim Produktions-
einsatz lassen muß.
Der Endwert (future value) des Differenzenzah-
lungsstroms h(t)−u(t)mit dem Zins rist
F(r, t) = Zt
0h(x)−u(x)er·(t−x)dx.
Da tB> T , die Gewinnschwelle nach Projekten-
de Tliegt, errechnet man
F(r, t) = 1
rKU
T+WH−WUer(t−T)
−KU
Tert −WH−WU.
Gesucht ist der interne Zinsfuß r(t) (internal rate
of return), man vergleiche [BL], f¨
ur den gilt
F(r(t), t)=0.
Da ein einfacher formelm¨
aßiger Zusammenhang
zwischen rund tgesucht ist, wird die Exponential-
funktion nur bis zum quadratischen Glied benutzt:
ex= 1 + x+x2
2! +· · ·
Mit Hilfe dieser Vereinfachung findet man
r(t)≈2(t−T)(WH−WU)−KU
(2t−T)KU−(t−T)2(WH−WU).
Die angen¨
aherte Renditefunktion hat damit einen
hyperbolischen Verlauf. Man erkennt, dass trotz
N¨
aherung weiterhin gilt r(tB) = 0. Eine
N¨
aherungen kubischer Ordnung liesse sich analog
konstruieren, [MX].
Das nachfolgende Bild zeigt den Renditeverlauf
f¨
ur KU= 3.5, WH= 2 und WU= 0.3 f¨
ur die
Projektlaufzeiten T= 1, T= 1.5 und T= 2.
Man erkennt, dass die quadratische Approximati-
on (im Bild nur f¨
ur T= 1.5) die positive Rendite
¨
ubersch¨
atzt und die negative untersch¨
atzt.
2

In der Zeichnung kann man erkennen, dass nach
4 Jahren f¨
ur T= 1.5 die exakte Rendite 9.8%, nach
5 Jahren 22% betr¨
agt.
In der Praxis sind Projektlaufzeiten von 6 bis
18 Monaten typisch und realistisch, d.h. T= 0.5,
T= 1 oder T= 1.5. Weitere Preisbeispiele findet
man in [ME].
3 Rechenanlage
Von den großen Hardware Herstellern gibt es lei-
stungsstarke Rechenmaschinen, die im Verbund ein
Mehrfaches der ben¨
otigten Rechenleistung erbrin-
gen, wie sie der Mainframe bereitstellen kann. Als
Beispiele f¨
ur Rechner auf Basis von Linux (In-
tel/AMD), die sich gut in einem Verbund zusam-
men betreiben lassen, seien genannt:
1. HP ProLiant DL980 Server [HP]
2. Oracle (Sun) Fire X4800 Server [Ora]
3. Fujitsu Siemens PRIMERGY RX900 Server
[FJS]
4. IBM System x3755 [IBM]
Das nachfolgende Bild skizziert eine Architektur.
DEPOT
DB Server
KK DWH STAMM
…
Hierbei werden die Rechner entweder paarweise
oder in gr¨
oßeren Gruppen zu einem Cluster zusam-
mengeschlossen. Alternativ lassen sich nat¨
urlich
auch große, monolithische Systeme verwenden, wie
z.B. Sun M9000 oder HP 9000 Superdome.
Im obigen Schaubild wurden die Aufgaben nach
Sachgebiet und Systemen verteilt. Im Beispiel sind
dies die Systeme f¨
ur Wertpapier und Depot, f¨
ur
Kontokorrent und Zahlungsverkehr, auswertende
Systeme auf Basis von Datawarehouse L¨
osungen,
sowie die Stammdatensysteme (Kunden, Wertpa-
pier, Filialorganisation). Aufgrund der hohen Last
f¨
ur die zentrale Datenhaltung wurde die Datenbank
auf einen eigenen, leistungsstarken Rechner gelegt.
4 Werkzeuge
Im Folgenden sollen namhafte Hersteller und Werk-
zeuge aufgelistet werden, welche bei der Migra-
tion ben¨
otigt werden. Die Aufz¨
ahlung ist nicht
vollst¨
andig, repr¨
asentiert aber sicherlich die wich-
tigsten Produkte und Hersteller.
An COBOL Compilern f¨
ur dezentrale Plattformen
seien genannt:
1. Micro Focus COBOL [MF]
2. AcuCOBOL [MF]
3. Liant RM/COBOL (jetzt auch Micro Focus)
[MF]
4. Fujitsu NetCOBOL [NC]
5. OpenCOBOL (open source) [OC]
6. COBOL-IT (basiert auf OpenCOBOL) [CI]
7. Veryant isCOBOL [Vy]
Die Auswahl an PL/I Compilern ist erheblich klei-
ner:
1. Micro Focus Open PL/I (fr¨
uher Liant Open
PL/I) [MF]
2. IBM PL/I for AIX [IBM]
3. Iron Spring PL/I for OS/2 and Linux [IS]
An CICS Produkten f¨
ur UNIX und Windows seien
genannt:
1. Oracle Tuxedo Application Runtime for CICS
and Batch [Ora]
2. Micro Focus Enterprise Edition [MF]
3. Clerity UniKix TPE [CY]
4. HTWC XFRAME [HT]
5. Fujitsu NeoKicks (nur f¨
ur Windows) [NC]
3

Alternativ kann man den CICS BMS Datenstrom
umwandeln in JSP/HTML/JavaScript, man ver-
gleiche dazu [LW], ferner wird der Transaktions-
monitor CICS durch Tuxedo [Ora] ersetzt.
Der IBM Transaktionsmonitor IMS/DC und die
IBM IMS/DB Datenbank k¨
onnen durch eine der
folgenden Produkte ¨
ubernommen werden:
1. Micro Focus Enterprise Edition [MF]
2. Clerity UniKix TPE mit H-RDB [CY]
3. HTWC H2R [HT]
Bei den genannten Produkt bleiben die COBOL
und PL/I Programme, die auf IMS zugreifen, un-
ver¨
andert. [Mue] beschreibt die Micro Focus Pro-
dukte. Ist nur der IMS Transaktionsmonitor f¨
ur
die Maskensteuerung zu ersetzen, so kann dieser
vergleichsweise einfach selber nachprogrammiert
werden, in dem man sich die Benutzersteuerung
und Lastverteilung durch einen Web-Server zunut-
ze macht.
F¨
ur die Portierung von DFSORT und Sync-
Sort Anweisungen kommt man in vielen F¨
allen mit
dem klassischen UNIX sort aus, andernfalls emp-
fiehlt sich eine Pr¨
ufung des Ahlsort Produktes, [AS]
und [IG].
An JCL/JES Emulatoren seien genannt:
1. Micro Focus Enterprise Edition [MF]
2. Clerity UniKix BPE [CY]
3. HTWC XFRAME (XEBE) [HT]
4. Fujitsu NeoBatch (nur Windows) [NC]
5. IT-gain J2U [IG]
Mithilfe dieser Batch Systeme werden die JCL und
OPC Abl¨
aufe ¨
ubernommen. Die eigentliche Job
Planung und Ausf¨
uhrung wird ¨
ublicherweise durch
eine der klassischen Scheduling Systeme erledigt,
z.B. UC4, siehe [UC4].
Die eigentliche Migration wird in hohem Ma-
ße automatisiert ablaufen. Die zu ¨
ubernehmenden
Programme werden nicht etwa h¨
andisch auf die
neue Plattform umgearbeitet, sondern mittels
Scripten umgestellt. Hier kommt h¨
aufig die Script-
sprache Perl zum Einsatz [PE]. Damit ist sicherge-
stellt, dass parallel laufende Projekte bis kurz vor
der Schlußabnahme noch Source Code zum Reho-
sting einliefern k¨
onnen.
5 Vorgehen
Vor dem eigentlichen Mainframe Rehosting ist ei-
ne Vorstudie aufzusetzen, die sich mit der Infor-
mationsbeschaffung, den Alternativen, den Stolper-
steinen und lokalen Gegebenheiten besch¨
aftigt. Ei-
ne Beschreibung aus der Praxis findet man bei-
spielsweise bei [BS], bei der die Migration von Bull
GCOS8 zu AIX beschrieben wird.
Die Bestandsaufnahme umfaßt:
1. Eigenerstelle Programme
2. Source code
3. Fremdprogramme ohne Quellcode
4. Job Abl¨
aufe
5. Netzwerkschnittstellen zwischen Mainframe
und anderen Systemen (Messaging, File Trans-
fer)
6. Datenmodell und performance-kritische Tabel-
len
7. Dokumentation und bisherige Testergebnisse
8. Nicht mehr ben¨
otigte Programme
9. Geplante Produktionseins¨
atze anderer Projek-
te
Nach der Bestandsaufnahme ist das Inventar zu
bewerten: Welche Programme sind zu ¨
ubernehmen,
welche k¨
onnen entfallen, gibt es vom Fremdher-
steller auf der neuen Plattform entsprechende
L¨
osungen, ist der Source Code vollst¨
andig? Die
Vorstudie skizziert das Cluster- und Disaster Re-
covery Konzept. Ein besonderer Punkt ist die Mi-
gration von Assembler Programmen. Die Umwand-
lung von Assembler nach COBOL kann zwar au-
tomatisiert werden, jedoch ist hier stets manuelle
Nacharbeit erforderlich. Umso wichtiger ist es im
Rahmen der Vorstudie festzustellen, welche Assem-
bler Programme erst gar nicht mehr migriert wer-
den m¨
ussen. Die Vorstudie ergibt, ob es zweckm¨
aßig
ist den vorhanden Source Code Tool-gest¨
utzt zu re-
strukturieren, das sind Ausschluß toter Code, GO-
TO Eliminierung und Verringerung, z.B. mit Hilfe
der in [SSV] angegebenen Verfahren.
4

Die Vorstudie sollte mit Hilfe eines Prototyps
(proof of concept) den Nachweis f¨
uhren, dass kri-
tische Prozesse grunds¨
atzlich migrierbar sind. An-
hand einer performance-kritischen Datenbankta-
belle und einzelnen, damit zusammenh¨
angenden
Programmen wird exemplarisch eine Migration
durchgef¨
uhrt und der Nachweis erbracht, dass
auf einer dezentralen Plattform grunds¨
atzlich ei-
ne ausreichende Geschwindigkeit erzielbar ist. Dies
ist wichtig, um im Unternehmen auch gegen¨
uber
Zweiflern eine Handhabe zu besitzen. Gleichzei-
tig wird eine Empfehlung f¨
ur die zu verwendenden
Werkzeuge gegeben.
Die lokalen Gegebenheiten ber¨
ucksichtigen
das Sicherheitskonzept des Unternehmens,
Versionsf¨
uhrung, Projektorganisation und Be-
richtswesen. Schließlich liefert die Vorstudie die
voraussichtlichen Kosten KU, die Projektlaufzeit T
f¨
ur die Migration und benennt die zu erwartenden
Wartungsgeb¨
uhren WU. Mit diesen Daten kann
man das Vorhaben entweder ausschreiben oder
vom hauseigenen Dienstleister durchf¨
uhren lassen.
Es sei betont, dass die Gr¨
oßen KU,WUund T
auch schon vor der Vorstudie gesch¨
atzt werden
k¨
onnen.
6 Erfahrungen und Ausblick
Hunderte Unternehmen und Beh¨
orden aus al-
len Branchen, Banken, Versicherungen, Automobil,
Bildung, Stahl u.s.w. haben ihre Mainframe An-
wendungen rehostet bzw. planen dies in naher Zu-
kunft zu tun.
Alle Banken haben die Euro Einf¨
uhrung gemei-
stert, sie haben den Jahrtausendwechsel erfolgreich
bew¨
altigt und die WKN Umstellung durchgef¨
uhrt.
Bei allen diesen Großprojekten waren die vorhan-
den Systeme, der Source Code und die Schnitt-
stellen zu analysieren. Im Rahmen dieser Projek-
te sind h¨
aufig Analysewerkzeuge und Inventarlisten
erstellt worden. All diese Hilfsmittel k¨
onnen beim
Rehosting erneut verwendet werden. Unter diesem
Gesichtspunkt ist das Rehosting risiko¨
armer und
einfacher als die vorgenannten Projekte. Gemein-
sam ist allen genannten Projekten, dass ihr Ur-
sprung technischer Natur ist, jedoch ein gutes fach-
liches Verst¨
andnis bei der Umsetzung und insbe-
sondere beim Test erforderlich ist. Neben der fach-
lichen Expertise ist ein sorgf¨
altiges Projektmanage-
ment vonn¨
oten, welches die zahlreichen IT Abtei-
lungen, die Abh¨
angigkeiten zu anderen Projekten
und die fristgerechte Fertigstellung einzelner Lie-
ferungen ¨
uberwacht und steuert. Weiterhin ist die
Unterst¨
utzung durch die oberste F¨
uhrungsebene
notwendig, um ¨
Angsten und Behinderungen entge-
genzutreten.
Bei Rehosting Projekten wird vielfach der
Wunsch vorgebracht mit der neuen Plattform auch
gleichzeitig eine andere Datenbank zu verwen-
den. H¨
aufig wird der Wechsel von DB2 zu Oracle
gew¨
unscht. Gelegentlich besteht auch Interesse von
DB2 zu MySQL zu wechseln. Das Rehosting selber
erzwingt keinen Wechsel des Datenbankherstellers
unter der Voraussetzung, dass der Hersteller die al-
te und neue Plattform entsprechend unterst¨
utzt.
Nat¨
urlich hat der Wechsel auf MySQL erhebliche
Auswirkungen auf die Wartungskosten WU. Aber
dieser Wechsel ist nicht ganz so einfach. Leichter
ist es, wenn man seinen bisherigen Datenbankher-
steller beibeh¨
alt. Selbstverst¨
andlich kann man hier
in zwei Schritten vorgehen: zuerst das Rehosting
und anschließend der Wechsel der Datenbank.
Eine Schwierigkeit, die man beim Mainfra-
me Rehosting ¨
uberwinden muß, ist das den
gr¨
oßeren Instituten innewohnende Verharrungs-
verm¨
ogen. In [MM] findet man die Aussage, dass
das Mainframe Rehosting ¨
ahnlich wirkt, wie der
Fall der Berliner Mauer, der Gewinn an Freiheit
sei ph¨
anomenal.
7 Literatur
[AS] http://www.ahlsort.com/
[BL] Blohm, Hans und L¨
uder, Klaus: “Inves-
tition”, 4. Auflage, Verlag Franz Vahlen,
M¨
unchen, 1978, XII +298 S
[BP] http://www.bphx.com/
[BS] Bach, Johannes und Schulze, Martin:
“Das Debeka-Projekt MiKe — Migra-
tion der Debeka-Kernanwendungen von
Bull/GCOS8 auf AIX”, 10. Workshop
Software-Reengineering der GI-Fachgruppe
Software Reengineering, Bad-Honnef, 05.–
07. Mai 2008
[CO] http://www.cobug.com/
5

[CI] http://www.cobol-it.com/
[CY] http://www.clerity.com/
[FJS] http://www.fujitsu-siemens.de/
[HP] http://www.hp.com/
[HT] http://www.htwc.com/
[IBM] http://www.ibm.com/
[IG] http://www.itgain.de/
[IS] http://www.iron-spring.com/
[LW] Laszewski, Tom and Williamson, Jason:
“Oracle Modernization Solutions”, Packt Pu-
blishing (26. September 2008), Birmingham,
432 p.
[ME] META Group: “Mainframe Rehosting Mar-
ket Evaluation: Tools and Relative Costs”,
by Corey Ferengul and William Snyder, May
2003, 20 p.
[MF] http://www.microfocus.com/
[MM] http://mainframemigration.org/
[Mue] M¨
uller, Oliver: “Adieu Dino — Mainframe
Rehosting mit Micro Focus’ Enterprise Ser-
ver”, iX, M¨
arz 2011, heise Verlag, S.92–97
[MX] http://maxima.sourceforge.net/
[NC] http://www.netcobol.com/
[OC] http://www.opencobol.org/
[Ora] http://www.oracle.com/
[PE] http://www.perl.org/
[SSV] Sellink, Alex and Sneed, Harry and Verhoef,
Chris: “Restructuring of COBOL/CICS Lega-
cy Systems”, Computer Programming, Volu-
me 45, Issue 2–3, p. 193–243
[UC4] http://www.uc4.com/
[Vy] http://www.veryant.com/
6