Mit MODE=ADC® resp. MODE=NDC (No Data Compression) soll eine FLAMFILE® ein Unikat sein.
Wer die gleichen Originaldaten noch einmal mit FLAM® und den gleichen Parametern komprimiert, erhält eine FLAMFILE®, die gleich groß ist, aber ganz anders aussieht, d.h. offenbar anders codiert ist: ein Unikat.
Beispiel: Man hat 2 Kartenspiele, die völlig gleich sind. Fallen die Karten herunter, kann man nicht mehr unterscheiden, welche Karte zu welchem Spiel gehörte. Nimmt man 2 Kartenspiele vom Münchner Oktoberfest von 2 Brauereien, dann haben sie einen verschiedenen Aufdruck auf der Rückseite. Man kann sie also unterscheiden.
Das hat nun bei einer FLAMFILE® verschiedene Vorteile.
Die Komprimierung der Daten hinterläßt partiell lesbare Reste, insbesondere wenn in autarken Segmenten gearbeitet wird, weil es immer wieder eine neue Anlaufphase gibt. Solche Reste erkennt man bei dieser Verschleierungstechnik nicht, weil mit der Bildung von 2 Checksummen jedes Byte gezielt verändert wird. Die Entropie im Komprimat ist sehr gut (Streuung der Bytes und deren gleichmäßig verteilte Häufigkeiten).
Mit MODE=ADC® komprimierte Daten mit einer solchen Entropie sind interessant, wenn an die Verschlüsselung bestimmte Anforderungen gestellt werden: Man kann z.B. in einem 2. Lauf diese FLAMFILE® als Input benutzen, mit MODE=NDC arbeiten und mit AES verschlüsseln. Der Input zur Verschlüsselung ist dann "chaotisch". ADC-Komprimierung, CRC-Verschleierung und die Arbeit mit dem NDC "vernebeln" jeden Bezug zum Original bei gleichmäßiger Streuung der Codes (Bytes).
Nun gibt es mit FLAM® die Möglichkeit, beim Schreiben der FLAMFILE® den Output parallel zu splitten, d.h. in Einheiten von 4 Bytes nacheinander immer wieder eine andere von k Teildatei zu bedienen. Man verteilt diese Teildateien so auf k unterschiedliche Standorte/Systeme.
Durch dieses parallele Splitting (» Bermuda Concept®) kann man sich bei Backup-Verfahren und/oder bei der (Langzeit-)Archivierung ganz vom Key Management lösen und zusätzlich auch technisch deutlich sicherer vorgehen. Man kann die Daten sogar an einem der 3 Standorte resp. auf einem der 3 Systeme "verlieren". Man verbessert ferner den Datenschutz, weil es lokal unmöglich ist, Daten zu entschlüsseln/dekomprimieren.
Das könnte man mit einer Verschlüsselung mit einem One-Time-Pad vergleichen, wobei das durch das parallele Splitting fehlende Teilstück einem solchen Pad entspräche, zumal die FLAMFILE® den Charakter eines Unikats hat. Bei einer Aufteilung in 3 Teildateien braucht jeder Standort ein fehlendes Drittel von einem der beiden anderen Standorte.
Im Wiederholungsfall entstünde eine anders codierte, aber gleich große FLAMFILE® mit gleich großen Teilen, die analog in einem solchen Dreieck verteilt und nur als eine in sich geschlossene Einheit wieder entschlüsselt/dekomprimiert werden können. Man kann Teile, die zwar inhaltlich gleich sind, nicht austauschen. Die parallel gesplittete FLAMFILE®, die dekomprimiert werden soll, muss in einem Prozess erzeugt worden sein.
Man kann, um die Wirkung des parallelen Splittings zu verfeinern, einen "Allerwelts- oder Zufallsschlüssel" benutzen, der aufgrund dieser Technik eben gerade nicht geheim gehalten werden muss. Diese Zusatztechnik der Verschlüsselung, z.B. mit AES könnte man auch auf 1/3 der gesplitteten FLAMFILE® und MODE=NDC beschränken, um CPU-Zeit zu sparen. Man kann auch mit der Verschlüsselung aus FLAM® V3.0 arbeiten, die weniger an CPU-Zeit braucht, weil sie eine andere Schlüsseltechnik benutzt.
Anmerkung: Der Verbrauch an CPU-Zeit ist mit FLAM®, MODE=ADC® und AES bei gut komprimierbaren Daten niedrig. Die AES-Verschlüsselung macht gerade 10% bis 20% der Gesamtzeit aus. Ohne Komprimierung würde sehr viel mehr an CPU-Zeit verbraucht werden und das selbst bei Einsatz von CPACF (AES-Prozessor).
Beispiel: Auf einer z/10 unter z/OS braucht ein Großanwender für Massendaten aus dem internationalen Zahlungsverkehr (Clearing) für 42 MB zur Komprimierung plus AES Encryption gerade 1 CPU-Sekunde.
Die System-Plattformen der Standorte dürfen unterschiedlich sein. Und auch die System-Plattform, auf der die parallel gesplittete FLAMFILE® erzeugt wird, darf von denen dieser Standorte abweichen. Man kann an jedem der Standorte das Original wieder erzeugen, wenn man das fehlende Drittel hat, weil FLAM® abwärts- und dabei durchgängig kompatibel ist.
Umgekehrt kann man Dateien/Member beliebig zu einer ganzen FLAMFILE® konkatenieren und diese als eine Einheit (!) wiederum splitten, um die Teildateien auszulagern. Man muss also nicht einzelne Dateien/Member separat behandeln.
Das Bermuda Concept® (3 x 66,7% = 200%) kostet nicht mehr an Volumen, denn man archiviert ohnehin Daten an mindestens 2 Standorten (2 x 100% = 200%). Hat man um 85% komprimiert, ergibt das 2 x 15% = 30% der Originaldaten. Man komprimiert nur in 1 Step; in dem zweiten Step wird das Komprimat (Teildateien) lediglich kopiert/ausgelagert/versendet.
Die Entkopplung solcher Prozesse ermöglicht es, Leerlaufzeiten im Rechner (priority idle) sowie Lücken auf Leitungen zu nutzen. Trotz schneller und kostengünstiger Leitungen bleibt ein erheblicher Vorteil, das Volumen von Prozessen/Daten und die Laufzeiten solcher Anwendungen stark zu reduzieren. Man muss bei Fehlern nur Aktivitäten mit den einzelnen Teildateien wiederholen.
Man muss sich gründlich betriebswirtschaftlich überlegen, wie man mit dem Bermuda Concept® Kosten für Hochsicherheits-Archive und vergleichbare aufwändige Einrichtungen drastisch reduzieren kann, eben weil die Daten nicht an 1 Standort zu 100% verfügbar sind. Mit 2 x 33,3% kann niemand etwas anfangen! Die Abläufe sind voll automatisierbar. Die Auswahl der Hardware resp. System-Plattformen an den Standorten kann frei von dem System erfolgen, auf dem die Teildateien erzeugt wurden resp. in Zukunft gelesen und dekomprimiert werden sollen.
limes®: leistung im grenzbereich des machbaren.
limes®: efficiency at the limit of possibility.
© 1985 - 2011 limes datentechnik® gmbh
