Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.06.1993

Beim Downsizing koennen OLTP-Produkte hilfreich sein Datenbanksysteme machen dir OLTP-Monitore ueberfluessig

Lange galt das Fehlen von Loesungen zum Online Transaction Processing (OLTP) fuer kommerzielle Umgebungen als eine der gravierendsten Schwaechen von Unix. Ullrich Jost* ist hier allerdings ganz anderer Meinung. Aus seiner Sicht ist Transaktionsverarbeitung heute die Aufgabe von relationalen Datenbanksystemen. OLTP-Systeme taugen allerdings noch als Hilfsmittel bei der sanften Migration vom Mainframe auf moderne Client-Server-Architekturen

*Ullrich Jost ist Leiter Produkt-Marketing fuer Systemsoftware bei der Cincom Systems GmbH, Frankfurt.

Was immer sich hinter dem Sammelbegriff offene Systeme verbergen mag, er ist jedenfalls ein Synonym fuer Veraenderung. OLTP-Unix- Systeme und Client-Server-Computing unterscheiden sich elementar von den Mainframe-Anwendungen. Zum endgueltigen Erfolg mangelte es bisher jedoch an einfachen Migrationstechniken fuer die meist auf Cobol und sequentiellen Datenhaltungssystemen basierenden Mainframe-Anwendungen.

Indem sie auf die angebliche Durchsatzschwaeche von Transaktionen bei OLTP-Anwendungen hinweisen, haben die Verfechter proprietaerer Systeme eine Diskussion entfacht, die zu einer absurden Entwicklung fuehren koennte: Anstatt auf Basis neuer Softwaretechnologien die alte Systemwelt fuer den Anwender investitionssichernd zu integrieren, sollen aufgrund der hohen Migrationskosten etablierte TP-Monitore auch in der Unix- und PC- Welt zum neuen Standard werden. Es gibt aber sinnvolle Wege zur Migration der Altanwendungen unter Beruecksichtigung der neuen Anforderungen und der vielfaeltigen Moeglichkeiten, die sich in der Unix-Welt bieten. In Teilbereichen koennen dann auch althergebrachte Techniken wieder zur Loesung beitragen.

Eine Vielzahl von Faktoren beeinflusst den Wert von Migrationstechniken hinsichtlich Effizienz, Machbarkeit und Zukunftssicherheit. Beim Einstieg in eine offene Systemwelt und bei der Migration von OLTP-Anwendungen stellen sich allen Anwendern mehr oder minder die gleichen Probleme, unabhaengig davon, ob sie bisher proprietaere Systeme von IBM, DEC, SNI, NCR oder Bull einsetzen. Es ist die Altlast der mit einem bestimmten proprietaeren TP-Monitor und dem dazugehoerigen Datenhaltungssystem entwickelter Anwendungen.

Verschiedene Wege

fuehren zu Unix

Die Modernisierungsansaetze unterscheiden sich in der Regel nur durch die verschiedenen Wege hin zu Unix. Downsizing hat den Ersatz des Grossrechners zum Ziel, Right- oder Smartsizing bezweckt den Einsatz der bei unterschiedlichen Anwendungen jeweils effizientesten und kostenguenstigsten Systemloesung und Plattform. Dabei sind PC, Unix und Mainframe zunaechst einmal gleichwertig, und jede Loesung muss hinsichtlich der Plattform austauschbar sein.

Ausgangsposition muss

beruecksichtigt werden

Kein Unternehmen beginnt mit Unix auf der gruenen Wiese. Jede neue Technologie ist nur so gut, wie sie das Bestehende und Erhaltenswerte integrieren und weiternutzen kann. Von daher spielen also Unix-TP-Monitore und VSAM-identische Datenhaltungssysteme bei der Migration von Mainframe-Anwendungen eine Rolle.

Es ist aber auch die jeweilige Ausgangsposition eines Unternehmens zu beruecksichtigen: Werden auf dem Grossrechner ausschliesslich Cobol-Systeme mit einfacher Datenhaltung wie VSAM, RMS oder Leasy eingesetzt, so stellen sich zum Teil erheblich groessere Probleme als bei Altanwendungen, die bereits auf Datenbanken oder 4GL-Tools basieren.

Einfach hat es ein Anwender, der bereits auf dem Mainframe mit einer Datenbank und 4GL entwickelt hat, die in gleicher Form auch auf PCs und Unix verfuegbar ist. Er braucht dann nur mit einem minimalen Portierungsaufwand zu rechnen. Geschaeftsfuehrer Ritschel ist bei der Teamco Software Instruments, Koeln, in einer solch gluecklichen Lage: "Wir haben unser Instandhaltungssystem TMS mit den Cincom-Produkten Supra und Mantis auf einem IBM-Grossrechner entwickelt. Unsere Kunden wollen jedoch Unix-Systeme, da diese in der Administration einfacher sind. Wir haben unsere Anwendungen binnen einer Woche auf verschiedenen PC- und UnixSystemen implementieren koennen."

Teamco befand sich jedoch in einer Ausnahmesituation. In der Regel stellen sich die Probleme anders dar, selbst wenn fuer die Zukunft der Einsatz einer Datenbank und eines Entwicklungswerkzeugs der vierten Generation geplant ist.

Eine offene Systemwelt zeichnet sich durch Attribute wie Portabilitaet, Interoperabilitaet und Hersteller-Unabhaengigkeit aus. Man muss dabei aber beruecksichtigen, dass die DV-Realitaet keineswegs nur aus offenen Unix-Systemen, sondern vor allem aus heterogenen DV-Umgebungen mit einem hohen Anteil proprietaerer Produkte besteht. Bei einem Downsizing-Konzept kommt es daher darauf an, die positiven Unix-Eigenschaften auch auf PCs und Grossrechner zu uebertragen.

Moeglichkeiten fuer

einen sanften Umstieg

Grundsaetzlich bieten sich vier Migrationswege an:

- Die komplette Neuentwicklung aller Anwendungen mit Austausch der vorhandenen Standardsoftware ist dabei als wirklichkeitsfern auszuschliessen.

- Genauso unrealistisch ist es, die alten Anwendungen ohne Aenderung uebernehmen zu wollen und weiterzumachen, als haette es sich lediglich um einen Rechneraustausch gehandelt. Die geringeren Hardwarekosten allein rechtfertigen keinen Umstieg auf Unix.

- Die dritte Moeglichkeit besteht darin, zunaechst auf dem Grossrechner zu bleiben und mit dem vorhandenen Wissen und Equipment auf eine portable Datenbanksoftware umzustellen. Der Umstieg auf Unix erfolgt dann erst in einem weiteren Schritt.

- Der vierte Weg ist eine den individuellen Anwenderanforderungen anpassbare Kombination aus den drei genannten Migrationsstrategien. Hier spielt OLTP eine wichtige Rolle.

Anforderungen an

die Anwendungen

Der letztgenannte Migrationspfad, der nun im Detail betrachtet werden soll, hat einige Voraussetzungen, die vorweg geklaert werden muessen. Dazu gehoeren sieben grundsaetzliche Anforderungen an Anwendungen, die im Rahmen von OLTP eine effiziente und sichere Transaktionsverarbeitung gewaehrleisten:

- Datenkonsistenz: Die zu verarbeitenden Daten muessen immer gueltig sein. Reorganisationsbedingte Ausfaelle von Teildaten darf es nicht geben; relationale Verbindungen im Datenmodell muessen gewahrt werden.

- Commit-Steuerung: Eine Transaktion darf nur erfolgreich oder gar nicht ausgefuehrt werden. Die Datenintegritaet geht sonst verloren.

- Unabhaengigkeit: Alle Transaktionen muessen voneinander unabhaengig, Teilsperrungen muessen erlaubt sein.

- Sperrung: Daten, die von einer Transaktion verarbeitet werden, muessen unterschiedliche Sperrmechanismen erlauben. Entwickler muessen etwa zu Lese-, Update- oder konkurrierenden Update- Sperrverfahren greifen koennen.

- Sicherheit: Rollback und Recovery muessen im Fehlerfall moeglich sein.

- Transparenz: Alle Transaktionen muessen protokollierbar sein, um so die Anforderungen der DV-Revision und des Datenschutzes erfuellen zu koennen.

- Prioritaetensteuerung: Die Transaktionsverarbeitung muss hinsichtlich sich aendernder Prioritaeten steuerbar sein.

Immer wieder liest man, dass die Standards fuer OLTP heute definiert und verfuegbar seien. Meist stammen solche Aussagen von Hardwareherstellern - und das mit gutem Grund. Sie wollen ihre Produkte mit dem Etikett "Standard" attraktiver machen.

Hersteller aus der offenen Systemwelt preisen dabei die unbestreitbaren Vorzuege ihrer Technologie gegenueber dem Mainframe. Meist geben sie damit jedoch nicht die Erfahrungswelt des Anwenders wieder: Grafische Oberflaechen werden als Voraussetzung fuer OLTP genannt, Portabilitaet und Interoperabilitaet wird nur zwischen verschiedenen Unix-Systemen als notwendig erachtet, der Einsatz einer relationalen Datenbank wird vorausgesetzt, und operative Massendatenanwendungen - eine Staerke der Grossrechner - sind im Erfahrungsschatz der Workstation-Hersteller noch unbekannt.

Die proprietaeren Hersteller, namentlich die IBM, gehen beim Marketing einen subtileren Weg. Er ist vor allem davon gepraegt, dass Big Blue im harten Konkurrenzkampf mit den anderen Herstellern seine angestammte Installationsbasis schuetzen will. Entsprechend sieht die OLTP- und Migrationsstrategie der IBM aus.

CICS und Cobol sind

SW-Loesungen der 70er Jahre

Da die mehr als zehn Millionen Cobol- CICS-VSAM-Anwendungen auch weiterhin von den mehr als einer Million Cobol- und CICS- Programmierern gewartet werden muessen, soll die Kombination aus Cobol und CICS auch fuer Unix das Allheilmittel werden. Das klingt zunaechst einmal plausibel, verringert sich so doch der Migrationsaufwand bei der Mainframe-Abloesung. Ziel ist es, schliesslich die bisherigen OLTP-Anwendungen auch auf Unix laufen zu lassen und das vorhandene Wissen der Entwickler weiter zu nutzen. Bereits seit geraumer Zeit lizenzieren Hewlett-Packard und SNI den IBM-Transaktionsmonitor CICS; Big Blue selbst hat jetzt angekuendigt, dass CICS vermehrt auch weiteren Hardwareherstellern zur Verfuegung gestellt werden soll.

Mit dieser Loesung wird suggeriert, dass IBM den Grossrechner- Anwendern Sicherheit gibt und ihnen zudem Software-Investitionen beim Uebergang zu Unix erspart. Die Unix- und Workstation- Hersteller koennen darueber hinaus aufgrund der Portabilitaet der Altanwendungen selbstbewusst versuchen, auch weiterhin im Rahmen von Downsizing-Strategien auf die Abloesung des Grossrechners zu draengen.

Was sich so verlockend einfach darstellt, ist jedoch keine Migrationsstrategie. Eine OLTP-Anwendung beinhaltet mehr als Cobol- und CICS-Kommandos: Die Daten sind dann immer noch im VSAM verankert, es gibt Batch-Programme und JCL-Prozeduren, die komplette Anwendungen navigieren.

Hinter IBMs Strategie laesst sich die Absicht vermuten, die Probleme der Heterogenitaet durch eine vermeintliche Homogenitaet zu loesen. Dabei geht die Staerke der Vielfalt moeglicher Loesungen schon im Ansatz verloren.

CICS und Cobol sind Softwareloesungen der 70er Jahre und beruecksichtigen nicht die heutigen Moeglichkeiten und Anforderungen. Beide Werkzeuge kennen nicht die Moeglichkeiten der modernen relationalen Datenbanken und 4GL-Werkzeuge. Mit Aufkommen solcher Systeme sind die OLTP-Anforderungen zu integralen Bestandteilen der Entwicklerwelt geworden.

Datenbanken machen

TP-Monitore obsolet

Moderne Datenbanksysteme besitzen die notwendigen Features, um den Einsatz eines TP-Monitors ueberfluessig zu machen. Einige Produkte gehen sogar weit ueber das hinaus, was traditionelle TP- Monitore leisten koennen. Neue Formen in der Anwendungsentwicklung wie Verteilung von Daten, Anwendungen und Multimedia-Programmen sind erst durch Datenbanken moeglich geworden. Ein klassischer TP- Monitor kennt keine Blob-Bildverarbeitung (Binary Large Objects) und keine Spiegelung von Datenbanken auf mehreren Rechnern. Auch die fuer die Verteilung von Daten notwendige Zwei-Phasen-Commit- Steuerung und ein Transaktions-Partnerkonzept zur Commit- und Restart-Steuerung bei mehr als zwei physisch getrennten Daten- Servern laesst sich nicht mit einem TP-Monitor abbilden.

Vermeintliche Schwaechen wie die Einzelprozess-Verarbeitung, die kein echtes Multithreading zulaesst, sind bei Systemen wie Supra und der Version 7 von Oracle durch Shared processing ausgeraeumt und hinsichtlich der Prioritaeten steuerbar. Auch ist davon auszugehen, dass kuenftiges Parallel-Computing beziehungsweise symmetrisches Multiprocessing mehrerer Rechner auch den Ein- und Ausgabe- durchsatz im Massenbetrieb erheblich verbessern wird.

TP-Monitore wie CICS und eine Programmiersprache wie Cobol sind fuer zentralistische und monolithische Anwendungen konzipiert worden.

Technisch gesehen bedeutet heute ein TP-Monitor zusaetzlichen Overhead, der sich auf Grossrechnern nur rechtfertigen laesst, weil der Monitor dort als Traegersystem fuer die Datenbank und das Entwicklungswerkzeug dient. Nur solange mit Werkzeugen gearbeitet wird, die Datenkommunikation und Daten-Management nicht als immanente Funktionen besitzen, ist der Entwickler und Systembetreuer auf ein solches OLTP-Steuerungswerkzeug angewiesen. Datenbanken zielen genau auf dieses Problem ab, und 4GL-Werkzeuge haben die Datenmanipulation auf eine logische, zum Befehlsumfang gehoerende Ebene verlagert; SQL hat das Daten-Management transparent gemacht. Auch Cobol oder C haben durch die SQL-Pre- Compiler diese Funktionen zusaetzlich erhalten.

Client-Server-Computing stellt eine weitere zeitgemaesse Technik dar, die fuer den Einsatz von Datenbanken und 4GL-Tools als Ersatz fuer einen TP-Monitor spricht. Eine Client-Server-Anwendung fuer PCs oder Unix, bei der eine Datenbank und ein modernes Entwicklungs- Tool unabdingbar sind, realisiert im Gegensatz zu einer monolithischen Grossrechner-Anwendung die Trennung von Daten- Management, Anwendungslogik und Anwendungspraesentation (vgl. Abbildung 1). Nur dadurch kann eine Anwendung unabhaengig von der eingesetzten Datenbank und der physikalischen Moeglichkeit zur Praesentation werden. Eine derartige Autonomie der verschiedenen Anwendungsschichten ist anzustreben, weil dem Anwender in einer offenen Systemwelt jederzeit erlaubt sein muss, die Infrastrukur seiner Client-Server-Anwendung umzugestalten.

Die Aenderung von Daten-Management und Praesentation beziehungsweise der Wechsel der Client-Server-Betriebsart werden also nicht mehr programmiert, sondern im Rahmen der Systemintegration von aussen im 4GL-Dictionary oder im Datenbank- Directory definiert. Ein TP-Monitor wuerde dagegen die dynamischen Aenderungsmoeglichkeiten von Anwendungen ausserhalb des Programms einschraenken. Jeder Wechsel von Client- oder Server-Funktionen hat dann Programmierarbeit zur Folge. Im Grunde genommen duerfte auch nicht mehr mit einer 3GL entwickelt werden, da lediglich das Daten-Management via SQL als sprachimmanente Client-Server- Funktion verfuegbar ist, Anwendungslogik und Praesentationsform jedoch statisch im gewandelten Programm verankert sind.

Offene Systeme

bedeuten Interoperabilitaet

Diese Einstellung zu TP-Monitoren stuetzt auch David Tory, Praesident der Open Software Foundation (OSF): "Offene Systeme sind nicht mit Unix gleichzusetzen, ebensowenig mit Windows NT oder irgendeiner anderen Betriebssystem-Software. Offene Systeme bedeuten Interoperabilitaet, die nur auf der Basistechnologie der Rechner und durch Middleware zu erreichen ist."

Basistechnologie meint in diesem Zusammenhang kein bestimmtes Betriebssystem oder eine bestimmte Netzsoftware. Statt dessen muss Middleware (also Systemsoftwareprodukte wie Datenbanken, Entwicklungs-Tools, Gateways und Router) die Interoperabilitaet von Daten und Anwendungen zwischen allen Betriebssystemen sicherstellen. Eine einzige Rechnerarchitektur mit einem universellen Betriebssystem und universell einsetzbaren Betriebssystem-Werkzeugen wird es voraussichtlich nicht geben, da sonst jede Neuentwicklung wieder Migrationsprobleme eroeffnen wuerde.

Der Weg zur

einfachen Migration

Vor der Migration steht immer die Auswahl der neuen Software- und Hardwarelandschaft. Legt man die Massstaebe der OSF an, dann beschaeftigen sich die meisten Anwender bei der Suche nach einer fuer sie passenden Migrationsstrategie meist mit den falschen Fragen. Es wird nicht nach der universellen Einsetzbarkeit geforscht, sondern es werden wiederum proprietaere Teileigenschaften einer neuen Softwarelandschaft untersucht und gefordert. Man sollte also zusammen mit der Entscheidung fuer eine neue Systemwelt die Kriterien fuer offene Systeme und Grossrechner einfliessen lassen. Werden diese Punkte in moeglichst grossem Masse erfuellt, dann kann jeder Anwender sicher sein, eine fuer sich geeignete Migrationsstrategie zu finden.

Zwischen PC, Workstation und Grossrechner muessen Interoperabilitaet und Portabilitaet von Daten und Anwendungen bestehen. Die eingangs erwaehnte, von mir praeferierte vierte Moeglichkeit einer realistischen Migrationsstrategie basiert hierauf.

Ein Vorteil bei der Einfuehrung von Unix-Systemen und die Umstellung auf eine relationale Datenbank ist die neu gewonnene Unabhaengigkeit hinsichtlich der Realisierung.

Aufgrund der Client-Server-Architektur der Entwicklungssysteme koennen die Benutzer mit einer Vielzahl moeglicher Werkzeuge ihre unterschiedlichen Informationsbeduerfnisse auf Grundlage einer einzigen Datenhaltungsmethode realisieren. Die Fachbereiche koennen mit grafischen Werkzeugen wie Spreadsheet-Software oder mit Abfrage-Tools selbstaendig ihre Anwendungen erstellen. Die professionelle Anwendungsentwicklung arbeitet mit Fortran, Cobol, C oder einer 4GL und stellt damit die operativen Anwendungen zur Verfuegung. Ein interoperables Datenhaltungssystem kann ermoeglichen, dass auf einer identischen Datenbank die Grossrechner- Stammdatenpflege, die PC-Grafikauswertung und eine multimediale Bildverarbeitung erfolgen. Audiovisuelle Informationen werden parallel und ergaenzend zu den operativen Daten mitgespeichert.

Der Grossrechner ist

nicht einfach ersetzbar

Betrachten wir zunaechst die Faktoren, die eine Migration in die Unix-Welt erschweren koennen. Wichtige kommerzielle Anwendungsbereiche werden heute oft von Standardsoftware abgedeckt, die wiederum meist an die proprietaere Plattform gekettet ist.

Ein weiteres Problem stellen alte Datenbestaende in den indexsequentiellen Datenhaltungssystemen wie VSAM dar. Meist sind diese an aeltere Cobol-Anwendungen gebunden, die mit CICS entwickelt wurden. Diese Anwendungen sind oftmals nicht ersetzbar, da entweder die Neuentwicklung zu aufwendig waere oder ganz einfach das Wissen nicht mehr im Unternehmen verfuegbar ist.

Auch neuere Dialoganwendungen, die bereits auf einer relationalen Grossrechner-Datenbank basieren, lassen sich aufgrund des Aufwands nicht einfach binnen kurzer Zeit neu entwickeln.

Sind bestehende Anwendungen leicht umzustellen, erhebt sich sofort das Problem, dass die alten Datenbestaende auch von neuen Programmen mitverarbeitet werden muessen. Wichtig ist also, dass das neue Entwicklungssystem und die Unix-Datenbank die transparente Verarbeitung der VSAM-Dateien ermoeglichen. Dieses kann mit besonderen Zugriffsroutinen geschehen, wie sie die meisten Datenbankhersteller inzwischen anbieten.

Die Umstellung von

CICS und VSAM

Entschliesst sich ein Unternehmen zum Einsatz eines CICS- kompatiblen TP-Monitors auf Unix, dann bieten sich fuer VSAM- Verarbeitungen weitere Varianten an. Ein Cobol-Programm kann in einer solchen Umgebung relativ leicht auf einen Unix-Rechner portiert werden. Fuer indexsequentielle Dateien muss allerdings eine VSAM-aehnliche Datenverwaltung genutzt werden, wie sie einige 4GLs anbieten.

Effizienter und konsequenter ist jedoch die Umstellung der Dateien auf SQL-Datenhaltung, da die VSAM-Simulation viele neue Probleme verursacht. Dabei ist aber zu beruecksichtigen, dass es zur uebrigen SQL-Datenhaltung redundante Daten gibt, die durch fehleranfaellige Interface-Programme kuenstlich konsistent gehalten werden. Bei einer solchen Vorgehensweise gehen jedoch elementare Vorteile der relationalen Datenbank verloren, da die Konsistenz und Integritaet des gesamten Datenbestandes in Frage gestellt ist.

Um diese Nachteile zu beseitigen, bieten einige Datenbankhersteller fuer die Portierung von Cobol-VSAM-Anwendungen spezielle Migrationswerkzeuge an, die Cobol-Programme hinsichtlich der Haeufigkeit und Komplexitaet der Dateizugriffe und Dateiformate analysieren und die manuelle Konvertierung unterstuetzen. Weitere Tools muessen dann die eigentliche Portierung der VSAM-Dateien uebernehmen. Am Ende des Projekts stehen dann Cobol-CICS-SQL- Anwendungen und SQL-Datenbestaende auch fuer den Grossrechner zur Verfuegung (vgl. Abbildung 2).

Trotz groesstmoeglicher Sorgfalt kann es keine universelle Stategie fuer den Wechsel von proprietaeren zu offenen Systemen geben. Die Anforderungen eines jeden Unternehmens sind einzigartig. Jede Migration ist ein individuelles Projekt und muss durch eine Vielfalt moeglicher Alternativen variabel steuerbar sein.

Abb. 1: Die Gartner Group hat die Betriebsarten von Client-Server- Computing systematisiert. Durch die Trennung von Praesentation, Anwendungslogik und Datenhaltung duerfen kuenftige OLTP-Anwendungen keine monolithische Strukturen mehr aufweisen.

Abb. 2: Die monolithische Cobol/CICS/VSAM-Anwendung muss im Rahmen der Migrationsarbeiten in eine neue Struktur gebracht werden. Durch Trennung von Daten-Management, Anwendungslogik und Praesentation der Anwendung kann mit geeigneter Middleware die Anwendung portiert werden. VSAM- oder CICS-Simulation auf PC- oder Unix-Rechner kann im Einzelfall jedoch sinnvoll sein.