With FLAM support, we want to fulfil the high demands of our customers. When FLAM is implemented as an infrastructure, our customers' critical systems often depend on the availability of the data that we manage with FLAM. Qualified support is therefore an important aspect. This includes professional problem management, which is organised via a ticket system (support@flam.de) as part of our central ERP/CRM. In addition, there is software maintenance, in which backwards compatibility plays a major role alongside support for the latest technologies and operating system versions.

Our customers can also use the ticket system to submit requirements and feature requests, which are then scheduled as part of the release planning process. A newsletter can be used to be automatically informed about important fixes and new releases. We also offer a special newsletter for the connection of a Secure Operation Centre (SOC). This informs your SOC about newly recognised security vulnerabilities in our software or in the external libraries we use in accordance with BSI and NIST specifications. Translated with DeepL.com (free version)

In the download area you will find our entire documentation, the software packages for all platforms, various add-ons and the customisations we have made to external libraries, which we publish on GitHub.

Supported Platforms:

FLAM is currently provided as standard on the following platforms:

• x86 - Windows (MSI) - 32/64
• x86 - Linux (RPM, DEB/APT, PAC, TAR) - 32/64
• x86 - Solaris (Sun, Open (PKG, TAR)) - 32/64
• SPARC - Solaris (Sun, Open (PKG, TAR)) - 32
• Power - Linux (RPM, TAR) - 32/64
• Power - AIX (RPM, TAR) - 32/64
• Power - Solaris (Open (PKG, TAR)) - 32/64
• System z - z/OS (XMIT, SMPE) - 24/31
• System z - z/USS (TAR) - 31/64
• System z - z/LINUX (RPM, TAR) - 31/64
• BS2000 - OSD - 24/31 (nur für FLAM4 Komponenten)

We can set up support for other platforms on request or as part of maintenance. FLAM can be provided very quickly for all Unix, WINDOWS and MAC derivatives (including mobile devices (ARM)). For proprietary platforms, such as zVM, VSE, AS400, etc., support can be set up with a little more lead time.

In the past, we have supported up to 60 different platforms and have ensured that the data exchange between these sometimes very different computers has worked.

Anyone who has created a FLAMFILE on one of these 60 platforms with FLAM can of course unpack it on any of the systems currently supported with FLAM, provided the data is available 1 to 1 as a binary byte stream on the new platform.

Problems and requirements:

To report requirements, feature requests or problems for FLAM or simply to ask technical questions, please send an informal email to our support helpdesk.​

​support@flam.de

The following information is required when reporting problems:

• Version of FLAM or the component being used
• FLAM-Kommando (COMP, DECO, CONV, ARCHIVE, ...)
• Error messages and error trace of FLAM
• List of all changes to the system environment that were made before the problem occurred
• On the admin PC, host console etc: All the information that can be seen on the monitor when an error occurs
• Serial numbers, version numbers and other identifiers for the hardware or software concerned (e.g. computer architecture and operating system of the sending and receiving systems)
• Date and time of the error event
• Severity and priority of the error
• Description of the process during which the error occurred
• Error description, reproducibility
• Description of the hardware and software environment incl. location
• Contact person of the client incl. phone no.
• Name and phone number of the operator who noticed the error

Depending on the type of fault, further information can reduce the overall effort required to analyse and rectify the fault. Such information includes, for example:

• Link listing of FLAM modules
• Trace listings of FLAM components
• Configuration datasets for FLAM
• Dumps, logs, etc.
  

Please note that we can only guarantee the protection of your contact data (see GTC, AVV and TOM for maintenance) and therefore no sensitive data will be sent to us via this unprotected channel (unencrypted email). If we are unable to reproduce the problem at our end and need to access your data to analyse the error, we will go to your secure environment. For this purpose, our employees may sign an NDA and a second DPA in which the TOM refers to the secure customer environment.

We are a pure software company (not a data centre), our software is not tied to us and we do not operate any software for our customers. The responsibility for the results of using FLAM lies with our customers.

Quality assurance:

Our software is developed methodically and in a structured manner using a mixture of Scrum and Rational Team Concert (IBM). The coordinated work of our employees is made possible by project management via our ERP/CRM system (Odoo) and source code management with Git. Both are integrated into the shared development environment VS-Code and Eclipse. Our efficient and agile development model enforces regression tests of the software (continuous integration) with every build (many small tests) and after the changes have been pushed to the central repository (all medium-sized tests). In addition, there are nightly builds in which tests with longer runtimes are executed automatically every night. This allows errors and incompatibilities with older versions on all platforms to be recognised and rectified at an early stage, thus avoiding undesirable developments. A complete run-through takes place every weekend so that we can publish a new version of our software at the beginning of each week, provided no errors occur, which makes FLAM a rolling release.

The quality assurance of our software is supported by the following tools:

• Vulnerability scanner for MISRA and CERT
• ​Static code analysis with Cppcheck and scan-build (Clang)
• Dynamic code analysis via Valgrind under Linux and the HEAPCHK on the host
• In-house developed memory and resource monitoring to detect buffer overflows, double frees and similar problems
• Self-developed test framework for all platforms, which can be used to develop and maintain function, module, component and regression tests simply, quickly and effectively
• Code coverage analysis with Coco from Froglogic as an integral part of our test framework
• The graphical user interfaces under Unix and Windows are tested automatically in the framework with Squish from Froglogic
• For the ISPF panels under z/OS we use x3270 with Phyton scripts (py3270) which we start as a host test remotely via the FLCL on a central Linux server
• zACS scan of our started task (FLAMSTC) on the host

We are planning to develop our test framework (FLTF) into our own open source product, similar to CLEP. Using C code, complex mass tests can be mapped quickly and easily in order to generate a high level of test coverage with just a few lines of code. Regression tests for the customer interfaces and unit tests for the individual components can be written very easily or generated by AI. The tests can be executed fully automatically. All test results are summarised in HTML files so that all tests on all platforms can be viewed by every developer and as part of the automation on the intranet.

Before checking in new code, each developer must build it for Linux, Windows, USS and z/OS and successfully pass all build regression tests. After checking in to the central Git repository, further tests are carried out. If a problem is found, the affected developer will receive an email and their changes will not be merged with the main development branch until the problem is fixed.

In addition, we carry out cross-platform tests to ensure interoperability between the platforms. This means, for example, that output generated on a Linux system is tested for correct readability on a z/OS system and vice versa, but also that cryptographic hardware such as PKCS#11 tokens and IBM CCA devices must work together with our software implementations of the cryptographic algorithms. For standard data formats, interoperability with standard tools such as GnuPG, gzip and 7-Zip is also tested. For our archive formats, the crosstests are also performed across all versions that have been supported over time. This additional time dimension ensures that our software can also read all older versions of our archives, thus guaranteeing 100% backwards compatibility.

All these checks are summarised in a quality gateway on the intranet. Once all tests have been successfully completed and all tools have been given the green light, our quality gateway provides a button for publishing the respective software version.

In addition to the version number that each FLAM delivery has, each individual component also has its own version number. This helps us to determine the exact software version of the customer's installation in the event of support and therefore to be able to offer help promptly. Inconsistent installations can also be recognised more easily.

Another tip from many years of experience:

In addition to confidentiality, FLAM also protects the integrity and completeness of the data. FLAM very often detects transmission or storage errors, even though FLAM itself is not the cause. On the one hand, this leads to unjustified support costs, which we are happy to provide for our customers as part of maintenance. On the other hand, errors can often be found and rectified elsewhere. In this way, major damage has already been avoided and many a customer now uses FLAM for precisely this reason.​