FLUC-Subsystem

Unsere Subsysteme stellen alle Konvertierungen (z.B. HOST FB-Dataset mit EBCDIC-Strings und BCD-Zahlen als PGP-File mit CSV-Format in UTF-8 lesen und schreiben) des FLUC transparent für Anwendungen zur Verfügung. Dies kann genutzt werden, um Standard-Anwendungen (z.B. SAP) um Verschlüsselungs-, Komprimierungs- und Konvertierungs-fähigkeiten zu erweitern. Auf der Host wird es eher genutzt um Altanwendungen fit für diverse neue Sicherheitsstandards (z.B. PCIDSS) zu machen oder Formate (z.B. XML oder CSV) zu schreiben, welche in modernen WEB-Applikationen gebraucht werden. Zum Beispiel nutzen Kunden die Subsysteme, damit dezentrale SAP-Systeme oder das Datawarehouse CSV- bzw. XML-Dateien einlesen können, welche physisch als Dataset auf einer Host liegen. Andersherum kann man Hostanwendungen mit fixen Datenstrukturen versorgen, welche physisch als komprimierte oder verschlüsselte XML-Dateien angeliefert werden.

 

 

Unter Linux basiert die Implementierung auf FUSE (File system in user space). Das FLUC-Subsystem ist hier ein normales Executable, womit man ein Verzeichnis mounten kann. Der Mount-Point ist die logische Sicht auf die Daten. Dieser ist mit einem physischen Verzeichnis verbunden, wo die verschlüsselten, konvertierten und/oder komprimierten Dateien zu finden sind. Welche Dateien, wie zu wandeln sind, wird über eine Konfigurationsdatenbank (Hidden File in physischem Verzeichnis) gepflegt. Am einfachsten ist die Bearbeitung dieser Konfiguration mit der hier dargestellten Oberfläche die im FLCC enthalten ist.

Hier kann man für beliebige Matchstrings (Wildcards) entsprechend Read- oder Writespezifikationen hinterlegen. Beim Write kann man unter anderem auch bestimmen, ob die Datei über die logische Sicht (Mountpoint) wieder lesbar sein soll oder nicht. Auch die Rechte der physischen Datei können beim Schreiben neu definiert werden. Damit ist die Lösung im Gegensatz zu anderen File/Folder-Verschlüsselungen nicht volltransparent und man hat die verschlüsselte Datei (z.B. PGP-File) unter eigener Kontrolle (End2End). Alle Dateien, welche keinem Matchstring entsprechen, können mit Passthrough behandelt werden, so dass ein Mount erstmal nichts verändert, sondern erst mit einem Eintrag in der Konfigurationsdatenbank konvertierte, komprimierte und oder verschlüsselte physische Dateien entstehen. Für das Lesen werden verschiedene Views unterstützt. Beim Mount kann man eine entsprechende View mitgeben, womit man für unterschiedliche Parteien zum Lesen unterschiedliche logische Sichten auf die gleichen physischen Daten einrichten kann. Beim Schreiben ist es unter anderem auch möglich, mehrer Write/Output-Spezifikationen oder I/O-Definitionen anzugeben, womit man gleichzeitig die Daten noch zu einem Partner schicken oder in ein Archive zum Backup legen kann.

 

 

Auf der HOST ist es ein I/O-Subsystem, welches über eine Started-Task bereitgestellt wird und welches man im DD-Statement allokieren kann. Somit kann man einzelne Dateien beim Lesen und Schreiben entsprechenden Wandlungen unterziehen, ohne das die nutzende Applikation von diesen Änderungen etwas mitbekommt. So wäre es zum Beispiel möglich, eine Altanwendung, welche einen FB80-Dataset schreibt, dahingehend zu erweitern, dass diese fixen Datenstrukturen aus BCD-Zahlen und EBCDIC-Strings in eine CSV-Datei in UTF-8 überführt werden, welche als GZIP-File per SSH auf ein UNIX-System geschrieben oder von dort wieder gelesen werden.

 

In beiden Fällen stehen somit alle Konvertierungsmöglichkeiten des FLUC zur Verfügung, welche wie gewohnt über die entsprechenden CLP-Strings genutzt werden können.