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.

03.02.1989 - 

Erfahrungen mit IMS und DB2 - Harmonie von alten und neuen Anwendungssystemen:

Probleme entstehen beim Umdenken von Satz auf Menge

*Karlheinz Groß ist Abteilungsleiter Datenbanken bei der Lurgi GmbH, Frankfurt. Der Tagungsband ist bei CW-Publikationen erhältlich.

Der isolierte Einsatz des relationalen Datenbanksystems DB2 neben IMS/DB führt zu unnötigen Schnittstellenproblemen und Redundanzen. Eine wesentliche Voraussetzung zum Aufbau und Betrieb Integrierter Anwendungssysteme ist ein kooperierendes Miteinander der unterschiedlichen Datenbanksysteme. Karlheinz Groß* berichtet über die Erfahrungen beim Aufbau und Einsatz operationaler DB2-Anwendungen in einer IMS-Umgebung.

Die Entwicklung und der Einsatz von Dialoganwendungen begann bei Lurgi Mitte der siebziger Jahre. Die ersten Anwendungen basierten auf VSAM und dem Monitor TCAM. Nach der Einführung von IMS 1979 erfolgte die Umstellung dieser Anwendungen auf IMS. In der Folgezeit wurden zur Entwicklung unternemensspezifischer Software große Anstrengungen unternommen und hohe Investitionen getätigt.

Neben den selbstentwickelten Dialoganwendungen kamen auch Anwendungspakete vom Markt zum Einsatz. Die Anwendungssysteme sind über gemeinsame Datenbanken verknüpft. Das Datenbanksystem IMS/DL/ 1 hat dabei die Aufgabe, die Integration und die Konsistenz der Daten zu gewährleisten. Die Programme sind vorwiegend im PL/1 und Assembler kodiert. Zur Zeit sind 28 Anwendungssysteme unter IMS im Einsatz mit einem monatlichen Transaktionsvolumen von 1,2 Millionen Transaktionen und einem durchschnittlichen CPU-Verbrauch von 0,5 Sekunden pro Transaktion.

Dem Wunsch der Benutzer, ihre Daten selbst zu handhaben und flexibel auszuwerten, setzte die bisherige Datenorganisationsform Grenzen. Der Anwender, der seine Daten mit Reportgeneratoren selbst bearbeitete, mußte sowohl über die Organisationsform als auch über die physische Speicherung der Daten bescheid wissen. Es war schwer, einen Mitarbeiter aus der Fachabteilung aktiv an der Erstellung von Listen zu beteiligen.

Im Jahre 1985 standen mehrere Anwendungssysteme zur Entwicklung an, deren Datenstrukturen gegenüber der Fachabteilung transparent sein sollten. Im gleichen Jahr ware IMS/DB2 verfügbar, was uns veranlaßte, DB2 in die Betrachtung für die Realisierung dieser Systeme miteinzubeziehen. Für den Einsatz von DB2 sprachen:

- Gleichzeitiger Zugriff auf IMS-DAten und DB2-Daten,

- Weiterverwenden der bisherigen Kenntnisse bei der Dialogprograminierung,

- Beibehalten der gleichen Benutzeroberfläche,

- Vermeiden des Einsatzes einer bunten Vielfalt von Softwarekomponenten,

- Erstellen von individuellen Auswertungen durch den Benutzer,

- Zukunftssicherheit von DB2.

Das gewichtigste Argument, den Einsatz von IMS/DB2 in Betracht zu ziehen, war die Koexistenz der beiden Datenbanksysteme DL/ 1 und DB2 in einer Anwendung. Dabei war die Forderung, bestehende IMS-Daten ohne Umstellung mit DB2-Daten zu verarbeiten, unverzichtbar.

Der Datenmodellierung kommt besondere Bedeutung zu

Nachdem die grundsätzliche Einsatzmöglichkeit von DB2 feststand, beschäftigte sich eine Arbeitsgruppe damit, die Entscheidung zum Realisieren der neuen

Anwendungssysteme mit DB2 vorzubereiten.

Die Gruppe hatte die Aufgaben:

- Installieren von DB2,

- Testen der Funktionen,

- Erarbeiten von Namenskonventionen,

- Testen der verschiedenen DB2-Produkte wie DBEDIT, QMF/ QBE, DXT

- Realisieren einer Pilotanwendung PL/l-TSO

- Erarbeiten von Vorschlägen zur Einsatzmöglichkeit

- Ausarbeiten eines Schulungsplans.

Der Abschlußbericht der Arbeitsgruppe war die Basis für die Realisierung der anstehenden Anwendungen mit IMS/DB2.

Der Datenmodellierung kommt bei neuen Informationssystemen besondere Bedeutung zu. Erst ein klares und sauberes strukturiertes Datenmodell schafft die Möglichkeit für den Endanwender, seine Daten mit geeigneten Werkzeugen selbst zu bearbeiten. Die Einbeziehung eines kompetenten Endanwenders in der Modellierungsphase und bei der Vergabe der Namen für Objekte und Datenfelder fördert die Akzeptanz des Anwendungssystems bei den späteren Nutzern.

Basis war die Datenmodellierung von Codd

Das bisherige Vorgehen beim Aufbau von Datenmodellen für hierarchische Datenbanken orientierte sich stark an der späteren physischen Implementierung. Das konzeptionelle Datenmodell für die neuen Anwendungen entwarfen wir völlig losgelöst von der späteren Implementierung. Die Theorie der Datenmodellierung von Codd war unsere Basis.

In einem iterativen Prozeß zwischen Systemanalytiker, einem Mitarbeiter aus der Fachabteilung und dem Datenbankadministrator entwickelten wir die Datenmodelle der Anwendungen. Zuerst lag das Modell in grafischer Form vor und wurde dann detailliert durch die Tabellen mit ihren Datenfeldern. Aufgabe des DBAs und des Systemanalytikers war es dann noch, das konzeptionelle Datenmodell in die dritte Normalform überzuführen. Als Ergebnis der Modellierung lagen abschließend vor:

- grafisches Datenmodell,

- Datenfeldkatalog mit der Fachabteilung abgestimmte Namen,

- Tabellenaufbau und Festlegung des Primärschlüssels.

Um die Vollständigkeit des Modells zu überprüfen, wurden die einzelnen Anwendungsfunktionen am Datenmodell noch einmal diskutiert.

Das konzeptionelle Datenmodell beinhaltete alle Daten, die die zu realisierende Anwendung benötigte (Eingabe) oder erzeugte (Ausgabe). Vor der Implementierung war festzustellen, welche Daten: - - bestehende Datenbestände betreffen,

- allgemeine Daten darstellen oder

- anwendungsspezifisch sind.

Unser Ziel war, die Daten möglichst redundanzfrei zu speichern und auf bestehende Datenstrukturen Rücksicht zu nehmen. So bewirkten neue Daten, die logisch zu bestehenden IMS-Datenbanken gehörten, eine Anpassung der IMS-Datenbanken. Durch die Anpassung der IMS-Datenbanken an die neuen Gegebenheiten erhofften wir uns, ein späteres Umstellen der bestehenden IMS-Daten zu erleichtern. Alle weiteren Datenstrukturen des Modells setzten wir 1:1 in ein physisches DB2-Datenmodell um. Bewußt realisierten wir die DB2-Tabellen in der dritten Normalform, um so die Konsistenz der Daten einfach zu beschreiben und sicherzustellen sowie spätere Neuerungen in weiteren DB2-Releasen nutzen zu können.

Für jede Tabelle Primärschlüssel als Index

Um sicherzustellen, daß die Tabellenzeilen im Sinne des Relationen-Modells eindeutig durch den Primärschlüssel beschrieben werden, implementieren wir für jede Tabelle den Primärschlüssel als Index. Bei einigen großen zusammengesetzten Schlüsseln war es notwendig, einen Stellvertreter zu definieren. Dessen Wert wird durch einen Hashalgorithmus aus den unsprünglichen Key-Feldern ermittelt.

Weitere Indizes (zum Beispiel Fremdschlüssel) bauten wir in dieser Phase nicht auf. Der Bedarf zusätzlicher Indizes wurde später mittels der Explainfunktion aus den kodierten SQL-Statements abgeleitet.

Im allgemeinen definiert der Datenbankadministrator die DB2-Objekte, die sich anhand unserer Namenskonventionen voneinander unterscheiden und eindeutig einem Arbeitsgebiet zuordnen lassen, in Test und Produktion interaktiv über SPUFI unter TSO. Um die Objekte personenunabhängig zu halten, verwenden wir einen besonderen User-Id. Dieser User-Id wird Owner der Objekte. Bei Wechsel des Administrators treten so keine Autorisierungsprobleme auf, die DB2 an die Ownerbeziehung knüpft. Die einzelnen CREATE-Befehle zum Anlegen der DB2-Objekte speichern wir pro Arbeitsgebiet in einer Bibliothek. Diese Member dienen gleichzeitig der Dokumentation der Objekte, dem Wiederanlegen und der Migration in Produktion.

Parallel zur Implementierung des Datenmodells konnte die programmtechnische Realisierung beginnen. Mehrere Schwerpunkte standen dabei an:

- IMS-Dialogprogrammierung,

- IMS/DB2-Batchprogrammierung,

- TSO/QMF-Auswertungen,

- DBEDIT-Programme zur Pflege von Schlüsseltabellen und zum Erstellen von Testdaten.

Zur Unterstützung der Arbeit der Programmierer schufen wir Umwandlungs-, Link- und Bindpanels für DB2-Programme, die auf unsere Umgebung abgestellt sind. Dabei änderten wir das vorgegebene Bindpanel, so daß die Bindanweisungen nach der Ersteingabe abgespeichert werden können und wieder ausführbar sind. Ansonsten änderte sich nichts zu dem bisherigen Vorgehen beim Programmieren. Die Batch- und Dialogprogramme wurden in PL/1 geschrieben. Als Testwerkzeuge standen PL/ 1 -Checkout, BTS und TIP zur Verfügung. Jeder Entwickler hat darüber hinaus die Möglichkeit, seine SQL-Statements unter TSO/SPUFI auf Funktionsfähigkeit zu testen.

Im Gegensatz zur bisherigen IMS-Programmierung wurde auf die Kodierung allgemeiner Zugriffsmodule für den Zugriff auf DB2-Tabellen verzichtet. Das Kodieren der SOL-Statements in den betreffenden Programmfunktionen vereinfachte die Logik der Programme erheblich. Ein weiteres Parameterisieren der SQL-Aufrufe erschien uns zu aufwendig. Die Restriktionen bei Einsatz von Views schreckten uns damals ab, diese in Programmen zu verwenden. Um Datenunabhängigkeit der Programme von einer Tabelle zu gewährleisten, ist der Einsatz einer View auf eine Tabelle aus heutiger Sicht, durchaus zu überlegen.

Zur Vorbereitung der Realisierung der neuen Anwendungen wurden zwei Mitarbeiter als Datenbankadministratoren geschult. Alle an den Projekten beteiligten Entwickler erhielten eine Ausbildung in DB2Anwendungsprogrammierung und QMF. Die Ausbildungsdauer betrug pro Mitarbeiter 10 Tage und wurde teilweise bei IBM und in internen Schulungsveranstaltungen durchgeführt. Im Selbststudium eigneten sich die Entwickler den Umgang mit DBEDIT und SPUFI an. Mitarbeiter aus den Fachabteilungen wurden bisher nicht im Umgang mit QMF geschult.

Voraussetzung zum Besuch einer Schulung war die Mitarbeit an einem konkreten Projekt. So konnte das Gelernte schnell umgesetzt werden. Es zeigte sich, daß das Umdenken von satzweiser Verarbeitung auf mengenorientierte Verarbeitung Probleme bereitete. Durch gezielte Nachschulung konnte dieses Problem beseitigt werden.

Die Produktionsumgebung ist bei uns, wie bei vielen anderen Unternehmen, von der Entwicklungsumgebung getrennt. Wir betreiben einen TSO-Rechner in der Entwicklungsumgebung und einen IMS/CICS-Rechner in der Produktionsumgebung. Die Systemsoftware wie MVS, DB2, IMS ist mehrfach installiert. Im Störfall dient der Entwicklungsrechner als Back-up-Rechner für den Produktionsbetrieb. Durch Namenskonventionen unterscheiden wir zwischen Entwicklungskomponenten wie Programme und Testdatenbestände und produktiven

Komponenten.

TSO-Rechner in der Entwicklungsumgebung

Die Übergabe von Programmen an die Produktion

erfolgt durch ein definiertes Verfahren. Für die Übernahme von DB2-Programmen mußte das alte Verfahren modifiziert werden. Folgende Probleme traten auf:

In Produktion und Test unterscheiden sich gleiche Tabellen durch den ersten Qualifier. In den Programmen kodieren wir den Tabellennamen voll aus und ordnen nicht durch den Bindprozeß den Qualifier zur. Übergibt der Entwickler so ein Programm an Produktion oder entnimmt es zu Testzwecken, ist vor einer Umwandlung immer eine Anpassung der Tabellennamen nötig.

Zur Lösung des Problems setzen wir den PL/l-Preprozessor ein, der die Ersetzung der Tabellennamen automatisch vornimmt. Derjenige User, der den Bindprozeß anstößt, benötigt die entsprechenden Autorisierungen auf die Tabellen, die das Programm verarbeitet. Da die Entwickler keinen Zugriff auf produktive Daten haben, muß der Bindprozeß durch einen Berechtigten durchgeführt werden. Dieser Berechtigte ist ein Verfahrensuser, der die Autorisierung auf die DB2-Tabellen besitzt.

Das Übergabeverfahren läuft nun folgendermaßen ab:

Der Entwickler ruft spezielle Übergabepanels auf und initiiert einen Batch-Job. Über einen Exit wird der ursprüngliche User-Id durch den Verfahrensuser ersetzt. Analog der Linkanweisungsbibliothek steht eine Bindungsweisungsbibliothek zur Verfügung, in der ein Member gleichen Namens wie der Planname zu finden ist. In diesem Member stehen alle die DBRM-Namen, die zu einem Plan zu binden sind. Der Job kopiert das Sourceprogramm in eine besondere Bibliothek compiliert, linkt und bindet das Programm.

Zu den Aufgaben des DBAs gehören das Definieren und Anlegen der DB2-Objekte in der Produktions- als auch in der Entwicklungsumgebung. Um auftretende Fehler von produktiven Programmen zu rekonstruieren, muß er dabei darauf achten, daß die Entwicklungsumgebung ein spiegelbildliches Abbild der Produktionsumgebung darstellt. Bei der Anlage eines neuen Systems in der Produktion stehen ihm die CREATE-Anweisungen aus der Entwicklungsumgebung als Vorlage zur Verfügung.

Am Abend beginnt der Batchlauf

Das Überspielen von Daten aus Produktionstabellen in Testtabellen beziehungsweise umgekehrt kann wegen der unterschiedlichen DB2-Systeme nur indirekt erfolgen, zum Beispiel Erzeugen einer sequentiellen Datei und Laden mit dem LOAD-Utility.

Nach Stoppen der Online-Verarbeitung am Abend beginnt die Batchverarbeitung. Die Jobs werden bei uns unter dem Jobsteuerungssystern APEs ausgeführt. Auch DB2 bietet die Möglichkeit der Batchausführung. Das Erstellen von DB2-Batchprogrammen verlangt jedoch besondere Aufmerksamkeit. Beim Entwurf der Programme muß besonderes Augenmerk auf die Restartfähigkeit gelegt werden. Bei abnormalen Programmende setzt DB2 automatisch die Datenbankveränderungen bis zum letzten Commit-Punkt zurück. Die klassische Methode der Sicherung der Datenbestände vor Ausführung des Jobs und das komplette Zurückladen der betroffenen Datenbestände nach nicht korrektem Ende, kann nicht automatisch ausgeführt werden. Eine Timestamp-recovery von DB2-Tabellen erfordert Eingriff durch den

Datenbankadministrator und manuelle Steuerung.

Batchprogramme, die IMS-Datenbanken und DB2-Tabellen verändern, können nur als BMP-Programme ausgeführt werden oder müssen mit IMS/DBRC laufen. Bei dem Entwurf der Batchanwendungen versuchten wir, Veränderungen der IMS-Datenbanken und Veränderungen von DB2-Tabellen in unterschiedlichen Programmen zu realisieren. Dadurch erreichten wir, daß diese Programme unabhängig von der Verfügbarkeit des IMS-Onlinesystems ausgeführt werden können.

Programme die IMS-Datenbanken nur lesen und DB2-Tabellen verarbeiten, können ab DB2-Release 1.3 als IMS/DL/l-Programme ausgeführt werden.

Die Konzeption der neuen Systeme sah die Möglichkeit der Endbenutzer vor, ihre Informationsbedürfnisse selbst durch geeignete Abfragemöglichkeiten zu befriedigen. Diese Auswertungsmöglichkeiten sind durch QMF gegeben. Leider erlaubt QMF nur den Zugriff auf DB2-Tabellen und nicht auf IMS-Datenbanken. Dadurch wurde es nötig,

bestimmte IMS-Daten als DB2-Tabellen zur Verfügung zu stellen. Diese Auswertungsbestände werden stichtagsbezogen erstellt.

Zu bemerken sei hier, daß die Dialoganwendungen nur mit den original IMS-Datenbeständen arbeiten. Eine Pflege der Auswertungsbestände ist nicht vorgesehen, da sie bei Bedarf aus den Originaldaten wieder hergestellt werden können.

Ein wichtiger Bestandteil eines Anwendungssystems ist die Möglichkeit, die Daten vor unberechtigtem Zugriff zu schützen und nur autorisierten Benutzern zugängig zu machen. Mit DB2 lassen sich mehrere Wege realisieren. Unser Ziel war, eine einfache, handhabbare und doch wirkungsvolle Zugriffskontrolle zu den DB2-Daten zu finden. Wir wollten erreichen, daß ein großer Teil der GRANT's automatisch bei der Programmübergabe vorgenommen wird. Unsere Vorgehensweise sieht folgendermaßen aus:

Der Verfahrensuser, der die Programme in die Produktionsumgebung einbringt, veranlaßt folgende GRANT's:

IMS-Dialogprogramme:

GRANT BIND ON PLAN xxxx TO DBA-USER

GRANT EXECUTE ON PLAN xxxx TO PUBLIC

Der Schutz der Dialogprogramme wird über den IMS-Transaktionsschutz geregelt.

DB2-Batchprogramme

GRANT BIND ON PLAN xxxx TO DBA-USER

GRANT EXECUTE ON PLAN xxxx TO APEX-USER

Batchprogramme, auch BMP-Programme dürfen nur unter APEX und der Kontrolle der Arbeitsvorbereitung ausgeführt werden.

TSO-Programme

Die Ausführung dieser Programme wird individuell geregelt.

QMF

Analog der TSO-Programme. Bei integrierten Auswertungen ein zentrales Menue, eigene Log-on-Prozedur und eigene Benutzeroberfläche.

Die Einführungsphase war der Prüfstein für die Entscheidung, die neuen Systeme mit IMS/DB2 zu realisieren. Hier mußte sich zeigen, ob die Implementierung eines Datenmodells in der 3NF sinnvoll ist, und wie sich diese Anwendungen in der Produktionsumgebung, in Konkurrenz zu anderen Systemen, verhalten.

Zunächst eine schlechtere Antwortzeit

In der ersten Zeit verschlechterte sich das Antwortzeitverhalten der neuen Anwendungen stetig. Eine Auswirkung auf andere IMS-Anwendungen stellten wir jedoch nicht fest. Bei der Analyse der Probleme machte sich das Fehlen eines Performance-Monitors bemerkbar. Mit Hilfe der Explain-Funktion und enger Zusammenarbeit mit der Systemprogrammierung lokalisierten wir folgende Engpässe:

- falsche Bindparameter, zu empfehlen sind

ISOLATION = CS und für Anwendungen mit hohem Transaktionsvolumen ACQUIRE = ALLOCATE, RELEASE = DEALLOCATE,

- falsche Verwendung des CLOSE-Parameter bei Definition des Tablespace, verwendet werden sollte CLOSE = NO,

- zu kleiner Bufferpool,

- zu kleiner Workspace für die DSNDB07,

- zu geringe Anzahl Locks per User,

- zu hohe Anzahl Locks pro Tablespace,

- falsche Zuordnung der Transaktionen zu IMS-Klassen, dadurch gegenseitigem Behindern,

- falsche oder fehlende Indizes,

- zu niedriges Transaktionsvolumen, dadurch bei jedem Aufruf von DB2 Neuaufbau der DB2-Umgebung,

- schlechte Antwortzeiten beim Aufruf von QMF, da der Produktionsrechner ein IMS-Rechner und kein TSO-Rechner ist.

Probleme ließen sich schnell lösen

Die unter dem vorhergehenden Punkt angesprochenen Probleme, ließen sich schnell lösen, brachten aber nicht den gewünschten Erfolg. Das größte Optimierungspotential fand sich in der Kodierung der Zugriffe. SQL ist eine sehr mächtige Sprache. Gleiche Ergebnisse lassen sich durch unterschiedliche Abfragen erzielen. Der damalige Release-Stand von DB2 erlabute es nicht, alle Möglichkeiten von SQL auszuschöpfen. Aufbrechen komplexen SQL-Anweisungen in mehrere einfache SQL-Statements konnte hier Abhilfe bringen. Nach kritischem Analysieren und Umformulieren der SQL-Statements schaffen wir schließlich die angestrebten Verbesserungen.

Hierbei war die Explain-Funktion eine der wichtigsten Optimierungshilfen. Mit ihr lassen sich die SQL-Statements eines Programmes analysieren und fehlende oder falsche Indizes entdecken. Jedes kritische Programm in der Produktionsumgebung untersuchten wir eingehend auf die Einsatzmöglichkeiten von Indizes, dem Aufruf von Sortiervorgängen und der Verknüpfung von Tabellen. Dabei zeigte sich, daß die Ergebnisse aus der Testumgebung sich nur bedingt übertragen ließen.

Regelmäßige Reorganisation der Table- und Indexspace sind, wie auch bei anderen Datenbanken, notwendig, um gutes Antwortzeitverhalten zu sichern. Zum Überwachen der verschiedenen DB2-Objekte schufen wir QMF-Auswertungen auf die DB2-Kataloge. Wöchentlich werden diese Auswertungen erstellt, um Rückschlüsse auf den Zustand der DB2-Objekte zu ziehen und Reorganisationsmaßnahmen zu verlassen.

Dritte Normalform erwies sich als richtig

Der Einsatz von DB2 als operationales Datenbanksystem hat sich bewährt. Es traten nie Probleme im Zusammenspiel IMS-DB2 auf. Unser Ziel der Integration der Daten über ein Datenbanksystem hinaus, erreichten wir. Die Implementierung des Datenmodells in der dritten Normalform zeigte sich als richtig, da Tabellen in anderen Systemen wiederverwendet werden konnten, und wir mit einem klar strukturierten Datenmodell arbeiten können. Das Antwortzeitverhalten bei Verknüpfungen mehrerer Tabellen in einer Abfrage besserte sich mit jedem neuen DB2-Release. Die generellen Antwortzeiten der IMS/DB2-Anwendungen unterscheiden sich nicht von vergleichbaren IMS-Anwendungen. Was uns nicht befriedigt, ist das parallele Arbeiten auf einem Rechner mit IMS und TSO/QMF. Zwar besteht die Flexibilität jederzeit neben dem Dialogbetrieb die Daten mit QMF auszuwerten, doch sind dabei die Antwortzeiten unbefriedigend. Hier sehen wir noch weitere Verbesserungsmöglichkeiten, auch seitens der IBM.

Das Unternehmen

Die Lurgi GmbH ist der Unternehmensbereish Anlagenbau

Mettalgesellschaft AG (MG).

Die Metallgesellschaft wurde 1881 als Aktiengesellschaft zur Weiterführung eines alten Frankfurter Metallhandelsunternehmens gegründet. Sie stellt eine Gruppe von Gesellschaften mit einer weitverzweigten Organisation dar, die Im Grundstoff und Investitionsgüterbereich wie im Anlagenbau tätig ist.

Die Metallgesellschaft gehört mit einem Weltumsatz von 13 Mrd. DM zu den zwanzig größten Unternehmen der westdeutschen Wirtschaft. Lurgi ist ein weltweit tätiges Unternehmen für Verfahrenstechnik, Ingenieurtechnik und Anlagenbau mit den Arbeitsschwerpunkten Rohstoffe, Energie und Umweltschutz. Lurgi plant, liefert und baut schlüsselfertige Fabriken und Einzelanlagen für alle Industriebereiche einschließlich der erforderlichen Infrastruktur.