FLCL.XCNV(1)

NAME
flcl.xcnv - `Extended data conversion`

SYNOPSIS

PATH:   limes.flcl
TYPE:   OBJECT
SYNTAX: > flcl XCNV(INPUT(),OUTPUT[()...],DIR(),LOG(),NORUN)

DESCRIPTION

The XCNV command reads and writes various data formats, local or remote, on different platforms. It uses the read and write routines for original data of FLAM. More precisely, it provides all conversion capabilities of FLAM without a FLAM archive in the background.

The XCNV command was designed to provide the full capacity of the powerful Frankenstein Limes Universal Converter (FLUC). It can be used to read and write local or remote data of different kinds, performing optional conversion steps in the process. For example, the XCNV command can be used to read an encoded, encrypted, compressed text file in UTF-16 from a PC platform and write the text records into a mainframe data set with a dedicated record format (FB, VB, ...) in EBCDIC with ASA or machine print control characters. You could even write the same data in UTF-8 with line delimiters as PGP file to a remote (SSH) ZIP archive in one step or vice versa. When using XCNV, you must know precisely what kind of data you read, as you can manipulate any kind of attribute and you have the complete control over each conversion step.

Some of the formats and conversions that XCNV supports:

    • Different kinds of remote access protocols (IP-Nativ, MQ-Series, SSH)

    • Different kinds of data sources (Files, Streams, Tables, Archives)

    • Different kinds of IO methods (Binary, Character, Text, Record, FLAM)

    • Various data encoding formats (HEX aka. Base16, Base32, Base64)

    • Multiple encryption methods (FLAM, PGP)

    • Different compression methods (GZIP, BZIP2, XZ)

    • Powerful character conversion (Unicode, subsets, tranlitteration, reporting, mapping, NFD/NFC, input assistance)

    • Different logical data formatting methods (BIN, TEXT, XML, tables (FB-CSV-VB))

If the XCNV command is too complex or you need auto detection capabilities, you can use the simplified variant called CONV which also provides the full conversion capabilities of FLAM, but with more automatism. The CONV command provides an easy to handle subset of all the supported conversion capabilities. In contrast to XCNV, the CONV command does a lot of auto detection and automated conversions. It tries to guess how the data must be represent on the current system. For XCNV command, the user must know in detail what kind of data is read and can full control how the data is written.

To get syntax information, please use:

       flcl SYNTAX XCNV

To get help for a parameter, please use:

       flcl HELP XCNV.parameter[.parameter[...]]

To read the manual page for a parameter, please use:

       flcl MANPAGE XCNV.parameter[.parameter[...]]
          or
       flcl HELP XCNV.parameter[.parameter[...]] MAN

To generate the user manual for the command, please use:

       flcl GENDOCU XCNV=filename

Parameters can be defined via command line (directly or in a file) or by properties taken from the corresponding property file.

Example.

       flcl XCNV inp(sav.fil(fio.blk(file='ssh://<cuser>@server1/my.file')
                             cnv.hsh(format=bsd)
                             cnv.gzp()
                             cnv.chr(from='UTF-8' to='IBM1141')
                             fmt.txt(suptws)))
                 out(sav.fil(fmt.txt(method=HST)
                             cnv.hsh(algo=SHA512)
                             fio.rec(file='my.output'
                                     falloc(orga=SEQ,recf=VB,recl=512))
                 out(sav.fil(fmt.txt(method=UNIX)
                             cnv.chr(to='latin1')
                             cnv.pgp(pass=s'DUMMY')
                             cnv.hsh(algo=SHA256)
                             cnv.bas(armor())
                             fio.blk(file='~/my.pgp')
                             fio.zip(file='ssh://user@server/my.zip')

Reads a remote file as binary blocks, generates a SHA1 checksum in BSD style, performs GZIP decompression, converts characters from UTF-8 to IBM1141 and formats the data into text records and rest elements in the read operation. On first write, the text elements are formatted without a delimiter, a SHA-512 checksum is calculated for the result and the data elements are written to a record-oriented PS-VB-512 dataset. A second output specification produce a PGP file containing the text in LATIN1 (ISO-8859-1) encoding with 0x0A (UNIX) as delimiter. The binary PGP file is hashed with SHA256 in BSD style and then an ASCII-ARMOR encoding are done. These result is then written to a local file and in a remote ZIP archive.

AUTHOR

limes datentechnik(r) gmbh (www.flam.de)