Since version 5.1.16, FLAM supports conversion of tables in the form of fixed and variable record structures (based on length fields or binary delimiter) and CSV (comma separated values) files. Tables can be encoded, encrypted and compressed like any other file.
Tables can be converted easily between FB/VB datasets, CSV, XML and other file formats. Table columns can be re-ordered, removed or written in multiple representations (adds additional columns).
The table format must be described as row specification. This is a CLP string which contains an unlimited amount of columns. There can be more than one row specification per file, which means that multiple tables may be present in a source.
Support for tables is most useful when used through our stream, byte and record interfaces. For example, a Java or C/C++ application that can process CSV files, can also process tables stored in physical FB or VB datasets by converting back and forth between both formats with FLAM. A COBOL or PL1 application could use the record interface to put or get fixed or veriable structures, but in reality a CVS or XML file is read or written on a local or remote system.
When reading, the format of each column must be described, so that FLAM knows how to break up records into cells of the table. For example, a simple method is to cut records into multiple cells based on a fixed length for each column.
When writing, columns are written in their original format unless a row specification is provided that describes how the columns are joined together with the other elements in this row to a certain data format.
For each column, an unlimited number of pre-processing steps can be specified which are executed before neutralisation of the read element. A pre-processing step could be column decryption or type conversion, e.g. conversion of a BCD number to a neutral FLAM-internal integer representation, or any other supported conversion. When writing, this neutralised number could be written to a column as decimal number string. An unlimited amount of post-processing steps (e.g. encryption) can follow before a table cell is written out.
For hierarchical formats an additional format-specific path must be provided for each column. There can be more than one such path to support different hierarchical formats for the same table. This allows to convert the same table, for example, to a CSV file (no path required), to an XML file (XML path required) and to a Swift MT103 message (TVD path required).
For more information, please read the table formatting sections.