Auf welchen Plattformen wird FLAM unterstützt?
Kann ich mit dem FLAM-Subsystem die Tablespaces von DB2 unter z/OS komprimieren und verschlüsseln?
Kann ich mit einer neuen Version von FLAM alte FLAMFILEs noch lesen?
Läuft FLAM unter der neuen Betriebssystemversion?
Auf welchen Plattformen wird FLAM unterstützt?
Generell können wir FLAM auf allen Plattformen bereitstellen, auf denen ein ANSI-C-Compiler zur Verfügung steht. Die standardmäßig unterstützten Plattformen sind hier beschrieben.
Primär kommt FLAM auf Mainframe-, Host- resp. großen Server-Systemen zum Einsatz. Aber auch für Client-Systeme, wie zum Beispiel MAC und Mobile Devices kann relativ schnell ein Support realisiert werden. Wenn Sie hier Interesse haben, können Sie unter Evaluierung eine entsprechende Lösung anfragen. Einfach die gewünschte Plattform eintragen oder direkt Kontakt zu uns aufnehmen, um Ihr Projekt mit uns zu besprechen.
FLAM ist ein Produkt, das die Basis für eine Infrastruktur bilden kann. Man erwirbt ein Nutzungsrecht an den urheberrechtlich geschützten Softwarekomponenten. Neben verschiedenen Lizenz- und Supportmodellen kann man für die verschiedenen Plattformen die unterschiedlichen Produkte bestellen. Wir richten uns hier nach den Bedürfnissen unserer Kunden. Unser Sales Team macht Ihnen gerne ein Angebot.
Die Lizenzkosten für FLAM sind von den folgenden Faktoren abhängig:
- Plattformen
- Anzahl der Installationen
- Kapazität an Ressourcen
- Einsatzorte
Ein individuelles Angebot können Sie bei unserem Sales Team anfordern.
Kann ich mit dem FLAM-Subsystem die Tablespaces von DB2 unter z/OS komprimieren und verschlüsseln?
Dies geht leider nicht. DB2 nutzt zwar als Tablespace einen VSAM-ESDS aber nur, um einen festen, nicht verschiebbaren Bereich auf der Platte zu allokieren. Es greift dann nicht über die IO-Funktionen des Betriebssystems zu, welche das FLAM-Subsystem handeln würde, sondern es werden die IO-Controller hart programmiert. Dies geschieht aus Performancegründen und gibt uns leider nicht die Möglichkeit, den IO über FLAM zu komprimieren und zu verschlüsseln. Hierfür können Sie nur die EDITPROC oder die UDF's des DB2-Encryption-Tools einsetzen.
Wenn die EDITPROC zum Einsatz kommt, kann das FLAM-Subsystem genutzt werden, um mit dem gleichen Schlüssel (meist ein protected Key des ICSF) alle Offline-Datasets (Unload, Backups, Logs, Dumps, usw.) zu verschlüsseln. Hierdurch erhöht sich nicht nur die Sicherheit, sondern auch die Datenbank-Unloads und -Loads laufen durch die Komprimierung wesentlich schneller ab.
Kann ich mit einer neuen Version von FLAM alte FLAMFILEs noch lesen?
Ja natürlich, dies ist ein absolutes Muss. Jedes FLAMFILE, das je erzeugt wurde, kann mit neueren Versionen von FLAM jederzeit und immer gelesen werden.
Läuft FLAM unter der neuen Betriebssystemversion
Da FLAM bis auf die libc (und FLAM4 auf der HOST nicht mal das) keine externen Abhängigkeiten hat (wir programmieren alles selbst) und die alten Funktionen in einer neuen libc in der Regel unterstützt werden, kann man diese Frage immer mit ja beantworten.
Wichtiger ist hier die Frage, ab welcher Betriebssystemversion FLAM denn funktionsfähig ist. Sprich, wie alt ist die LIBC, mit der FLAM gelinkt wurde. Hier gehen wir immer so weit zurück, dass die Mindestanforderungen, welche in der readme.txt hinterlegt sind, keine Probleme darstellen sollten. Mit FLAM4 ist dies vollkommen unkritisch. Bei FLAM5 muss die libc für die Netzwerkfähigkeit zumindest die neuen ANSI-Socket-Funktionen unterstützen, welche IPv6 integriert haben. Dies ist zum Beispiel ab WINDOWS 2000 gegeben. An diesem Beispiel sieht man, dass es in Bezug auf die Betriebssystem-Unterstützung keine Probleme geben sollte.
FLAM4 für die HOST ist vollkommen LE-less programmiert. Man spricht hier auch von Metal. Dies bedingt, dass eine neue Betriebssystemversion eigentlich keine Rolle spielt.
Was vorkommen kann und wo wir über die Softwarepflege versuchen aktuell zu bleiben, ist die Unterstützung von neuen Betriebssystemfeatures. Zum Beispiel kann man ab z/OSv2.1 beim PARM jetzt bis zu 1024 Byte übergeben, was bisher auf 100 Byte begrenzt war. Hier müssen wir nun unsere internen Speicher auf 1024 Byte erhöhen, damit man dies mit FLAM nutzen kann, ohne dass dies Einfluss auf ältere z/OS-Versionen hat. Wovor wir uns scheuen, ist die Nutzung von Funktionen, welche erst ab einen bestimmten Release zur Verfügung stehen, weil wir niemanden dazu zwingen wollen, wegen FLAM ein neues Betriebssystemrelease zu installieren. Es kommt aber vor, dass diese neuen Techniken zum Beispiel CPU-Zeit sparen. In einem solchen Fall implementieren wir die neuen Möglichkeiten, wie zum Beispiel CPACF und haben die alte unabhängige Implementierung als Fallback. Sprich, wer die neuen Prozessoren hat, der profitiert davon, ohne dass man sie zwingend haben muss.