Professionelle Lösungen für komplexe Probleme

Seit Abschluss unseres Informatik-Studiums 1987 arbeiten wir als Db2-Spezialisten auf IBM-Großrechnern.

Das Tolle an unserem Spezialgebiet Db2 ist, dass es hochkomplex und sehr langlebig ist und dass unser Berufsleben zufälliger Weise zeitgleich mit dem Aufkommen von Db2 begann. So konnten wir mit dem Immer-besser-Werden von Db2 parallel unser Knowhow kontinuierlich weiterentwickeln bezüglich Datenbankadministration, Datenmodellierung, Systemprogrammierung, Anwendungsprogrammierung, Systemtuning, Anwendungstuning, Automation, Schulung.

Glücklicher Weise konnten wir unser Knowhow etwas schneller entwickeln, so dass wir zusätzlich zu Db2 sehr gute Kenntnisse aufbauen konnte in z/OS, verschiedenen Programmiersprachen, IMS/DC, Case-Tools, BMC-Produkte, Automation, IMS-Tools und Db2 auf anderen Plattformen.

Unsere Tätigkeit beginnt daher häufig da, wo die übliche Datenbank-Administration aufhört: in der kreativen Entwicklung von effizienten Systemverbesserungen. Und weil wir ungern dieselbe Tätigkeit mehrfach ausführen, haben wir viele Programme geschrieben, die wir ursprünglich nur zur eigenen Produktivitätssteigerung entwickelt hatten. Häufig werden diese Programme dann aber produktiv eingesetzt, weil vergleichbare Produkte teuer oder schlechter sind oder es so nicht gibt.

Einige der nachfolgend beschriebenen Lösungsbeispiele sind nicht mehr aktuell, weil sich Db2 weiterentwickelt, so dass man heute andere Lösungsvorschläge hätte oder Db2 selber die Funktionalität abdeckt. Z.B. ist das 1993 entwickelte LOAD Programm, das eingabekompatibel zum LOAD-Utility war mit vielen Zusatzoptionen, nach Einführung von LOAD SHRLEVEL CHANGE und SQL MERGE obsolet geworden.

Die Programme können gerne auch nach Ablauf unserer Tätigkeiten weiter eingesetzt werden.

Db2/zOS Catalog Navigator

Der Db2 Catalog Navigator ist eine ISPF-Administrationsoberfläche zur Verwaltung und Optimierung von Db2/zOS-Systemen mit Tabellenanzeige aller Db2-Objekttypen, Erzeugung aller Objekt-DDL und -DCL und BIND-Statements mit vielen Generierungs- und Umbenennungsoptionen, Generierungen von JCL für Utilities (COPY, REORG, RUNSTATS, RECOVERY(PIT und DSN1COPY), DSN1COMP), Navigation zwischen den Db2-Objekten, Objektvergleiche aus mehreren Db2-Catalogen, Generierungen von DML, CDL, Commands, Ausgabe der Command-Outputs als Tabelle, dynamischer Aufruf von Stored Procedures. Etwas detaillierter: Eigenschaften: Nach Eingabe des Objekt-Typs (z.B. DB, TS, TB, IX, ...) und Namensfilter (z.B. TB und SYSIBM.SYS%) werden die entsprechenden Objekte mit den Daten aus den Systemcatalog-Tabellen in einer ISPF-Tabelle angezeigt. Vor jedem Objekt können objektspezifische Commands angegeben werden, z.B.: Anzeige der hierarchisch über- oder untergeordneten Objekte rekursiv in einer neuen ISPF-Tabelle Generieren von Utility-Jobs (COPY, REORG, RUNSTATS, RECOVER TOLOGPOINT, UNLOAD-Utility, UNLOAD-Programm, ...) Generieren und Ausführen von Commands (-START, REBIND, -DISPLAY) Generieren und Ausführen von SQLs zOS-Commands für WLM-Environments Anzeige historischer Informationen Generieren der DDL mit optional allen hierarchisch abhängigen Objekten Anzeige der zugreifenden Packages und Pläne oder der genutzten Tabellen und Indizes Anzeige der Space-Objekte Anzeige der static SQLs von Packages, Plänen, Tabellen oder Indizes Anzeige der in static SQLs genutzten HostVariablen Anzeige von -DISPLAY Ausgaben in einer ISPF-Table. Die ISPF-Tabellen werden in einem Stack aufgebaut, so dass nach Drücken von [F3] wieder die vorherige ISPF-Tabelle angezeigt wird. Unterstützung einer Catalog-Historie, um z.B. gedroppte Objekte restaurieren zu können und Generierung der DSN1COPY-Aufrufe dazu. Anzeige der RealTimeStatistik-Informationen. Prüfung des physikalischen Datenbank-Designs (s. Catalog Extrakt- und Analyse-Programm). Anzeige von QuiesceGruppen und JCL-Generierung für gemeinsame PIT-Recovery. Objekt-Verwaltung und Gruppierung für schwellwertgesteuerte Utilityverfahren, z.B.: Sicherungsverfahren mit Durchführung von Full- oder Incremental Copies abhängig von Größe, änderungsaufkommen, manuellen Anforderungen, Alter der vorherigen FullCopy, Anzahl Incremental Copies... mit Sicherung auf unterschiedliches Devices (Platten, Tape gestackt, Tape ungestackt) abhängig von der Größe mit optimaler Verteilung auf eine vorgegebene Anzahl parallellaufender Jobs Statistikverfahren auf Basis der RTS-Daten Reorgverfahren auf Basis von Statistiken Anzeige von Datenelementen unterschiedlichen Typs. Generierung Informational RI aus der namentlichen Gleichheit von typgleichen Columns innerhalb eines Schemas zu einem Primary Key. Historische Anzeige von integritätsrelevanten Db2-Objekten (Foreign Keys, Check Constraints, Trigger). Analyse des dynamic und static Statement Caches (via IFCID 316 und 401). Vergleiche von Objekten zwischen verschiedenen DB2-Systemen. alle möglichen Generierungen

Durchführen eines Db2-SystemChecks

Bei fast allen Db2/zOS-Installationen werden Einsparpotentiale noch zu wenig ausgeschöpft, die Performance kann verbessert und ein höherer Automationsgrad erlangt werden. Wir bieten eine ganzheitliche Analyse unter Berücksichtigung von Systemkonfiguration, 3rd-Party-Tools (BMC), Datenbank-Design und Anwendungsprogrammierung an. Unser Know How: Unsere Berater (Dipl.-Informatiker) haben jeweils mehr als 20 Jahre Erfahrung als Db2- und IMS-Systemprogrammierer und –Administratoren. Ihr Vorteil: Sie profitieren von unserer langjährigen Erfahrung in der Administration großer Datenbank-Installationen. Vorgehensweise: Bestandsaufnahme: Konfiguration, Abläufe, Verfahren, ... Prüfung System-Parameter, Datenbank-Design, Utility-Abläufe, Datenbank-Zugriffe mit eigener Software Berücksichtigung vorhandener Db2-Accounting-Daten Ergebnis: Statusbericht und konkreter Maßnahmenkatalog

Optimierung Db2/zOS Plattenpools

Verfahren zur automatischen, Volume-übergreifenden Defragmentierung, Extentbereinigung, und Db2-optimierte Verteilung der Datasets in einer SMS-StorageGroup. Situation: Eine manuelle Verteilung von Db2-Spaces und Überwachung ihrer Extents ist aufwendig. SMS hat kein Db2-Knowhow und kann die Spaces daher nicht Db2-gerecht verteilen (nach einem CREATE TABLESPACE, LOAD REPLACE oder REORG werden alle Spaces oftmals auf demselben Volume angelegt. Platten-Defragmentierer können nicht plattenübergreifend Extents zusammenfügen und Reorgs zur Extentbereinigung sind aufwendig. Das Verfahren optimiert die Verteilung von Spaces in einem Plattenpool oder einer Db2-Storage-Group und bereinigt dabei Extents. Vorteile: Einsparung von Platten durch bessere Auslastung Einsparung von Reorgs zur Extent-Beseitigung bessere Performance Beseitigung aller Extents (SMS splittet Allocations schon bei Neuanlage in bis zu 5 Extents) Schaffung zusammenhängender Spaces für große Neu-Allocationen Unterstützung Desaster Recovery Überwachung Space-Wachstum Ablauf: Ermittlung der Volumes zur SMS-StoGroup und Prüfung des Volume-Status bzgl. Neu-Allocationen (DISNEW,...) Auslesen der VTOC-Informationen aller Volumes (Extents und Position der VSAM-Cluster, Freespaces) Auslesen des Db2-Catalogs: Zuordnung von Tablespaces und Indexspaces zu den VSAM-Clustern, Zuordnung von Indexes zu Tables Simulation der Defragmentierungs-Sequenz unter Gewichtung verschiedener Parameter: Multivolume Extentzahl Kollision Tablepart <=> Indexpart derselben Table Kollision Tablepart <=> Tablepart derselben Table Kollision Indexpart <=> Indexpart derselben Table Befüllungsgrad Volume freischaufeln aktuelle Usage-Prüfung der VSAM-Cluster (ggf. Ausgabe der Connections und kein MOVE) Erkennen vom Orphan-Datasets Erstellen eines Ladebestandes für eine Db2 Tabelle mit allen Informationen der aktuellen Allocationen auf Extentlevel: ( DBNAME , SPACENAME , PART , DATUM , ZEIT , VOLID , EXTNO , LOWTRK , TRKS , VCAT , SPACETYP , MULTIVOL ) Generierung aller benötigten Statements: -STOP DATABASE(x) SPACENAM(x) [ PART(x) ] ALTER der Spaces auf guaranteed Space für ... DFDSS COPY-Statements mit expliziter Volume-Vorgabe Anpassung der QTY-Angaben im Db2-Catalog ALTER zurück auf vorherige SMS-Werte Start der Spaces im Db2 im vorherigen Status Status: produktive Nutzung, aber eigentlich obsolet, weil SpaceAllocation mittlerweile ziemlich egal ist und Verlagerung mit REORG SHRLEVEL CHANGE unterbrechungsfrei möglich ist.

Db2/zOS Catalog Extrakt- und Analyse-Programm

Situation: Stimmt das Db2 noch mit der gesicherten DDL überein? Wie clone ich ein System oder migriere Strukturen mit Namensänderungen? Wie kann ich auf einen versehentlichen DROP vorbereitet sein? Wie kann ich aus dem -DISPLAY BUFFERPOOL ein ALTER BUFFERPOOL ableiten? Ist mein Datenbank-Design formal korrekt? Das Programm kann diese Fragen beantworten. Das Programm ist extrem schnell durch programminterne Zwischenspeicherung der Daten in dynamischen, ausgeglichenen binären Bäumen. Parameter: Objekttypen und -namen (mit Wildcards) Db2-Version der zu generierenden DDL Umbenennungsoptionen zum Duplizieren oder Migrieren von Objekten Generierungsoptionen (DDL welcher Objekttypen, Berechtigungen, BINDs, ...) Überprüfung des physischen Datenbank-Designs Angabe der SSID und optional eines remoten Db2-Systems oder Catalog-Tabellensatzes für Schatten- oder Historien-Cataloge) ... Ausgabe: DDL von Objekten einschließlich aller abhängigen Datenbank-Objekte sowie DCL der Autorisierungen und BIND-Statements der Pläne und Packages Recovery-Informationen (SYSCOPY, DBID, OBID) ALTER Statements für BufferPools und ggf. GroupBufferPools mit den aktuellen Werten Anzeige Installations-Parameter (DSNZPARM) Überprüfung des physischen DB-Designs, u.a.: ungünstige SEGSIZE ungünstige Column-Sequence in der Table sinnlose Indizes Verdrillung von vererbten Cluster-Indizes nicht minimale Primary Keys ungünstiges Clustering Foreign Keys ohne unterstützende Indizes Erzeugung DDL fehlender Indizdes zur Ünterstützung von RI Beispiele: DB=% PL=% CI=% BP=% generiert die DDL und DCL aller Objekte, die BIND-Statements und DCL aller Pläne und Packages sowie ALTER-Statements für alle BufferPools und ggf. GroupBufferPools. Anwendung: Anzeige von DDL Sichern der DDL vor Datenmodelländerungen Historische Verwaltung von System-Catalogen Migration von Anwendungssystemen regelmäße Sicherungen der DDL Generierung von BIND-Statements Überprüfung des Datenbank-Designs Clonen von Package-Collections

Db2/zOS Utility-Programm

Das Utility-Programm pflegt die über eine Tabelle oder Parameter angeforderten Objekte nach Status- und Verfügbarkeitsprüfung ( -DIS DATABASE(db) SPACENAME(space) ... ) über die Utility-Prozedur ( DSNUTILS ) mit COPY, RUNSTATS, REORG, MODIFY. Bei gerade nichtverfügbaren Objekte wiederholt das Programm die Durchführung, bis entweder erfolgreich oder eine Endezeit erreicht ist. Es können z.B. alle Tablespaces gesichert werden durch einen einzigen JCL-Step. Abbrüche treten (fast) nicht mehr auf. Es werden viele utilityspezifische Parameter und objektspezifische Schwellwerte unterstützt. 24h-Verfügbarkeit wird bei REORGs mit MAXRO(DEFER) unterstützt, die von einer zweiten Instanz das Programms geALTERt wird, wenn keine Locks auf dem Objekt mehr existieren. Status: produktive Nutzung (MODIFY).

Db2 Generierungstool

Programm für beliebige SQLS mit verschiedenen Ausgabe- und Verarbeitungsoptionen. Das Hauptanwendungsgebiet ist die Generierung von JCL, Sourcen und ISPF-Tabellen aus Db2-Tabellen. Das Programm ist in C geschrieben so, dass es Source-kompatibel für z/OS, NT und Unix ist. Im Fehlerfall erfolgt optional ROLLBACK und Abbruch. Input: SQLs auf Dateien mit beliebiger LRECL (bis 32K) CALL PROCEDURE Ausgabeformat: Ergebnisspalten als Records oder Delimited oder ISPF-Tabelle. Die weiteren Parameter sind abhängig vom gewählten Ausgabeformat. Input-Angabe: ISPF-Variablen oder DD-Name (Default: SYSUT1) Output-Art: Record, CSV-Unload, ISPF-Tabelle Output-Angabe: Name der ISPF-Tabelle oder vorgebbare DD-Namen (Default: SYSUT2) Ausgabe-LRECL Float-Zahlen möglichst als Integer darstellen Delimiter und Separator max. Anzahl von FETCHes ReturnCode SQLCODE-spezifisch vorgebbar Default: 0 bei SQLCODE 0, 1 bei SQLCODE 100, 8 bei anderen SQLCODEs oder Fehler Massen-DML mit Blockverarbeitung: UPDATE-, INSERT- und DELETE-SQLs werden bei optionaler Angabe einer Commitfrequenz intern umformatiert in einen Cursor und einen Einzel-SQL auf den Primary Key. Damit können Massen-DMLs auch parallel zum Online ausgeführt werden und sind syntaktische Erweiterungen möglich: DML mit ORDER BY, FETCH FIRST n ROWS, distributet DML. Output: Ausgabe in Datei oder ISPF-Tabelle Recordweise Ausgabe (jede Ergebnisspalte wird zu einer Ausgabezeile) oder delimited Format Resultsets von Stored Procecures werden in eine gleichnamige Declared Global Temporary Table kopiert, aus der sie mit SQL weiterverarbeitet werden können Beispiele: Generierung von ImageCopy-Jobs Anzeige von Db2-Tabellen in ISPF-Tabellen Generierung von SQL INSERT Statements aus den Daten von Db2-Tabellen Erzeugung von SQL zur Prüfung von RI ohne Check-Utility Generierung der DDL von Indizes zur Unterstützung von Foreign Keys Abfrage der ZParms via IBM supplied stored procedure SYSPROC.ADMIN_INFO_SYSPARM und INSERTen der Rückgabe in einer eigenen Tabelle.

WUXPLN: Programm zur Verwaltung der EXPLAIN-Informationen in einem Db2/zOS

Bei Performanceproblemen oder ansteigendem CPU-Verbrauch von Db2-Anwendungen sind die Zugriffspfade ein sinnvoller Analyseeinstieg. Db2 schreibt beim BIND von Plänen, Packages und Trigger bei Angabe von EXPLAIN(YES) die Zugriffspfad-Informationen von statischen SQLs in den DBRMs in die PLAN_TABLE und optional DSN_STATEMNT_TABLE and DSN_FUNCTION_TABLE. Für dynamisches SQL s. Db2 Dynamic Cache Analyse. Zur Unterstützung der Analyse und Überwachung der Zugriffspfade statischer SQLs haben wir ein Verfahren entwickelt: Alle Pläne, Packages werden immer mit EXPLAIN(YES) gebunden, um die aktuellen Zugriffsinformationen zu kennen. Täglich, z.B. nach der Freigabe von Programmen, werden die Informationen aus den PLAN_TABLEs in eine Historie überführt. Dabei werden die aktuellen RUNSTATS-Informationen und Objekt-Eigenschaften (z.B. Anzahl Columns der Indizes) hinzugefügt. Bei der Überführung wird der aktuelle EXPLAIN mit dem vorherigen abgeglichen. Die Anzahl unterschiedlicher Versionen für einen DBRM in der Historie ist variabel. Mit dem Verfahren können folgende Fragen beantwortet werden: Welche Zugriffspfade welcher DBRMs haben sich heute verändert? Wie haben sie die Zugriffspfade eines DBRMs über die Versionen verändert? Welche DBRMs nutzen einen Index mit wie vielen Matching Columns? Welche DBRMs waren durch eine Index-Änderung wie betroffen?

Db2XDYN: Programm zur Analyse der dynamischen (und statischen) SQLs in einem Db2/zOS

Dynamische SQLs sind häufig Ursache für Performanceprobleme oder ansteigendem CPU-Verbrauch von Db2-Anwendungen. Im Gegensatz zum statischen SQL existieren keine dauerhaft im SystemCatalog abgelegten Informationen zur Analyse. Monitor-Traces zur Protokollierung aller dynamischen SQLs sind sehr aufwendig. Aber (seit Db2 V6.1): Wenn der DSNZPARM-Parameter CACHEDYN=YES gesetzt ist, so speichert Db2 nicht nur die Statements im Dynamic Statement Cache, sondern über IFCID 318 werden auch viele Statistikwerte gesammelt, die eine detaillierte Auswertung ermöglichen. Und...: Dieser Cache kann ausgelesen werden über die IFCIDs 316 und 317. Darüber sind alle wichtigen Informationen wie CPU-Verbrauch, Aufrufhäufigkeit, Buffer-Reads und Getpages pro SQL Statement verfügbar. Das Programm liest diese IFCIDs über IFI-READS ein und erstellt entsprechend der Vorgabe eine Hitliste der SQLs. Das Programm ist in REXX geschrieben und nutzt nur Standardfunktionen. So stellt dynamisches SQL keine Black Box in Db2 Systemen dar. Im Modus FOREGROUND wird eine ISPF-Tabelle gefüllt. Im BATCH erfolgt die Ausgabe auf Dataset. Außer den IFCIDs 316 und 317 können auch noch folgende Daten aufbereitet werden: 001/002 Db2 Statistics Record 106 Db2 System Parameters 124 Db2 Current SQL Statement 147 Db2 Monitor Trace Record 225 Db2 Summary Information about Storage Mangager Pools 234 Db2 User Authorization Information 401 Static Statements in EDM Pool (mit IFCID 400)

Db2 Package-Versions-Bereinigung: Verfahren zum Entfernen nicht mehr benötigter Package-Versionen

Das Verfahren ermittelt CONTOKENs in SYSIBM.SYSPACKAGE, die in den LoadLibs nicht mehr existieren und deren Packages daher geFREEt werden können. Besonderes Augenmerk wurde auf die Sicherheit und Performance durch inkrementelle Vorgehensweise bei wiederholten Analysen in evtl mehreren Db2-Systemen gelegt. Parameter: zu berücksichtigende LoadLibs Sicherheits-Eigenschaften Vorgehensweise: Analyse der LoadLibs: Member=>CSECT, Link-Zeitpunkt CONTOKEN-Suche in den Membern (CSECT = Package-name (meistens)) Ergebnis: Protokoll Sicherungs-BIND-Statements FREE-Statements Recovery-BIND-Statements

Db2LOAD: sicheres Db2/zOS LOAD Programm

LOAD-kompatibles, Checkpoint-schreibendes, restartfähiges Programm zum Laden von Daten parallel zum Online und Refresh RI-verknüpfter Tabellen mit vielen zusätzliche Optionen. Vorteile: einfach zu bedienendes LOAD Programm Tablespaces bleiben verfügbar durch optionale Angabe einer Checkpoint-Frequenz keine Pending-States LOAD in einen View LOAD-Statements und DML (UPDATE, INSERT, DELETE) in einer UOW LOAD in Tables verschiedener Tablespaces und Db2-Systeme in einer UOW Restart ohne JCL-Änderung RESUME UPDATE: bei SQLCODE -803 gegen PK-Index wird UPDATE ausgeführt (z. B. zum Refresh RI-verknüpfter Tabellen ) bei Freespace Erhaltung der Cluster-Sequenz optionale Ausgabe der Load-Daten als SQL-INSERTs und SQL-UPDATEs Nachteile: langsam: es werden aus den LOAD-kompatiblen Informationen INSERT- oder UPDATE-SQLs generiert und ausgeführt. Status: wird noch genutzt, aber neuere Db2-Möglichkeiten (Langnamen, Unicode) werden nicht mehr unterstützt.

ISPF-Tools

Zur Vereinfachung von ISPF-Tätigkeiten haben wir im Laufe unserer fast 20 Jahren Tätigkeit im Bereich Db2-Administration eine Vielzahl Tools entwickelt, die die Arbeit im ISPF wesentlich vereinfachen. Viele Commands bieten Point-and-Shoot-Möglichkeit. Unsere effektivsten Tools: wuapply: Anwendung eines Makros auf mehrere Member einer Library. Beispiel: JCL-Anpassungen in allen Membern einer Library wubak: Versioniertes Sichern, Vergleichen und Wiederherstellen von Membern. Gesucht werden Versionen eines Members: 1. gleichnamig in der programmeigenen Sicherung der aktuellen Library 2. gleichnamig in der programmeigenen Sicherung aus einer anderen Library 3. andersnamig ... der aktuellen Library 4. andersnamig ... aus irgendeiner Library 5. durch Anlisten der HSM-Sicherungen für zur Auswahl für HRECOVER wudsn : Direktes Ausführen von Db2-Commands. Im Editor mit cc/cc markierte Commands werden ausgeführt. wuedcrs: Editieren des Datasets an der Cursorposition. Unterstützt werden Wildcards im Library und/oder Membernamen, die zuletzt editierten Datasets (ISPF und eigene Historie), Anzeige der HSM-Informationen nicht mehr vorhandener Datasets für HRECOVER. wuhsm: HSM-Oberfläche zum Massen-RECALL, -MIGRATE, -BACKDS, -RECOVER oder Massen-DELETE von Datasets, die mit DSN-Patterns ausgewählt werden können. wusel: formatfreie Db2-Ausgabe. Im Editor mit cc/cc markierte SQLs werden ausgeführt und ohne Formatierung (wie bei SPUFI oder DSNTEP2) direkten zur Weiterarbeitung ausgegeben. Programmbeschreibung: siehe Db2 Generierungstool. wusrch: Komplexes Suchen. Gesucht wird eingabehängig in der aktuellen Library, allen Librararies eines DD-Namens oder Dataset-Patterns oder allen Datasets des aktuellen ISPF-Bildschirms. Optionale Suchparameter sind Case-Sensitivität, ganzes Wort, Librarytyp, Memberpattern. Anzeige in einer ISPF-Tabelle zum Editieren, Ausführen, Umbenennen,... wusumbr: Komplexe Membersuche. wusumbr ist ähnlich wusrch, aber sucht nach einem Member anstatt nach einem String. wusync: Synchronisation von Libraries. Libraries werden vergleichen und die Unterschiede (sprachspezifisch) in einer ISPF-Tabelle angezeigt, um die Member einzeln oder per Massenaktionen mit dem jeweils neueren Member zu überschreiben. wutep2: Direktes Ausführen von SQLs. Im Editor mit cc/cc markierte SQLs werden ausgeführt durch Aufruf eines modifizierten DSNTEP2s: Optional wird der SQL explaint, kann die Ausgabebreite und Anzahl Ausgabezeilen vorgegeben werden und das Abbruchverhalten im Fehlerfall vorgegeben werden. wutep2s: EditMakro zum Verhübschen des DSNTEP2-Outputs von SELECTs: + Ausgabe einer Columnübersicht mit Anfangsposition der Daten. + Alle Columns werden nur in der von den Daten tatsächlich benötigten Breite ausgegeben (und nicht in der typspezifisch max. Breite) + ColumnNamen werden auf Datenbreite notfalls mehrzeilig ausgegeben. + Auf mehrere Seiten umgebrochener Zeileninhalt wird wieder zusammengefügt. + Jeder SELECT-Output wird in einer eigenen Datei verhübsch und editiert. Status: produktive Nutzung.