Historical Facts

• Vorgeschichte: Realtime-Backup zwischen Berlin und Frankfurt (1984/85)
• Vertikale Komprimierung in autarken Einheiten/Matrizen (1985)
• Sensationelle K-Effekte – extreme Performance (1985)
• limes datentechnik gmbh entwickelt FLAM (1985)
• Volle Abwärtskompatibilität bis zum 1. Prototyp (seit 1985)
• Beim ersten Konzernkunden wird der Einsatz ständig erweitert (seit Januar 1986)
• FLAM Universal-Version mit Zugriffsmethoden auf Datensätze (seit 1986)
• FLAM für 60 Plattformen: Integrierbarkeit in Standardverfahren (seit 1986)
• FLAM mit Exits für individuelle User-Module (seit 1990)
• FLAM-sub: FLAM als Subsystem bzw. I/O-Treiber unter z/OS (seit 1992)
• Sehr erfolgreicher Einsatz in VSAM-Applikationen (seit 1992)
• FLAMFILE als Member in einer FLAMFILE / Sammeldatei (seit 1993)
• Backup Restart durch autarke Einheiten in FLAM (seit 1993)
• ADC: Hoch effiziente dynamische Komprimierung (seit 1999)
• Suchen – ohne zu dekomprimieren, z.B. für SEPA-Archive (seit 1999)
• Paralleles und serielles Splitting für optimierten Datenaustausch (seit 2000)
• AES Integration in alle Funktionen von FLAM (seit 2004)
• FKME / FKMS: Key Management Extension / System (seit 2005)
• Verschlüsselung mit Co-Prozessoren, z.B. CPACF (seit 2007)
• FLAM-sub erfüllt PCIDSS bzgl. End-to-End-Security (seit 2009)
• Logische Elemente, Netzwerkfähigkeit, Komponenten und offene Standards (ab 2014)
• Fazit

Für die West-Berliner Filialen einer deutschen Großbank sollte ein Realtime-Backup-Netz zwischen Berlin und Frankfurt aufgebaut werden. Angesichts der Masse an Daten/Dateien sowie der damaligen Netzgeschwindigkeiten war dies schwierig. So kam es zu der Idee, diese Daten vor der Übertragung zu komprimieren. Die damals bekannten Verfahren waren bzgl. aufzuwendender Ressourcen (CPU-Zeit, RAM, etc.) und deren Folgen (Paging, Elapsed Time, Beeinträchtigung anderer Prozesse, etc.) nicht praktikabel.

Es kam zur Beantragung der Patentierung einer Technik zur vertikalen (verlustfreien) Komprimierung von statisch strukturierten Daten mittels Run-Length-Compression in Spalten (Bytes) auf der Basis von autarken Einheiten/Matrizen, die mit Daten(sätzen) unterschiedlicher Formate (fixe/variable Länge) aufgefüllt wurden. Das war ein bis dato in der kommerziellen IT und in div. technischen Prozessen ein noch unbekanntes Verfahren zur Datenkomprimierung. Das Verfahren ist auch in wissenschaftlichen Bereichen effizient, wenn die Daten strukturiert sind und ausreichend vertikal Redundanzen aufweisen, z.B. Messdaten, Daten in der Lebensmittelindustrie (Daten wg. Nachweisplichten), etc.

In Tests zeigte sich, dass man die für den damaligen Zahlungsverkehr typischen Daten um bis zu 95% und in der Industrie Stücklisten (Teilelisten) sogar um bis zu 98,5% komprimieren konnte. Bei Messdaten mit starker Streuung der (binären) Messwerte (ggf. sogar Werte aus Gleitkomma plus Mantisse) kam man immerhin auf mehr als 65%, z.B. im Wetterdienst.

Das Verfahren ist für Daten dieser Art als Software-Lösung extrem performant realisierbar, insbesondere für die in Assembler codierte Mainframe-Version.

1985 erfolgte beim AG Bad Homburg v.d.H. die Gründung einer Firma zwecks Umsetzung des Patents in ein marktgerechtes Software-Produkt – zunächst für Mainframe-Anwender (IBM, Siemens).

Das Software-Produkt erhält den Namen FLAM: Frankenstein-Limes-Access-Method. Es entsteht zu Präsentationszwecken ein Prototyp: FLAM Version V1.0 für MVS und BS2000.

Damit konnte man Daten nun „flambieren / deflambieren“.

Alle Folgeversionen zum Prototyp FLAM Version V1.0 sind voll abwärtskompatibel.

Die Bank hatte mehr als 40 Rechenzentren mit unterschiedlichen Plattformen und Datenbank-Systemen. Man brauchte für das nächtliche Abgleichen der Änderungen in diesen Datenbanken unbedingt eine Software zur Komprimierung.

Dieser Vertrag besteht noch heute. Die Breite der Anwendung im Konzern nahm und nimmt immer noch ständig zu.

Es erfolgte die Freigabe einer Universal-Version, die auf alle Systeme, die auf strukturierten Datensätzen aufbauen (Mess-, Finanz-, Verwaltungsdaten sowie Druck-, Stück-, Adresslisten, Job-Protokolle, etc.), portierbar ist.

Zwecks Öffnung als Zugriffsmethode für sequentielle und index-sequentielle Dateien (z.B. ISAM, VSAM) wurde eine in Applikationen integrierbare Satzschnittstelle geschaffen. Ab dieser Version konnte FLAM auch als Unterprogramm oder Ersatz für den IO eingesetzt werden.

In der Zeit von 1986 bis heute wurde FLAM kompatibel für 60 Plattformen implementiert. Das schaffte die Möglichkeit, FLAM in verschiedenen Verfahren im Datenaustausch, z.B. in Clearing-Verfahren zum Standard zu erklären.

Dabei musste eine Fülle an Konvertierungsproblemen gelöst werden, um die Kompatibilität der Zeichen, Felder, Formate, etc. sowie ein übertragunsgerechtes Format des FLAMFILEs für das jeweilige FT-Produkt/Verfahren zu gewährleisten. Im Zahlungsverkehr gehörte dazu auch ein Format, das trotz Komprimierung abdruckbar und für den File Transfer als Textdatei konvertierbar blieb (EBCDIC <=> ASCII).

Zu den sehr vielen Plattformen, die zum Standard im Zahlungsverkehr gebraucht wurden, kamen auch noch Vermittlungssysteme (Switches) in globalen Mobilfunknetzen zwecks Sicherung (lokal) und Übertragung von Messdaten an zentrale IT-Systeme für das internationale Clearing von Mess- und Abrechnungsdaten (billing records) von Netzbetreibern und Providern sowie deren Plattformen zur Weiterverarbeitung.

FLAM verbreitete sich rasch im Kreditwesen nicht nur bei den Instituten, deren Verbänden und Verlagen, sondern auch bei Dienstleistern für die im Bank- und Börsen- sowie Kreditwesen nahe standen. Dazu kam auch das Clearing der Kartenbetreiber sowie das Handling mit Karten beim Bestellen und Authentisieren.

Die Anwender von FLAM müssen seitdem nicht wissen, was der „Leser“ für ein IT-System zur Verarbeitung eines mit FLAM erstellten FLAMFILEs hat oder haben wird. Man kann so auch FLAMFILEs dekomprimieren, die auf einem System erstellt wurden, das es längst nicht mehr gibt. Dabei orientiert sich FLAM bei der Dekomprimierung an die für das betreffende System standardmäßigen Codierungen der Zeichen und die Formatierung der Daten. Man kann auch nach eigenen Vorgaben eine konvertierte Ausgabe steuern.

Das betrifft auch archivierte Original-Dateien aus der „Vergangenheit der IT-Welt“, die einfach nur, um sie zu konvertieren, mit FLAM verarbeitet werden.

Auf Bitten von Anwendern wurde FLAM um User-Exits erweitert. Dadurch kann man an Stellen, an denen der Input/Output stattfindet, auf diese Daten zugreifen und individuell Einfluss nehmen. Man muss FLAM deshalb nicht in eine Applikation integrieren.

Um die Integration von FLAM in Applikationen zu vereinfachen und vollkommen transparent zu gestallten, wurde ein Subsystem für den Zugriff auf das DMS (Data Management System) des MVS entwickelt, sodass FLAM wie ein I/O-Treiber zwischen Applikation und dem MVS integriert werden kann (Zusatz-Produkt). Es genügt der Parameter "SUBSYS=FLAM" im DD-Statement. Die Integration kann sowohl in Applikationen mit sequentieller als auch index-sequentieller Verarbeitung erfolgen.

Ein Großkunde setzte dies sofort in der täglichen Verarbeitung von Massendaten – in Form hunderter VSAM-Dateien – ein. Es wurden etliche grundlegende VSAM-Probleme zum Vorteil dieser Zugriffsmethode en passant gelöst. Die Effekte bezüglich Einsparung an CPU-Zeit, Plattenspeicher und Elapsed Time in einem komplexen Prozess waren und sind noch immer sensationell. Das liegt allein an der Tatsache, dass in autarken Einheiten (Matrizen) komprimiert wird, wobei sogar Sätze mit variabler Länge zugelassen sind. FLAM arbeitet mit einem stark optimierten, eigenen VSAM Key Management, das auch Wiederholungen im Original-Key der Anwendung zulässt.

FLAM kann beim Komprimieren beliebig viele Dateien (wie Member in einer Bibliothek) zu einem FLAMFILE konkatenieren. Selbstverständlich kann man nicht nur auf jedes einzelne Member sondern auch innerhalb eines Members wieder gezielt auf autarke Einheiten (Segmente/Datensätze) zugreifen.

Bei der Datenübertragung (z.B. per FTP, RVS, FTAM) kann man in der Regel nur einzelne Dateien übermitteln. Durch diese Funktion in FLAM konnte und kann man noch immer beliebig viele kleine Dateien beim Erstellen des komprimierten FLAMFILEs zu einer Datei zusammenfassen.

Ein Kunde hat z.B. problemlos mehr als 16.000 Dateien aus einem alten Archiv mit FLAM komprimiert und dabei zu einem FLAMFILE konkateniert, das auf allen von FLAM unterstützten Systemen/Plattformen kompatibel gelesen werden kann. Das macht einen File Transfer extrem effizient, wenn mehrere Dateien gleichzeitig an eine oder verschiedene Adressen zu versenden sind.

Man arbeitet automatisch „end-to-end“, d.h. man verbindet das Client-System des Absenders mit dem des Empfängers. Funktionen wie die De-/Komprimierung im FT/Server können unterdrückt werden. Somit muss der Empfänger das einzelne Member erst „bei Bedarf“ dekomprimieren. Dabei kann er Konvertierungsfunktionen nutzen. - Später kam mit AES (Standard) das Ver-/Entschlüsseln dazu.

Eine spezielle Applikation für den verschlüsselten Datenaustausch brauchte eine Lösung, mit der die zu übertragende, beliebig große Datei bei Unterbrechungen durch Störungen nicht die Wiederholung der gesamten Übertragung erforderlich macht, und zwar als einen in sich voll integrierbaren Prozess incl. Komprimierung und Verschlüsselung. Durch die Bildung autarker Einheiten war das mit FLAM kein Problem. Man kann auf eine solche autarke Einheit, die bereits komprimiert und verschlüsselt übertragen wurde, zurück positionieren und nur den Vorgang komplett neu wiederholen.

Nach mehrjähriger Forschungs- und Entwicklungsarbeit erfolgte die Freigabe eines für autarke, mit beliebigen Daten gefüllte Segmente (max. netto 64 KB) hocheffizienten Komprimierungsverfahrens MODE=ADC (Advanced Data Compression), das die Komprimierung in einem einstufigen Prozess (straight forward) erlaubt. Das ist ganz wichtig, wenn man solche Algorithmen in Zugriffsverfahren integrieren will.

Darauf basierend wurden die Zugriffstechniken durch ein sehr effizientes Suchverfahren erweitert, sodass man in komprimierten Daten suchen kann, ohne sie zu dekomprimieren. Eine Bank benutzt diese Möglichkeiten z.B. für das Selektieren von einzelnen Buchungen aus einem mit FLAM komprimierten riesigen Archiv (seit neusten sogar mit SEPA-Transaktionen im XML-Format), wobei jeweils nur unterschiedliche Teile (Feldinhalte) einer Buchung für den Suchaufruf bekannt sein müssen.

Es gab bereits eine Speziallösung für diese Bank für DTA-Dateien (altes Format aus dem deutschen Zahlungsverkehr), mit der man in dem auf Magnetbändern mit FLAM erstellten Archiv Buchungen sehr effizient suchen konnte. Dabei wurde noch vertikal komprimiert und noch nicht mit AES verschlüsselt.

Um bei großen Dateien die Menge an Daten einzuschränken, welche mit einmal übertragen werden müssen, bzw. um parallele Übertragungswege besser ausnutzen zu können, wurde auf Kundenwunsch das parallele und serielle Splitting von FLAMFILEs bei deren Erzeugung eigeführt.

• Integration von AES – ab Version 4.0 – (seit 2004)

Die Standard-Verschlüsselung AES wurde in FLAM integriert. Dabei werden die autarken Segmente mit abgeleiteten Keys so verschlüsselt, dass man trotz Verschlüsselung gezielt wie bei der index-sequentiellen Verarbeitung auf solche Segmente zugreifen, diese entschlüsseln und dekomprimieren kann. Es finden diverse Prüfungen statt, z.B. über MACs (kryptografische Checksummen). Die Input-Daten können auch 1:1 in so ein Segment übernommen werden, wenn der Anwender nur verschlüsseln will. Member eines konkatenierten FLAMFILEs können analog behandelt werden. Selbst die Suchverfahren lassen sich so anwenden, dass man beim Suchen nicht mit entschlüsselten (klaren) Segmenten arbeitet.

Es bietet sich die Möglichkeit, auf ganz einfache Weise beliebige Verschlüsselungsverfahren und Key-Management-Systeme zu adaptieren. Dazu benutzt man die FKME (FLAM Key Management Extension). Es besteht hierdurch auch die Möglichkeit der Verknüpfung von FLAM mit einem im betreffenden System verfügbaren HSM (Hardware Security Modul).

Muss der Anwender den Key und/oder das Verfahren, mit dem verschlüsselt wurde, ändern, genügt es, die Änderung auf den Header des FLAMFILEs zu beschränken. Die verschlüsselten Segmente/Member incl. MACs müssen nur kopiert werden.

Über dieses Service-Provider-Interface wurde zum Beispiel eine PCIDSS-konforme Lösung für die Bestellung von Debit und Creditkarten geschaffen, welche mitlerweile weltweit zum Einsatz kommt.

Es wurde das Zusatz-Produkt FKMS entwickelt, das die Probleme der Key-Generierung, -Verwaltung und -Verteilung (Authentisierung) für Kunden löst, welche keine eigene kryptographische Infrastruktur betreiben. Das FKMS stellt die Schlüssel für einen spezifischen FKME auf Basis eines einfachen Rollenkonzepts zur Verfügung.

IBM entwickelte einen Co-Prozessor (CPACF), mit dem man u.a. gemäß AES Standard verschlüsseln kann, um CPU-Zeit zu sparen. In FLAM wurde ein Modul integriert, das erkennen kann, ob diese Technik zur Verfügung steht und benutzt werden darf. Falls ja, wird dynamisch auf diese Technik zugegriffen. Anderenfalls arbeitet FLAM mit der bis dahin standardmäßigen AES Software-Implementierung. Folglich bleibt FLAM kompatibel zu allen FLAM-Versionen, die standardmäßig mit AES ver-/entschlüsseln können.

Dieses Vorgehen kann z.B. auf z/OS über das FLAM-Subsystem in eine Applikation integriert werden; auf anderen Plattformen bietet FLAM die entsprechenden Interfaces. Das bedeutet: Jetzt hat man eine perfekte Lösung, die dafür sorgt, dass klare Daten nicht die betreffende Applikation bei ihrer Entstehung verlassen und auch nicht außerhalb einer Applikation entschlüsselt werden. Man muss folglich immer erst dann entschlüsseln und dekomprimieren, wenn die klaren Daten tatsächlich innerhalb der betreffenden Applikation gebraucht werden, ohne das die Applikation hiervon etwas mitbekommt.

Das ist die sicherste Lösung für End-to-End Security. Damit erfüllt der Anwender die Anforderungen des PCIDSS (Payment Card Industry Data Security Standard).

• Logische Elemente, Netzwerkfähigkeit, Komponenten und offene Standards – ab Version 5.x – (ab 2014)

Die Verallgemeinerung der Zugriffsmethode zu Elementen macht es mit FLAM erstmals möglich, neben physischen Dateiformaten auch logische Datenformate (XML, ASN1, SWIFT, etc.) zu verstehen und zum Beispiel nach Elementen, wie einer Bankleitzahl in flambierten Daten zu suchen oder zwischen logischen Formaten (SEPA, SWIFT, DTA) zu konvertieren.

Die Netzwerkfähigkeit trennt die lokale Komprimierung und/oder Verschlüsselung von der Remote-Ablage der Daten in FLAM-Archiven (sichere Cloud).

Das Komponentenmodell ermöglicht den schnellen Austausch von Verfahren (Suites), das Lesen von unterschiedlichen Quellen (Dateien, Stream, Datenbanken), die Übertragung über unterschiedliche Netzwerke (IP, SSL/TLS, MQ) und die Speicherung von flambierten Daten in unterschiedlichen Ablagen (Datei, Cluster, Datenbank).

Die Unterstützung von offenen Standards, wie zum Beispiel UNICODE, GZIP, OpenPGP, Base64 bei den Originaldaten macht mit FLAM5 das Lesen und Schreiben von wesentlich mehr Datenformaten möglich als bisher. Hierbei kann man neben den verschiedenen IO-Verfahren beliebig viele unterschiedliche Konvertierungen mit einer abschließenden Formatierung der Daten verbinden. Hierdurch wird es zum Beispiel möglich, in einem Job-Step unter z/OS eine Datei blockorientiert aus dem USS zu lesen, die Daten von Base64 in eine binäre Darstellung zu überführen, diese mit OpenPGP zu entschlüsseln, mit BZIP2 zu dekomrimieren, den Zeichensatz von UTF-16LE in IBM1141 zu ändern und sich das Ganze in Textsätze mit ASA-Steuerzeichen in eine VBA oder FBA Datei unter MVS schreiben zu lassen. Hierbei brauchen wir keine temproäre Datei und nehmen jedes Byte/Zeichen nur einmal in die Hand, was sehr viel Rechenzeit und temporären Speicher erspart und gleichzeitig die Sicherheit erhöht.

• Fazit

Basis all dieser Entwicklungen ist die autarke Einheit von Datenmengen, mit der alles 1985 angefangen hat, weil die vertikale (spaltenweise) Komprimierung strukturierter Daten sonst nicht praktikabel gewesen wäre.