|
Notes |
|
|
|
Which Version of FLAM?
Can you give us the download URL used?
For which platform? (x86, Power or zSeries) |
|
|
|
|
Please provide platform and full version information:
the current version would be: 5.1.22-28565
The version is part of the package name. |
|
|
|
(0001317)
|
|
Chetan
|
|
2020-07-07 17:02
|
|
FLAM VERSION: 5.1.22-28565 given at path /opt/limes/flam/doc/txt/ABOUT.txt
Platform is 3.10.0-1127.el7.x86_64 0000001 SMP x86_64 x86_64 x86_64 GNU/Linux |
|
|
|
(0001318)
|
|
Chetan
|
|
2020-07-07 17:05
|
|
|
The OS Version is "Red Hat Enterprise Linux Server 7.8" |
|
|
|
|
Please check the checksum with the following command:
sha256sum flam-5.1.22-28565-x86_64.tar.gz
374996e690468828fc3086252bf67c4f7dda3599ff7c13c127f4594eb1ae30e1 flam-5.1.22-28565-x86_64.tar.gz
The URL to this file is:
https://flam.de/en/download/flam/latest/linux/x86/64bit/tar/flam-5.1.22-28565-x86_64.tar.gz [^]
Please also consider to make the installation with the RedHat package manager
(yum) as it does make this kind automatically, and also provides dependency resolution.
|
|
|
|
(0001321)
|
|
Chetan
|
|
2020-07-13 10:18
|
|
Hi Team,
Now ,we have installed Flam5.1.22-28565 license version properly.
Please let us know flam cmd for encryption and description |
|
|
|
(0001322)
|
|
Falk Reichbott
|
2020-07-14 09:23
(edited on: 2020-07-14 09:24) |
|
Hi Chetan
we don't know what you want to make. We expect you want read a file and you want to produce a compressed and or encrypted FLAMFILE. But which kind of file you want to read and for which platform you want to prepare your data?
FLAM is not a compression tool, FLAM is an enterprise service bus for persistent data, with APIs for C/C++, Java, Cobol and PL1, several I/O subsystems integrated in the operating system and batch utilities.
We expect you want to use our batch utility to convert and compress files. FLAM is mainly used to convert text files from UNIX or Windows systems to record oriented data sets on Mainframes or vice versa with character conversion from ASCII or UNICODE (UTF-8/16/32) in a certain EBCDIC code page. But we can also convert XML to CSV or XML/CSV/JSON to a FB or VB structure.
On the other side we support all these strange host records formats also on UNIX and Windows, which is often required if an application ported from mainframe to x86, Power, Sun or something else.
The question is, which kind of data you have and in which form these data is needed on the other side. FLAM use an internal neutral format for different kind of data items. To produce these platform neutral items, we must know which kind of data we read and at decompression which kind of data is required. For the read of data we have a detector to determine if it text or binary, is ASCII or EBCDIC, if there length field in front or delimiter behind the record etc.
The simplest way to produce a FLAMFILE using these detector is.
flcl conv "read.file='pathname*with*wildcards' write.flam4(file='nameforflamfile')"
But in this case we will decompress a GZIP/BZIP/XZ file or decrypt and decompress a PGP file at read, this means that the original content, will be analyzed and if it text then a character conversion to UTF-8 is done and records are build and stored in the FLAMFILE. If your partner read this on z/OS then often a EBCDIC code page is required. If your partner has FLAM5 and use the FLCL then we convert the data from UTF-8 to the correct local character set be default, but if the other side has only FLAM4 or older without Unicode support you must convert the records to the correct EBCDIC code page at write (write.flam4(file='...' ccsid='IBM1141')).
Only the CONV command of FLCL has currently 32000 parameter. To build the command you need, we need to know, which data you will read and how the data is required on the other side. It the other side is a Windows and needs a ZIP-Archive with Text in CP1252 and 0x0D0A as delimiter or does the other side needs a GZIP-File in UTF-8 with 0x0A as delimiter (required for example on Linux) or a FLAMFILE with EBCDIC records for a mainframe. FLAM is expensive, because we can connect application on different platforms (physical file formats) or using different logical data formats (fix or variable data structures vs XML, CSV, JSON).
For example, a banking DP center can use FLAM to convert a money transfer from SEPA XML to a COBOL copybook (fix data setucture) does the transaction (on the old fassion way) and send the answer as SWIFT MT/MX or SEPA massage. The old Cobol application only knows his fix structures, from the XML formats really used for this money transfer the old fashion program knows nothing. The conversion of the records (fixed structure) from BCD encoded amounts and EBCDIC names to XML in UTF-8, from the GZIP compression and the PGP encryption and signing the old Cobol application has no idea, all this can be done for example transparently over our I/O Subsystems.
We don't know what you need, based on that we can not really help you. What kind of data you must read and where and in which form these data is required?
Kind Regards
Falk
|
|
|
|
(0001323)
|
|
Chetan
|
|
2020-07-14 09:33
|
|
Thanks team ..!!
We are now able to perform encryption and decryption properly |
|