Die Wurzel von FLAM® liegt in einer Komprimierungstechnik, die strukturorientiert, genauer "vertikal" arbeitet: » MODE=CX8 (auf Byte-Basis) und » MODE=VR8 (binär).
FLAM® erzeugt beim Komprimieren grundsätzlich "straight forward", d.h. direkt (ohne Zwischenergebnisse, insbesondere ohne temporäre Zwischendateien) die komprimierte Datei, eine FLAMFILE®. Es wird auf eine "Nach-Optimierung/-Komprimierung" verzichtet.
Das Verfahren wurde 1985/86 in Europa, USA und Japan patentiert.
Mit » MODE=CX7 (auf Byte-Basis) kann für abdruckbare Daten ein effizientes, abdruckbares Komprimat, die "konvertierbare" FLAMFILE®, erzeugt werden, die z.B. per File Transfer während der Übertragung zwischen ASCII <=> EBCDIC (1:1) umcodiert werden darf. Hierbei wird oft FTAM oder FTP mit FLAM® kombiniert eingesetzt. Die Verantwortung für die Auswahl der richtigen Translate-Tabelle liegt beim FT-Administrator, nicht bei den Anwendern auf Sende-/Empfangsseite. FLAM® selbst konvertiert die FLAMFILE® nicht, sondern - wenn erwünscht - per Parameter nur unkomprimierte Daten beim De-/Komprimieren. Natürlich hat der CX7 Einfluß auf den K-Effekt. Der Anwender stellt hierbei die Translate-Funktion ganz in den Vordergrund. Er möchte eben en passant auch etwas komprimieren. Das nutzt nur dann etwas, wenn man wirklich "vertikal" komprimieren kann.
Bei der "vertikalen" Technik wird unterstellt, dass z.B. im Mainframe-Umfeld oder bei klassischen Applikationen (z.B. Buchungsdaten, Teile-Listen in der Industrie, Meßdaten auf Switches, Printfiles) Daten/Sätze/Zeilen meist strukturiert sind (Satzaufbau in Feldern mit zumindest linksbündig gleicher Feldposition/-länge mit Auffüllungen) und dass sich in diesen Strukturen Redundanzen, die sich ggf. nur auf einen fixen Satz-/Feldaufbau resp. die Syntax und weniger auf Inhalte beziehen, einfacher erkennen lassen, ohne dass es einer Strukturanalyse bedarf. Der Strukturaufbau muss nicht bekannt sein. Die Satzlängen liefert z.B. das DMS (Satzlängenfelder/-Delimiter).
Anmerkung: Bei vorwiegend kontextueller Redundanz und/oder bei Verschiebungen der Satzstruktur/Feldposition/Feldlänge resp. durch Optimierung von Druckzeilen wirkt diese "vertikale" Vorgehensweise nur bedingt. Ein Korrektiv kann das virtuelle Umsortieren bilden (siehe unten).
FLAM® kann angepaßt an die System-Umgebung (Betriebssystem) I/O-typische logische/physikalische Formate lesen und interpretiert diese Daten als "Satz" (eine quasi logische Einheit). Der Zugriff erfolgt weitgehend invariant zum Umfeld und ist mithin homogen wie heterogen kompatibel (revisionssicher). Das gilt insbesondere für abdruckbare Daten in ASCII/EBCDIC u.a. Alphabete (z.B. UASCII => 9-Bit-ASCII für 36-Bit-Prozessoren) mit der Option einer Zeichen-/Formatkonvertierung sowie des Wechsels zwischen sequentiellem und index-sequentiellem Zugriff (Access Method). Selbst beim sequentiellen Zugriff kann man Teile einer FLAMFILE® übergehen, ohne zu entschlüsseln und/oder zu dekomprimieren, um gezielt zu suchen/selektieren.
Anmerkung: Weil das Vorgehen von FLAM® schon für damalige Anforderungen außergewöhnlich war und von Banken und Börse in Standards einbezogen wurde, unterstützte uns die Kreditanstalt für Wiederaufbau (KfW) mit Fördermitteln. Es gab nur ganz wenige Softwarehäuser, die gefördert wurden. Unser Konzept überzeugt jeden!
So arbeitet FLAM® "vertikal":
Man schreibt maximal 255 Datensätze in einen Matrix-Puffer (Satzinhalte/-längen getrennt).
Man komprimiert das Satzende, falls dort gleiche Zeichen stehen.
Man sortiert (virtuell) nach (ggf. verkürzter) Satzlänge.
Man "spiegelt" die Matrix spaltenweise.
Man komprimiert die "gespiegelten" Daten (mit "run length" resp. binär).
Weitere Maßnahmen (» MODE=VR8): Stimmt das linke Halb-Byte beim Spiegeln überein, z.B. in abdruckbaren Ziffern, kann man die rechten Halb-Bytes in Bytes zusammenschieben (vgl. packen). Ferner kann man die Daten einer Spalte so behandeln, dass X'00' bis X'0F' Häufungsmengen bildet, um dann das linke Halb-Byte wegzulassen (wie zuvor). Die Spalten, in denen die Inhalte (partiell) stark streuen, werden einfach kopiert. Gilt letzteres für die Masse der Spalten oder ist gar keine Spalten-Struktur erkennbar, dann versagt die "vertikale" Vorgehensweise (Alternative: » MODE=ADC).
Man braucht für die "vertikale" Technik einen Arbeitsspeicher, wie ihn die 255 variabel langen Datensätze resp. Druckzeilen füllen, und zwar doppelt plus ca. 256 KB für die allgemeine Verarbeitung plus 2 x 4 KB für Längenattribute.
Diese Technik verbraucht sehr wenig CPU-Zeit und belegt nicht zu viel Arbeitsspeicher, sonst hätte sie sich 1986 gar nicht durchgesetzt. Man kann nur in autarken Teileinheiten (Matrizen) arbeiten, weil man sonst die Spalten einer ganzen Datei nacheinander spiegeln müsste. So kam die Idee einer "Access Method" auf (Zugriffsmethode auf logische Sätze, d.h. max. 255 Zeilen der internen Matrix).
Außerdem verkürzt(e) die Arbeitsweise von FLAM® die Job-Laufzeit (Elapsed Time) erheblich. Bei der heutigen Speichertechnik ist diese Zeit oft nahezu identisch mit der CPU-Zeit.
Man kann auch eine leere Datei "komprimieren", so dass eine FLAMFILE® entsteht, die dem Empfänger beim Dekomprimieren signalisiert, dass das Original "leer" war. Eine Datei ist leer, wenn sie keinen Satz enthält. Man kann sich auch eine Datei vorstellen, die zwar einen oder mehrere Sätze enthält, die selbst keine Daten enthalten.
Anmerkung zur "vertikalen" Technik:
Zu den ersten "Probanden" gehörten Teilbereiche der Siemens AG, die weltweit Fertigungssteuerungsdaten zu versenden hatten. Der Komprimierungseffekt erreichte über 98% und verblüffte damit alle, die erst gar nicht testen wollten, weil ihnen die Vorgehensweise (vertikal) so absurd erschien wie einst der Sprung "rücklings" über die Latte (Fosbury Flop), mit dem der US-Hochspringer Dick Fosbury in Mexiko-Stadt Gold gewann und der heute Standard ist. In der Automobil-Industrie u.a. Bereichen führt diese "vertikale" Technik immer noch zu Ergebnissen, die kaum ein anderer Algorithmus erreicht bzw. gar nicht erreichen kann, wenn ein Teil der Spalten wie in physischen Messdaten sehr stark streut, weil man keine Kontexte findet und sich auch kaum Häufungspunkte bilden (z.B. Messdaten auf Switches im internationalen Mobilfunknetz lassen sich mit FLAM® so um > 60% komprimieren). Es genügt meist auch nicht, aufeinanderfolgende Sätze mittels XOR zu homogenisieren, um dann "horizontal" vorzugehen. Die Streuung bleibt.
Dieses Basismodell wurde 1999 in FLAM® V3.0 mit einem völlig neuen Algorithmus erweitert:
- MODE=ADC® (Advanced Data Compression).
Man schreibt 64 KB Daten (netto) in einen Segment-Puffer (max. 4.095 Sätze).
Man komprimiert diese Daten "multidimensional", d.h. mehrstufig strukturell (vertikal) und/oder kontextuell (horizontal). Auch hierbei wird ausschließlich "straight forward" gearbeitet.
Als optimale Basis für eine heterogene Kompatibilität wird in Satz-Attribute und -Inhalte (Nettodaten) aufgeteilt; jeder Teil wird für sich komprimiert und die Ergebnisse werden zu einem autarken Komprimat des Segments vereinigt. Bei einem K-Effekt von z.B. 85% sind das als Komprimat ca. 10 KB (insgesamt). Mit einer raffinierten, zweistufigen CRC-Technik wird das Segmentkomprimat verschleiert, so dass unabhängig von einer Verschlüsselung ein Unikat entsteht. Im Wiederholungsfall sieht das (gleich große) Komprimat völlig anders aus. Dieses Komprimat hat eine ausgesprochen günstige Gleichverteilung (Entropie) der Byte-Codes. Ein Bit-Fehler oder eine Manipulation (z.B. durch Hacker) würde sich beim Entschleiern sofort verbreitern, aber nur auf das betroffene Segment-Komprimat. Das ist ein weiterer Vorteil, autark in Segmenten zu arbeiten.
Mit » MODE=NDC (No Data Compression) unterdrückt man den ADC-Modus, weil man nur andere Funktionen, u.a. die Verschleierung, aber eben nicht die Komprimierung nutzen will. Wird eine mit FLAM® komprimierte, verschlüsselte FLAMFILE® erzeugt und dann nochmals mit FLAM® und evtl. ein paar Exit-Modulen, aber mit MODE=NDC und ohne Verschlüsselung verarbeitet, spricht man von "legendieren". Der Beobachter soll möglichst nicht erkennen, dass hier verschlüsselt wurde oder man will Informationen über die Originaldaten "verstecken" (» Verschlüsseln).
Anmerkung: Der ADC ist nicht generell besser als die "vertikale" K-Technik. Sind die Daten in Sätzen stark strukturiert und dabei linksbündig ausgerichtet sowie in den Feldern der Sätze links-/rechtsbündig angelegt, kann es sehr wohl sein, dass z.B. die Komprimierung mit MODE=VR8 deutlich besser ist, zumal virtuell nach Satzlänge umsortiert wird. Die Satzlänge kann charakteristisch für einen Satz-Typ sein.
Beide Techniken arbeiten in autarken Teileinheiten (Matrizen/Segmente). Man kann deshalb nicht von einem Ganz-Datei-Kompressor sprechen. Letzteres gilt in der Regel für die aus dem PC-Umfeld verbreiteten Kompressoren, die dadurch bessere Möglichkeiten haben, redundante Daten effizient als Komprimat zu codieren.
FLAM® erzeugt auch als Ergebnis eine ganze Datei, aber eben als Kumulation der autarken, komprimierten Teileinheiten (Matrizen/Segmente). Dadurch hat FLAM® die Option, als Zugriffsmethode zu arbeiten und diverse Services zu bieten (» FLAM®-bieren).
Der ADC braucht mehr an CPU-Zeit als die "vertikale" Technik, aber der Verbrauch hält sich immer noch gegenüber den Produkten, die sich aus dem PC-Umfeld verbreitet haben, zur Überraschung von Großanwendern in deutlichen Grenzen. Das haben Tests immer wieder bewiesen. Der Aufwand hängt von der Komprimierbarkeit der Daten ab - egal, welchen Kompressor man benutzt. Je schlechter komprimiert wird, desto mehr CPU-Zeit wird verbraucht, weil mehr analysiert und codiert werden muss. Logisch!
Der Arbeitsspeicher, der in einem Aufruf von FLAM® mit MODE=ADC® benötigt wird, liegt nur bei ca. 350 KB - ein erheblicher Vorteil, wenn parallel große Mengen an Dateien de-/komprimiert werden müssen, z.B. weil FLAM® bei Großkunden gleichzeitig hundertfach in einer oder mehreren Applikationen gestartet wird. Auch hier wird die Job-Laufzeit (Elapsed Time) zum Teil drastisch verkürzt.
Jedes Segment hat einen eigenen Header und kann autonom verwaltet werden. Es gibt keine Abhängigkeit von Segmenten untereinander. Nur bei der AES Verschlüsselung werden auf hierarchischer Basis (Reihenfolge: Segmente, Member, File) irreversibel MACs (Message Authentication Code) gebildet und verkettet. Trotzdem kann man einzelne Segmente/Member gezielt lesen/entschlüsseln/dekomprimieren und bedingt modifizieren. Man sorgt bei Suchvorgängen (Selektionen) für ein Minimum an klaren Daten im virtuellen Arbeitsspeicher.
FLAM® kann die selektierten Daten verschlüsselt belassen, so dass die Daten erst entschlüsselt werden müssen, wenn sie bei dem dafür zuständigen, berechtigten Anwender sind (offline-Verarbeitung) und umgekehrt. Dieses Vorgehen ist auch bei PCI DSS (z.B. zur Bestellung von Cards bei Kartenherstellern) vorgeschrieben. Man soll nicht auf einem System (z.B. Server) ver-/entschlüsseln, wenn eine direkte Verbindung zum offenen Netz besteht.
FLAM® ist abwärtskompatibel. Zu jeder Version gibt es eine Vielzahl heterogen kompatibler Versionen für die am IT-Markt gängigen System-Plattformen (Mainframe, Midrange, PC) und deren klassische I/O-Formate mit der Option, Dateien bereitzustellen, die an sich im betreffenden Umfeld nicht kompatibel sind, um Applikationen resp. Emulationen zu unterstützen, die auf solchen Input angewiesen sind. Bei Bedarf kann man für indviduelle Zugriffs-Anforderungen auf Exits/Interfaces, Satz-/Unterprogramm-Schnittstellen etc. zugreifen. Das Format einer FLAMFILE® ist frei wählbar, d.h. unabhängig von dem der Originaldatei resp. der Datei, die (logisch) reproduziert werden soll - ein Vorteil, wenn man Vorgaben einhalten muss, die die betr. Original-Daten nicht erfüllen (z.B. fixe Satzformate auf speziellen Betriebssystemen oder für spezielle Applikationen sowie bei File-Transfer-Produkten).
Beispiel: FLAM® kann auf PC eine Datei lesen/erzeugen, die der Codierung/Formatierung auf einem IBM-Mainframe entspricht und umgekehrt.
FLAM® kann die Daten mit einem von einer Systemkomponente (z.B. HSM) oder ggf. selbst generierten » Zufallsschlüssel (64 Bytes binär) mit AES verschlüsseln. Dieser Schlüssel kann in einem individuellen Krypto-System/Netz unter Einbeziehung der hybriden Kompatibilität verschlüsselt werden, das außerhalb von FLAM® liegt. Beim Datenaustausch zwischen beliebigen Partnern, selbst unter Bedingungen wie dem Wechsel zwischen Key-Systemen, Verschlüsselungsverfahren, System-Plattformen und Anwenderkreisen muss nur dieser Schlüssel im FLAMFILE®-Header "umgeschlüsselt" und wieder signiert werden. Das vereinfacht jedes Key Management (PKI/SKI) und löst nahezu jedes Kompatibilitätsproblem zwischen verschiedensten Systemen/Partnern (inter-/national) im Datenaustausch. Man kann solche Vorgänge auf unterschiedliche Weise höchst effizient optimieren und dementsprechende Services bereitstellen.
Intern kann ein Anwender so unterscheiden, zu welchem Zweck eine verschlüsselte FLAMFILE® erzeugt wurde und damit den Zugriff beschränken. Beim Wechsel der Zuordnung muss man nur den Schlüssel im Header zweckgebunden wechseln, wenn man berechtigt ist.
Beispiel: Man tauscht über eine Art » eNotar® Dokumente/Dateien etc. aus. Der eNotar® ist Zeuge, Backup und Archiv in einem mit lokal jeweils verschiedenen, zweckgebundenen Schlüsseln für den Header. Unabhängig davon hat er seine Schlüssel zum Austausch von Daten mit seinen Mandanten. Er quittiert, nimmt Quittungen in Empfang und gibt sie abgesichert weiter.
Man kann das so organisieren, dass er die eigentlichen Daten nicht lesen (entschlüsseln) kann. Er kann nur den Header gemäß dem Key Management, das bei einem Trust-Zentrum liegt, umschlüsseln. Ein Schlüssel aus diesem System kann entweder verschlüsseln oder entschlüsseln. Die Mandanten korrespondieren nie direkt untereinander. Jeder muss nur mit seinem eNotar® die Daten und Quittungen dazu austauschen. So können auch eNotare untereinander arbeiten, wenn ein Mandant zu einem anderen Nutzerkreis gehört.
Der eNotar® kann für das (Langzeit-)Archiv ein » Bermuda Concept® nutzen, um flexibel und absolut sicher zu arbeiten. Damit braucht er kein auf lange Zeit ausgelegtes zusätzliches Key Management. Und zukunftssicher ist das auch, weil FLAM® auf jede Veränderung kompatibel und sicher reagieren kann - bis hin zur hybriden Kompatibilität zukünftiger Hardware-Komponenten, Veränderungen im Key Management, neuer Verfahren und Vorschriften sowie dem beliebigen Wechsel von Partnern und Partnerkreisen inkl. deren Erweiterungen inter-/national.
"Denkfehler" werden immer wieder in Verbindung mit Druckoutput und Support gemacht.
Wer Druckdaten versenden will, soll sie nicht virtuell aufbereiten und sich dann freuen, dass er diese Daten hochgradig komprimieren kann. Man soll dort die Daten aufbereiten, wo sie letztlich gedruckt werden. Unabhängig davon kann man die Ausgangsdaten meist sehr gut mit FLAM® komprimieren und verschlüsseln, so dass noch ganz andere Effekte entstehen.
Wer für den Support Dumps und andere Daten braucht, die man dann versendet, sollte vorsichtig sein. Werden solche Daten unverschlüsselt übertragen, ist völlig unklar, was in diesen Daten zufällig klar lesbar ist. Und für die Aufbereitung des Dump gilt das zuvor Gesagte (bezgl. Druckdaten). Der Empfänger solcher Daten kann sich in der Regel nicht sofort mit der Analyse befassen. Es fragt sich, ob eine Übertragung (über das offene Netz) überhaupt erforderlich ist. Mit FLAM® kann man auch eine verschlüsselte FLAMFILE® erstellen und einfach auf DVD brennen, die man dann versendet.
» FLAM®-bieren bedeutet: Technologisch Brücken schlagen zwischen Gegenwart und Zukunft in einer globalen Welt.
limes®: leistung im grenzbereich des machbaren.
limes®: efficiency at the limit of possibility.
© 1985 - 2011 limes datentechnik® gmbh
