Es geht um genau das: Die Frage, wie der Format Level Identifier errechnet wird.
Sicher kommt nun die Frage, wozu das denn ?
Es ist zwar ganz furchtbar, aber ich versuche das mal zu erklären, hoffentlich ausführlich genug, um die meisten, zu erwartenden Fragen abzudecken:
Der Kunde (wer sonst) hält hier eine Reihe von in C# geschriebenen Clients vor, die auf PCs laufen und Daten der AS400 verwenden. Es handelt sich dabei um bis zu 10000 gleichzeitig aktive remote-Anwender. Hierzu wird eine Art "self-made" Level-Check eingesetzt, der die Format Level-IDs der AS400 Dateien gegen diejeniger der der Clients prüft.
Nun kommt der Kracher:
Die Jungs haben bei der Erstellung der C#-Clients von allen Formaten auf der AS400 die Level-IDs ausgelesen, und FEST in den C# Programmen Hard-Kodiert. Is so, kann ich nix dran machen.
Soweit wäre das alles einfach nur hässlich, aber noch kein richtiges Problem, denn "es funktioniert doch". Tatsächlich werden hier, bei einer Änderung eines Formats, alle betroffenen Clients auf Source-Basis geändert (neue Level-IDs reingeschrieben) und neu an die rund 10000 Anwender ausgerollt. Auch das scheint zu funktionieren, auch wenn ich den "Architekten" solcher Verbrechen vermutlich ertränken, hängen und vierteilen würde.
Jetzt aber rächt sich das ganze Ding, weil in Zukunft dieselben Clients auch Daten von anderen (i.e. Linux) System verwenden sollen. Und zwar sollen die Anwender der einen Firma (wie gesagt ein Rechenzentrumsbetrieb) nach wie vor auf der AS400 bleiben, andere aber auf Linux-Systeme gehen. Letzteres ist durchaus OK, weils eben rest mal kleine Piloten braucht um so was umzustellen. Man kann ja schlecht alle Kunden auf einmal über die Klippe stoßen.
Nur: Die Clients sollen nicht geändert werden. Sie sollen, netzwerkbasiert, einfach ihren alten Scheiß weitermachen, und ihre -hardcodierte- Level-ID auf dem Server abfragen.
Und das heißt: Die Linux-Server müssten aus Ihren SQL-Daten (Oracle, MariaDB, was auch immer) eine Level-ID errechnen, die möglichst der original ID der AS400 entspricht.
Grundsätzlich wäre das keine Unmöglichkeit, weil ja die semantischen Zusammenhänge einer Tabellenstruktur im Prinzip auch auf den Linux-Plattformen vorhanden sind: Formatnamen, Felder, deren Längen, Typen und Formate, und deren Reihenfolge z.B.
Aber ich habe dem Kunden schon gesagt, dass sie da wahrscheinlich vergessen können. Ich finde das ganze Konzept auch schlicht Kagge, aber es gilt die IHS-Theorie: Is Halt So.
Da ich nun vom Kunden ja dafür bezahlt werde, Lösungen zu finden, frage ich hier eben mal nach: Gibts es ir-gend-eine Chance, den Algorithmus für die Berechnung des Format-Level-Identifiers nachzubauen?
Gurus, Bitfrickler, Cracks aller Art und Insider bitte ich also herzlich, vorzutreten!
Da die Id ja nicht im C# errechnet wird sondern nur gegen irgendeine Konstante verglichen wird, brauchst du keine Methode sondern nur eine Zufallszahl, die allerdings mit der Tabelle hart verdrahtet und nie wieder geändert wird.
Man muss auch nicht dafür sorgen, dass jede Tabelle eine eigene ID hat, da es durchaus dieselbe ID auf mehreren Tabellen gibt.
Also generiere einfach eine 13-stellige Zufallszahl je Tabelle und gib diese als ID aus.
So ähnlich wird das wohl ausgehen. Mein Entwurf hier macht das im Prinzip, wobei Dein Vorschlag allerdings noch viel simpler ist. Finde ich gut.
Kann aber sein, dass der Kunde erst beruhigt ist, wenn es irgendeinen logischen Bezug zur Dateistruktur gibt. ist ein psychologisches Problem, aber wenn er das will, bekommt er das. Das Prinzip bleibt gleich.
Wer nen Linux-Rechner hat, braucht im Prinzip nur Teile eines Kommentar-befreiten DDS-Formats durch md5sum zu schicken, und fertig ist die Laube.
Wobei md5 länger als 13 ist, deshalb habe ich diese nicht erwähnt.
Ob die IBM das jemals offenlegt, zumal die Antwort dann sein wird: wozu? SQL ignoriert dies doch!
Ja ne, klar, aber ist eine Formsache. (md5 modulo 0xFirgendwas) oder so, das wäre nur ein Nebenschauplatz. Die IDs sind übrigens laut IBM auch nicht garantiert eindeutig (wie das bei Hashes eben so ist).
Bookmarks