Anonymous | Login | Signup for a new account | 2024-12-10 03:31 CET |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0001010 | FL5 | 1.1 FLCL | public | 2020-07-07 14:15 | 2020-07-21 09:41 | ||||
Reporter | Chetan | ||||||||
Assigned To | Ulrich Schwab | ||||||||
Priority | immediate | Severity | major | Reproducibility | have not tried | ||||
Status | resolved | Resolution | no change required | ||||||
Platform | Red Hat Enterprise Linux Server | OS | Red Hat Enterprise Linux Server | OS Version | 7.8 | ||||
Product Version | 5.1.22 | ||||||||
Target Version | 5.1.23 | Fixed in Version | |||||||
Summary | 0001010: Unable to compress and decompress file using Flam version 5.1 | ||||||||
Description | Hi Team, We have downloaded Flam5.1 version TAR file and After untar we have set Environment variable ,Still we are getting error "flcl SYNTAX FLAM flcl: flcl: cannot execute [Exec format error]" Please take this issue on highest priority and let us know proper flam command for compression and decompression. Regards, Chetan baviskar | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0001315) Falk Reichbott (administrator) 2020-07-07 15:16 |
Which Version of FLAM? Can you give us the download URL used? For which platform? (x86, Power or zSeries) |
(0001316) Ulrich Schwab (administrator) 2020-07-07 16:52 |
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 (reporter) 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 (reporter) 2020-07-07 17:05 |
The OS Version is "Red Hat Enterprise Linux Server 7.8" |
(0001319) Ulrich Schwab (administrator) 2020-07-07 17:24 |
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 (reporter) 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 (administrator) 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 (reporter) 2020-07-14 09:33 |
Thanks team ..!! We are now able to perform encryption and decryption properly |
Issue History | |||
Date Modified | Username | Field | Change |
2020-07-07 14:15 | Chetan | New Issue | |
2020-07-07 15:08 | Falk Reichbott | Assigned To | => Ulrich Schwab |
2020-07-07 15:08 | Falk Reichbott | Status | new => assigned |
2020-07-07 15:08 | Falk Reichbott | Product Version | => 5.1.22 |
2020-07-07 15:08 | Falk Reichbott | Target Version | => 5.1.22 |
2020-07-07 15:13 | Falk Reichbott | Target Version | 5.1.22 => 5.1.23 |
2020-07-07 15:16 | Falk Reichbott | Note Added: 0001315 | |
2020-07-07 16:52 | Ulrich Schwab | Note Added: 0001316 | |
2020-07-07 16:52 | Ulrich Schwab | Status | assigned => feedback |
2020-07-07 17:02 | Chetan | Note Added: 0001317 | |
2020-07-07 17:02 | Chetan | Status | feedback => assigned |
2020-07-07 17:05 | Chetan | Note Added: 0001318 | |
2020-07-07 17:24 | Ulrich Schwab | Note Added: 0001319 | |
2020-07-07 17:24 | Ulrich Schwab | Status | assigned => feedback |
2020-07-07 17:25 | Ulrich Schwab | Note View State: 0001319: public | |
2020-07-13 10:18 | Chetan | Note Added: 0001321 | |
2020-07-13 10:18 | Chetan | Status | feedback => assigned |
2020-07-14 09:23 | Falk Reichbott | Note Added: 0001322 | |
2020-07-14 09:24 | Falk Reichbott | Note Edited: 0001322 | View Revisions |
2020-07-14 09:33 | Chetan | Note Added: 0001323 | |
2020-07-21 09:40 | Ulrich Schwab | Status | assigned => resolved |
2020-07-21 09:40 | Ulrich Schwab | Resolution | open => fixed |
2020-07-21 09:41 | Ulrich Schwab | Resolution | fixed => no change required |
Copyright © 2000 - 2024 MantisBT Team |