SEARCH_DATA.data.push([
[
"flam4_manual_cbd7.html",
"FLAM4 Manual",
"= FLAM4 Manual The new FLAM4 utility conforms to version 4 or older using the new FLUC components. It supports the FLCL FLAM command as a self-contained program. The FLAM command is the default command. It must not be provided on command line. The new FLAM4 utility is backwards-compatible to the old one for Unix, Windows and Mainframes, except: * Member selection * Output name conversion * And the protocol written All differences in detail can be find in the <<CLEP.COMMAND.FLAM,FLAM command chapter>>. This documents contains the complete old FLAM4 documentation in the new HTML format. Since version 5.1.21 of FLAM, the old PDF documentation is no longer supported. Beside the FLAM command, only the INFO command is supported. If you need more functionality please use the FLCL(R) utility. Copyright (C) limes datentechnik (R) gmbh + All rights reserved  ",
"",
""
],
[
"flam4_manual-preface_53ca.html",
"Preface",
"[preface] == Preface The new FLAM4 utility and the corresponding subprogram FLM4UP replace the old FLAM4 utilities and FLAMUPs on Windows and Unix. On z/OS the old FLAM utility and FLAMUP still exist. The new load modules FLAM4 and FLM4UP are additional entries available with FLAM version 5.1. This book will also replace the old FLAM4 documentation for Windows, Unix and Mainframes. The new FLAM command supports the FLAM syntax known form Windows, Unix and z/OS plus few extensions (UNICODE, SSH). To migrate from the old FLAM utility to the new one, the differences (completion codes, log output, input output name mapping, dafault values, etc.) are documented in the <<CLEP.COMMAND.FLAM,FLAM command chapter>> below. For the use of the old utilities and subprograms with this documentation the differences are written to each parameter below. The new FLAM4 utility based like the FLCL utility on the CLE/P library. The CLE/P library was developed by limes datentechnik and released as open source under the ZLIB license. CLE/P is a compiler to provide a platform independent command line interface for each kind of batch processing environment. The CLE/P library provides a lot of features including the <<CLEP.BUILTIN.FUNCTIONS,built-in functions>> used below. For example: We use this library to automatically create this document as part of our build process; If we add a parameter to the CLE/P tables and build the FL5 project this manual will be regenerated as well in order to be always up to date. This manual can by generated with the built-in functions GENDOCU or HTMLDOC provided by CLE/P library by calling the command below: To generate HTML documentation yourself instead of using the pre-built documentation, a service provider DLL must be available. The text file can be fed to Asciidoctor to build a PDF and/or an HTML5 document. ",
"",
""
],
[
"flam4_manual-preface-trademarks_00e1.html",
"Trademarks",
"=== Trademarks Below, you can find all trademarks or registered trademarks of limes datentechnik (R) gmbh. These trademarked terms are marked with the appropriate symbol ((R) or (TM)), indicating registered or common law trademarks owned by limes datentechnik (R) gmbh at the time this information was published. The following terms are trademarks of limes datentechnik (R) gmbh in Germany, other countries, or both: * LIMES(R)     - Short company name of the owner of this document * limes datentechnik(R) - Company name of the owner of this document * FLCL(R)      - Frankenstein Limes Command Line * FLCC(R)      - Frankenstein Limes Control Center * FLAM(R)      - Frankenstein Limes Access Method * FLUC(R)      - Frankenstein Limes Universal Converter * FLIES(R)     - Frankenstein Limes Integrated Extended Security * FKMS(R)      - Frankenstein Key Management System * FKME(R)      - Frankenstein Key Management Extension/Exit * FLAMFILE(R)  - A file based on FLAM syntax * CLE/P(R)     - Command line Executer/Parser ",
"",
""
],
[
"flam4_manual-preface-license_terms_2af3.html",
"License Terms",
"=== License Terms The license terms for all software components owned by limes datentechnik gmbh(R) can be found in LICENSE(.txt) in the installation folder doc/txt or in the partitioned dataset HLQ.FLAM.DOCTXT. Additional license information for external libraries used by this software can be found in ABOUT(.txt). The replacement of external libraries (LGPL) is described following the changelog in the file README(.txt). All license terms of the external libraries are included as files (LICxxxxx(.txt)) in doc/txt folder or in HLQ.FLAM.DOCTXT partitioned dataset. All old FLAM components till version 4 are completely owned by limes datentechnik gmbh (R). Only on Linux systems the glibc is used in unmodified form as prerequisite (part of the operating system, not part of the distribution) based on the LGPL license. The old FLAM4 components don't provide additional about and version commands or functions. The service provider interfaces (exits, extensions) of FLAM are owned completely by limes datantechnik gmbh(R) and provided to our users for individual extension to this software. The driver is conforming to this license terms but LIMES(R) is not responsible for such individual implementations which are not part of our distributen. Our own implementations against these SPIs (e.g. FAVECAV, PKCS#11, IBM-CCA/ICSF) are in sync with the stated license terms here. A lot of this information is generated in the package build process and can be requested over the corresponding built-in commands of our utilities or the corresponding functions of the APIs. To request the current valid state, please use the command or functions below (there are more APIs with analog functions available): The about and version information are also added as appendix to the manual's provided by limes datentechnik gmbh(R). The version information contains version, release and revision number of each component followed by the current build number. The versioning of the different components is independent of each other. The build number must be the same for each component and must correspond to the build number of the installation package. If the build number is not identical for all compiled and linked components, then the installation is wrong.  ",
"",
""
],
[
"flam4_manual-preface-about_limes_6a2c.html",
"About Limes",
"=== About Limes Since 1985, limes datentechnik(R) gmbh has been successfully producing quality software that simplifies data exchange across platforms and across borders (formatting, converting), secures data archiving and transmitting (encrypting, signature) while reducing storage use (compressing), and, finally, allows accessing data without depending on particular platforms or data formats (access method). * Professional management of compressed and encrypted data including   strong access control * Secure data storage (archive) and data transfer * Protection of data privacy, integrity, and completeness * Cutting-edge security technologies for handling of sensitive data   being outsourced, securing clouds etc. * Meeting safety requirements such as 'need-to-know', PCIDSS, etc. * Easy data exchange across borders, platforms, and formats (with regard   to internationalization moves, when migrating, etc.) * Saving of time and money through automation options and reduced   resource utilization (CPU, memory, external storage) * Converting, compressing, encrypting, and signing of data * Reading and writing methods for various data and file formats * Transforming data into a neutral internal format (FLAMFILE(R)) that   allows searching and positioning within encrypted and compressed data * Storage of data in various formats (file, cluster, VSAM, database) * Separating data compression and encryption (client) from data storage (server) * Neutral access to individual data records, data elements, or bytes via various APIs * Connecting solutions to any cryptographic infrastructure with access   control via key-management including periodic or adhoc re-keying * Unrestricted extendibility and adaptability through customer-APIs for   Cobol/PL1, c/C++ and Java (other programming languages on request) * Transparent integration as I/O subsystem, user space file system, ISP,   driver or by incorporating as a subroutine * Scripting, backup, restart and stream capability for switching to automated operation * Programming in ANSI-C and assembler utilizing hardware accelerators   and special instructions of the various platforms * Beside decades of experience with cross-platform and cross-border data   exchange, limes datentechnik(R) stands for protection of your investment   and for lasting reliability due to the uncompromising downwards   compatibility of its products and the friendly customer care provided   as part of its support services. * limes datentechnik(R) not only offers solutions for bulk data handling   in the mainframe environment, it also supports all current platforms   and systems for migrating and long-term archiving. * For more than 30 years limes datentechnik(R), located in Bad Homburg,   Germany, has been providing resilient, error-free, high-quality   software meeting professional standards - guaranteed 'Made in Germany'. ",
"",
""
],
[
"flam4_manual-preface-flam4_overview_33f2.html",
"FLAM4 Overview",
"[[flam4.overview]] === FLAM4 Overview FLAM4 is a software product for vertical and lossless data compression, encryption/decryption for structured data. FLAM4 supports different data formats as well as data exchange between several operating systems including necessary character conversions. FLAM4 is also used for long-term archiving of data. The archived data, which are compressed and encrypted, can be accessed directly, while the read data records are decompressed and decrypted. According to this approach other stored, compressed and encrypted data of the same file are not involved and remain compressed and encrypted. This handling makes FLAM4 100% PCI DSS compliant. ",
"",
""
],
[
"flam4_manual-preface-flam4_overview-introduction_to_flam4_e75e.html",
"Introduction to FLAM4",
"==== Introduction to FLAM4 FLAM4 is a software product for data compression typically used in applications in banking, wholesale and retailing, industry and public administration. FLAM4 is best suited for record-oriented data. FLAM4 compresses the standardized data formats as used in banking with a typical compression ratio of 4:1. For lists of material the compression ratio can be as high as 95% (20:1). Although FLAM was not specifically developed for banking applications, it is now accepted as the optional standard in data compression within electronic funds transfer. FLAM4 is used because of its flexibility, data conversion across platforms and the proven short turn around time. With each new FLAM implementation, new benefits arise for each user without additional costs. It is in the interest of each user to ask for support of FLAM by hardware manufacturers and third party software houses, and to support the installation of FLAM at sites of a business partner with whom electronic data is exchanged. That is the special benefit of FLAM regarding cost effectiveness. FLAM4 uses the algorithm of the Frankenstein-Limes-Access-Method for structure oriented data compression. This method has been patented in Germany, Europe and USA beginning with 19.7.1985. FLAM4 works without pre analysis of the data and without additional tables. This ensures that decompression can be always performed based on the syntax of the compressed file (FLAMFILE) and the FLAM program. This also ensures upward compatibility that allows for long time archiving. FLAM4 does not need any additional specifications about the data to be compressed. The compression method is invariant to file, record, and field formats. However, the compression effect depends on the actual data. Structural distortion mostly leads to worse compression results. ",
"",
""
],
[
"flam4_manual-preface-flam4_overview-principles_of_flam4_0dc1.html",
"Principles of FLAM4",
"==== Principles of FLAM4 The design principles of FLAM: An online data storage media files compressed with FLAM4 can be used in connection with both sequential and index sequential access methods without additional intermediate conversions. The same transparency applies for data exchange (file transfer) in a heterogeneous network between computers with different hardware and different operating systems. Formatting of the compressed files can be controlled in a way that all requirements are met for maximum memory usage and for portability on any type of transmission lines with any file transfer product. This is especially true for punched card formats (80 columns) and for FTAM formats. Compressed records can be created in both fixed and variable format. FLAM4 is even able to generate compressed files in a printable format. This allows to convert the compressed file from EBCDIC to ASCII and vice versa at any time. At the other hand, code conversions can be performed in combination with compression or decompression. Optionally FLAM4 can convert file and record formats. This allows FLAM to solve compatibility problems between heterogeneous systems or version dependent file management systems. Restrictions regarding record format (fix), duplicate key, etc. are neutralized using FLAM as an access method. A FLAMFILE can be used on all computer systems where FLAM is available. The FLAMFILE is the base for the access method FLAM without sacrificing the different system specific access methods of the particular file management system. A FLAMFILE can be converted during decompression into any file or record format as specified by the user. This guarantees continuity. An archived FLAMFILE can always be processed (especially decompressed) on any system. This insures independency from a particular operating system. However, it must be made sure, that the storage medium can be read by the hardware (e.g. tape unit). Also the FLAMFILE should not be converted into a system dependent format of any given archiving product. FLAM4 encrypts data and seals the compressed files using checksums for better protection. The FLAMFILE has internal synchronisation points, which allow to restart decompression after an erroneous data block caused by physical defects. Requirements for revision and controlling are fully supported. FLAM4 provides a variety of interfaces derived from a real file management system with index sequential access. FLAM can be executed as a subprogram under control of an application. User exits within FLAM4 allow pre- and postprocessing of uncompressed records as well as FLAMFILE records. FLAM4 is an optional compression standard for different applications used in German banking, within the framework of Banking Communication Standard (BCS), TARGET2, SEPA, and others. ",
"",
""
],
[
"flam4_manual-preface-flam4_overview-advantages_of_flam4_2468.html",
"Advantages of FLAM4",
"==== Advantages of FLAM4 Below is a list of advantages separated between data in transit and data at rest (archiving). * Cost reduction by volume reduction (e.g., packet switching) * Faster transmission by virtualisation * Implicit acceleration of other transmissions * Change to slower physical lines possible * Lower access and operation costs * Less transmission faults due to physically slower transmission * Solution for technological bottlenecks * Increase of potential transmission frequency * Reduction of network node and buffer workload * More efficient reaction possible to line breakdowns, transmission   faults, or operating mistakes * FLAMFILE in parking position saves space, allows immediate restart of   transmission and can be archived * Compatibility of the FLAMFILE in heterogeneous networks * Portability of the FLAMFILE due to format options * Convertibility of the FLAMFILE for printable data by   Pre- and post character conversion possible * Conversion of record and file formats possible (Utility) * Transparency of FLAMFILE to other applications * More remote controlling possible due to volume reduction * More data exchange via line possible due to volume reduction * More swapping to emergency computer centres possible due to volume   reduction * Automated remote archiving possible * Automated remote restore possible * Better data revision due to automated procedures * More data integrity due to check sum technique * More data security due to FLAM typical data encryption * Higher efficiency of additional cryptographic methods * Reduction of data storage on all media * Fewer requirements for physical space * Less multi volume files (Disc, Tape, Floppy) * Fewer requirements for power, air conditioning, protection * Less fixed capital required * Less overhead in archive and more continuity * Less I/O, less work load for channels * Probably fewer controllers, I/O ports, buffers * Acceleration of batch copy processes and of backup-/restart processes,   thus more resources for automation of computer centre * Shorter processing times and shifts * Additional data protection due to FLAM access * Integrated protection against manipulation due to FLAM syntax * Process typical data encryption * Effective protection of logical deleted data * Innovative (combined) access methods for index sequential and   logically blocked data in heterogeneous environments. ",
"",
""
],
[
"flam4_manual-preface-supported_systems_a24f.html",
"Supported Systems",
"=== Supported Systems FLAM4 is available for a variety of operating systems. For example: ",
"",
""
],
[
"flam4_manual-command_line_parser_abde.html",
"Command Line Parser",
"[[clep.main]] == Command Line Parser The COMMAND LINE PROCESSOR (CLE/P(R)) is a user application programming interface for several platforms including Windows, Unix and z/OS that simplifies and standardizes parameter string processing. The CLE/P(R) provides two separate functions: * COMMAND LINE PARSER (CLP)   - Compiles a parameter string from a command to a data structure * COMMAND LINE EXECUTOR (CLE) - Supporting execution of different commands with parameter strings The COMMAND LINE EXECUTOR provides a list of commands and some built-in functions, please use <<CLEP.BUILTIN.MANPAGE,MANPAGE>>, <<CLEP.BUILTIN.HELP,HELP>> and <<CLEP.BUILTIN.SYNTAX,SYNTAX>> to get extensive information about these capabilities. Additionally the built-in function <<CLEP.BUILTIN.GENDOCU,GENDOCU>> can generate a complete or a part of the user manual. To read the parameter of a command, a compiler (CLP) is applied. To see the regular expressions (lexemes) and the corresponding grammar, please use the built-in functions <<CLEP.BUILTIN.LEXEMES,LEXEMES>> and <<CLEP.BUILTIN.GRAMMAR,GRAMMAR>>. The return/condition/exit codes of the executable and the reason codes of the different commands can be reviewed with the built-in function <<CLEP.BUILTIN.ERRORS,ERRORS>>. See sections <<CLEP.APPENDIX.RETURNCODES,return codes>> and, if available, <<CLEP.APPENDIX.REASONCODES,reason codes>> for the meaning of the used return and reason codes. The CLE uses an owner management in order to separate the settings for different clients and a property management for each command. If problems occur, a trace might be activated. For each command execution the owner and environment variables can be defined in the configuration file. To see the current configuration use the built-in function <<CLEP.BUILTIN.CONFIG,CONFIG>>. The default trace file is 'stdout'. If the trace is activated before a trace file is defined, the trace will be printed on the screen. To manage the tracing use built-in function <<CLEP.BUILTIN.TRACE,TRACE>>. Last but not least it is possible to view the license, version and other information about the program. This is the RELEASE build version of the FLAMCLEP. ",
"",
""
],
[
"flam4_manual-command_line_parser-command_line_considerations_63c9.html",
"Command Line Considerations",
"=== Command Line Considerations The command line parser supports abbreviation of keywords depending on the unique first characters. This is only useful if you work in dialog. If the command is specified in a persistent way (e.g. in a script) writing the complete keyword is recommended, to ensure that the script must not be changed to work with a later version of the program. For example: Version X supports only one keyword starting with V (VERSION). Version X+1, supports the keywords VERSION and VERIFY. If you use version X with VER=4711 anything is fine but with with version X+1 it will fail, because one more character is required (VERS=4711) for the keyword to be unique. The same is valid for the required string support. The CLP supports strings without enclosing. These strings depend on the keywords used in a name space. If new key words are added in future version, the string could cause errors and must be enclosed. Concerning this it is recommended to enclose strings if the command is defined in a script. For example: The last item which could result in a damaged command syntax after a program update is the use of implicit array definitions after an assignment, because the end of such an array might change, for example if an array of numbers defined an a switch is the end. In a new version such a switch could be a number with a default value, if only the keyword is defined. In this case the defined number referenced by this keyword is then part of the number array and the parameter is lost. Concerning this it is recommended to use enclosed array definitions. For example: All these capabilities are implemented to be compatible with several existing command lines syntaxes and to limit the effort to port old commands or to simplify the interactive use. But in certain cases, the command interpretation could fail, if not the unique/enclosed variant of keywords, strings and arrays are used. ",
"",
""
],
[
"flam4_manual-command_line_parser-used_environment_variables_b674.html",
"Used Environment Variables",
"[[clep.main.usedenv]] === Used Environment Variables Environment variables can be managed via the operating system or via the FLAM4 configuration. The latter can be managed with the built-in functions <<CLEP.BUILTIN.SETENV,SETENV>>, <<CLEP.BUILTIN.GETENV,GETENV>> and <<CLEP.BUILTIN.DELENV,DELENV>>. To list the current state of all usable environment variables the built-in function <<CLEP.BUILTIN.LSTENV,LSTENV>> can be used. For help messages for each usable environment variable please use <<CLEP.BUILTIN.HLPENV,HLPENV>> There are also some platform-specific mechanisms that can be used to set environment variables: Environment variables are read from the file `.stdenv` in the current working directory or the user's home directory. The file in the home directory is only considered if the file does not exist in the working directory or cannot be read. `DD:STDENV` or the data set name `&SYSUID..STDENV` can alternatively be used to set environment variables. The `STDENV` file allows to define the `FLAM4_CONFIG_FILE`, `FLAM4_DEFAULT_OWNER_ID`, `LANG` and other environment variables in JCL. Example with a z/OS DD name allocation: The definition of the LANG variable outside of the program configuration file is recommended, so that the system character set is defined in each situation. The program configuration filename is used as is. No placeholder substitutions (e.g. `<USER>`) are possible. It might be useful to have a dedicated environment per user on mainframes. In such a case, it makes sense to define the environment in a dedicated file for each user. Since z/OSv2r1 you can also use exported JCL symbols like environment variables. The exported JCL symbols have lower priority than the same environment variable. The service CEEGTJS is called dynamically and the language environment must be in the STEPLIB concatenation to use it. Additionally, all z/OS system symbols can be used in the string replacement (<&LDAY>). The environment variables have the highest priority, followed by the exported JCL symbols. System symbols have the lowest priority. If the variable name is not found, then no replacement is done and the angle brackets are kept in place. For z/OS, the default record format and record length for non-existent output files is `recfm=VB, lrecl=516`. An attempt is made to open an existing file with `recfm=*` for overwriting (DISP=OLD). If this fails, another attempt is made with `recfm=VB, lrecl=516` to write a new file (DISP=NEW). The environment variable `CLP_DEFAULT_DCB` can be used to change this default file mode string. See 'Keyword Parameters for File Mode' for fopen() in _z/OS XL C/C++ Runtime Library Reference_ for more information and for the correct syntax. Beside `recfm` with a valid record format (not + or *) and `lrecl`, the `space` parameter can be set. All other file mode parameters are managed by CLP. Beside all the environment variables managed by CLE it is possible to set all properties as environment variables to override the hard coded default values with CLP. If a property is defined as environment variable and in a property file, then the value in the property file overrides the setting in the environment. The environment variable name for each property is built by the rules below: * convert all characters to upper case * replace all dots (`.`) by underline (`_`) To get a list and help for all properties please use the built-in function `GENPROP` to generate property files. The properties can be defined per owner, per program and globally. The owner-specific definition overrides the program specific definition and the program-specific definition overrides the global definition. Examples: The value string behind the sign (including the comment) will be used as supplement for the command line processor. Aliases are not supported in this case. You can only define properties for the main argument. If a string must be enclosed with apostrophe, please don't use double quotation marks because these are used in addition if a new property file is built based on the environment settings. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. Below you can find the list of static environment variables. * LANG (&FLANGLC_&FLANGCC.&FLANGCS) - The default language and CCSID/encoding string for this platform (Format: de_DE.UTF-8 or de_DE.IBM-1141) * HOME - To determine the home directory on UNIX/WIN * USER - To determine the current user id on UNIX/WIN * CUSER - To determine the current user in upper case * Cuser - To determine the current user in title case * cuser - To determine the current user in lower case * SYSUID - To determine the current user id on z/OS * ENVID (&FLENVID) - The current environment qualifier for key label templates (default value is 'T'  or the first valid letter of &SYSCLONE on z/OS) * OWNERID - Used for current owner if not already defined (used in key label templates (can also be used in file names)) * HOSTNAME - Current host name * MAILADDR - The email address used as sender for outgoing emails (only relevant on z/OS with SYSOUT format set to MAIL) * CLE_QUIET - Disables the normal log output of the command line executer (must set to YES or ON) ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * CLE_SILENT - Disables log and errors messages of the command line executer (must set to YES or ON) ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * CLP_NOW - The current point in time used for predefined constants (0tYYYY/MM/DD.HH:MM:SS) * CLP_STRING_CCSID - CCSID used for interpretation of critical punctuation character on EBCDIC systems (default is taken from LANG) * CLP_DEFAULT_DCB - The default record format and record length in C file mode format (default is 'recfm=VB, lrecl=516' only for z/OS) * CLP_SYMTAB_STATISTICS - Print symbol table statistics to STDERR stream at close (must set to YES or ON) ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * CLP_MALLOC_STATISTICS - Print memory allocation statistics to STDERR stream at close (must set to YES or ON) ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * FL_PLATFORM - Platform definition (WIN/UNX/MAC/ZOS/USS/BS2[.B/.L]) for emulation at read or write operations ** WIN - Choose Windows as platform (CRLF) ** UNX - Choose Unix derivative as platform (LF) ** ZOS - Choose ZOS as platform (NL) ** USS - Choose USS of ZOS as platform (NL) ** VSE - Choose VSE as platform (NL) ** BS2 - Choose BS2000-OSD as platform (NL) ** MAC - Choose MAC as platform (CR) * FL_DEFAULT_ASCII_CCSID - Default CCSID for ASCII character sets (if ASCII machine and LANG, then default is taken from LANG else default is 'ISO-8859-1')) * FL_DEFAULT_EBCDIC_CCSID - Default CCSID for EBCDIC character sets (if EBCDIC machine and LANG, then default is taken from LANG else default is 'IBM-1047')) * FL_PGP_PREF_SYMALG_AES128 (&FLPA128) - Invert order of preferred symmetric algorithms from AES256/192/128 to AES128/192/256 in PGP certificates ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * FL_ALLOW_LOW_ENTROPY - If defined and no source of entropy is available, the random number generate is seeded with a low entropy which may result in weak encryption keys * FL_DEFAULT_CHAR_MODE (&FLCHARM) - Default error handling if character not available in target character set [STOP] ** STOP - Stop at the first non-convertible character ** IGNORE - Ignore non-convertible characters ** SUBSTITUTE - Substitute non-convertible characters ** IDENTITY - Copy non-convertible characters (supported only for single byte conversions) ** TRANSLIT - Activate ICONV transliteration and ignore the rest (MODE=IGNORE SYSTAB=ICONV) * FL_DEFAULT_PGPCCAPARA - Default PGP IBM-CCA (ICSF) parameter (normally not required, only profile and pin (if applicable) or trust store name) * FL_DEFAULT_PGPP11PARA - Default PGP PKCS#11 parameter (LIB=/usr/lib/libsofthsm2,PIN=f'pkcs11.pin') * FL_DEFAULT_PGPRNGPARA - Default PGP key ring parameter (pub='pubrng.pgp',sec='secrng.pgp',pass=f'keyring.pwd') * FL_DEFAULT_CCALIB - Default path/name of CCA library (not required for ICSF) * FL_DEFAULT_CCAPKDS - Default path/name of CCA public key data set * FL_DEFAULT_P11LIB - Default path/name of PKCS#11 library * FL_DEFAULT_P11PIN - Default PIN/passphrase for PKCS#11 token (it is not recommended to use this if authentication is required) * FL_DEFAULT_P11SLOT - Default PKCS#11 slot number * FL_DEFAULT_RNGPUBFIL - Default public key file for key ring implementation * FL_DEFAULT_RNGSECFIL - Default secret key file for key ring implementation * FL_DEFAULT_RNGPASSWD - Default password for key ring implementation (it is not recommended to use this if authentication is required) * FL_INFO_BLOCK_SIZE - Set a custom block size for the INFO command (useful mainly for PGP files) * FL_USAGE_SYSLOG_IDENT (&FLOGIDT) - Activate usage logging to SYSLOG on each platform (in addition to the usage log stream on z/OS) * FL_DEACTIVATE_HW_CRYPTO_ACCELERATION - Deactivate hardware acceleration for cryptographic operations (enforce use of software implementation) * FL_PRIMARY_SPACE_TRK (&FLPRISP) - Default primary space in tracks (only relevant on mainframes, default is 600) * FL_SECONDARY_SPACE_TRK (&FLSECSP) - Default secondary space in tracks (only relevant on mainframes, default is 1200) * FL_DIRECTORY_BLOCKS (&FLDIRBL) - Default directory blocks (only relevant on mainframes, default is 45) * FL_ZEDC_SUPPORT (&FLZEDC) - Controls use of RCF1951 (GZIP) compression in FLAM4 ADC modules (ON, OFF, AUTO(default), threshold (nnn) in percent) * FL_SSH_HOME_DIR - Directory containing SSH key files and known_hosts file (/home/user/.ssh) * FL_GZ_EXPANSION_FACTOR (&FLGZEXP) - Expansion factor for GZIP decompression (default is 5) * FL_GZ_COMPRESSION_FACTOR (&FLGZCMP) - Compression factor for GZIP compression (default is 2) * FL_BZ_EXPANSION_FACTOR (&FLBZEXP) - Expansion factor for BZIP2 decompression (default is 6) * FL_BZ_COMPRESSION_FACTOR (&FLBZCMP) - Compression factor for BZIP2 compression (default is 2) * FL_XZ_EXPANSION_FACTOR (&FLXZEXP) - Expansion factor for XZ decompression (default is 10) * FL_XZ_COMPRESSION_FACTOR (&FLXZCMP) - Compression factor for XZ compression (default is 2) * FL_ZS_EXPANSION_FACTOR (&FLZSEXP) - Expansion factor for ZSTD decompression (default is 10) * FL_ZS_COMPRESSION_FACTOR (&FLSZCMP) - Compression factor for ZSTD compression (default is 2) * FL_KEY_EXPIRE_WARN_DAYS (&FLKEYWD) - Amount of days to warn before a key will expire (default is 90 (3 months)) * FL_RETURN_IF_LOG_WARNING (&FLRLOGW) - If set to OFF, the completion code 0 is returned instead of 1 if a relevant warning is written to the log ** YES - Yes, do it (same as ON) ** ON - Activate it (same as YES) ** NO - No, don't do it (same as OFF) ** OFF - Deactivate it (same as NO) * FL_FAVE_LIBRARY - Set default library for anti virus scanning (default is 'libfave') * FL_FAVE_FUNCTION - Set default function for anti virus scanning (default is 'CLAMAVC') * FL_FAVE_PARAMETER - Set default parameter for anti virus scanning (default is 'clamav.daemon:3310') * FL_CLAMAV_DAEMON - Set default communication parameter for ClamAV client (default is 'clamav.daemon:3310:10') * FL_AVSCAN_READ - If defined, anti virus scanning when reading is activated (corresponding default values must be defined) * FL_AVSCAN_WRITE - If defined, anti virus scanning when writing is activated (corresponding default values must be defined) * FL_AVSCAN_COMPRESS - If defined, anti virus scanning is done on a compressed GZIP data stream (must be supported by service provider) * FL_SYSOUT_MAIL_CLASS (&FLSOMC) - Default class for SYSOUT allocation if FORMAT.MAIL() is used (only on z/OS) * FL_SYSOUT_MAIL_WRITER (&FLSOMW) - Default program for SYSOUT allocation if FORMAT.MAIL() is used (only on z/OS) * FL_LITERAL_CACHE_SIZE (&FLITCS) - Size of the hash table used (by power of 2) for the literal cache (8>=x<=20 (256 to 1.048.576 entries)) * FL_RECORD_FORMAT_MAPPING (&FLRECFM) - If this variable is not set to DATATYPE (is the default), records with length field (RECF=VAR) are used ** DATATYPE - Binary data as binary (RECF=BIN), Text as text (RECF=TXT) * FL_IBM_UNICODE_SERVICE (&FLIBMUS) - Define use of z/OS Unicode Services for simple character conversions to lower performance [AUTO] ** AUTO - Use it, if behavior the same and faster ** ON - Activate it (with round trip conversion) ** OFF - Deactivate it (no use of Unicode Services) * FLAM4MF - Enable Microfocus Enterprise Server support for FLAM and FLUC record interfaces (ccsid/yes/no) * FLAM4MF_TRACEFILE - Enable a trace file for the MF-EDZ stubs supporting the record interface (Windows or Linux filename) * FLAM4MF_STATIC_SYSVAR - Static system variables are read from filename into the environment (filename in EBCDIC or ASCII, Syntax: 'SYMBOL=value', also use 'DD:SYSVAR') * FLAM4MF_DYNAMIC_SYSVAR - Dynamic system variables are read from filename into the environment (in conjunction with the JCL User Exit of MF-EDZ to add dynamic variables) * _EDC_ZERO_RECLEN (&FLZRECL) - Used for handling of empty records (see dedicated <<flcl.handling.empty.records,chapter>> below) on z/OS Beside the static environment variables there a lot of dynamic formed environment variables supported. * FLAM4_CONFIG_FILE - the configuration filename (default is '$HOME/.flam4.config' on UNIX/WIN or '&SYSUID..FLAM4.CONFIG' on mainframes) * FLAM4_DEFAULT_OWNER_ID - the default owner ID (default is 'limes') * owner_FLAM4_command_PROPERTY_FILENAME - To override default property file names * path_argument - to override the hard coded default property value On platforms (mainly mainframe systems) where system symbols are available, some of the environment variables can be pre-defined over corresponding system variables. See install.txt or use built-in function <<CLEP.BUILTIN.HLPENV,HLPENV>> (in round brackets the corresponding system symbols are listed). Trailing whitespace is removed from variable values before being used. A system symbol must start with `&` or an alphabetic character followed by alphanumeric characters. The environment variable LANG is also used on EBCDIC systems to interpret several syntax characters correctly, which depend on the codepage. See chapter <<CLEP.MAIN.EBCDIC,special EBCDIC code page support>> for how the CCSID can be defined. It is important to set this variable to the correct value on EBCDIC systems. If this environment variable is not set, files and literals are interpreted in IBM-1047 on z/OS and USS. If you use another CCSID for entry, you must define the environment variable LANG to enable correct parsing for strings that contain special characters like `~`. We recommend to define the corresponding system variables (&FLANGLC, &FLANGCC and &FLANGCS) via `SYS1.PARMLIB(IEASYMxx)` on z/OS (see also install.txt). These three system symbols are used to build the environment variable LANG based on the string below: For example with the definitions below the environment variable below is defined. The language code (de) is important for correctly selecting the default CCSID if an ASCII code page was detected. The `ENVID` variable is normally one character to separate test and production environments. On z/OS the default is simply the first letter of system symbol `&SYSCLONE` or if not defined (on all platforms) 'T' for test. The variable FLAM4MF and (if needed) FLAM4MF_TRACEFILE should be set in the environment of the Microfocus Enterprise Server instance where the FLAM or FLUC record interfaces are used. To define static and dynamic system variables, the FLAM4MF_STATIC/DYNAMIC_SYSVAR environment variable can be used to read the system variables to the environment. The second file was mainly introduce for the MF-EDZ JCL user exit, which can be used to provide the dynamic symbols like JOBNAME as keyword=value pair as the dynamic file. All the files read to build the environment undergo automatic ASCII and EBCDIC detection. A semicolon can be used to mark the end of a keyword-value pair (an inline FB80 encoding in JCL on EDZ does not contain new line characters). To undefine an environment variable, there must be no characters behind the equal sign. To replace a variable with nothing upon use, the environment variable must be set to one or more whitespace character(s). Trailing whitespace is removed from the value string, so a value which contains only whitespace characters will result in an empty string upon substitution. For Micro Focus EDZ environments, the DD name SYSVAR is supported to define system variables. The function used to read the `keyword=value` pairs automatically detects if EBCDIC is used (character > 0x80) and converts the lines automatically to the local character set. The LE-less part of FLAM can only use system symbols. Below is a list of available variables: *&FLREUCEE - Activate reuse of language environment in FLAM ZEDC support *&FLOGQL1  - First qualifier to specify the FLAM usage log stream name *&FLOGQL2  - Second qualifier to specify the FLAM usage log stream name *&FLOGQL3  - Third qualifier to specify the FLAM usage log stream name See install.txt for z/OS for more information. ",
"",
""
],
[
"flam4_manual-command_line_parser-environment_variable_mapping_0270.html",
"Environment Variable Mapping",
"=== Environment Variable Mapping Each value enclosed with angle brackets (`<>`) are replaced with the corresponding environment variable (`<LANG>`). This feature is available at each starting point of a lexeme and inside of a normal string. If the environment variable not defined the replacements below are still possible: * <SYSUID>   - Current user id in upper case * <USER>     - Current user id (case sensitive) * <CUSER>    - Current user id in upper case == <SYSUID> * <Cuser>    - Current user id in title case * <cuser>    - Current user id in lower case * <HOSTNAME> - The current host name of the system * <ENVID>    - The environment ID (default is T for test) * <HOME>     - Replaces with the users data directory, if this not                available the replacements below are done: ** On UNIX with /home/<USER> ** On USS with /u/<USER> ** On ZOS with <SYSUID> Additional few abbreviation are supported for different kind of strings. * '~' for <HOME> in file strings * '!' for <ENVID> in key labels * '~' for <SYSUID> in key labels * '^' for <OWNERID> in key labels All these abbreviation character have different code points in EBCDIC code pages and can only be used if the CCSID known be CLP, see chapter <<CLEP.MAIN.EBCDIC,special EBCDIC code page support>> how the CCSID can be defined for CLP. ",
"",
""
],
[
"flam4_manual-command_line_parser-filename_mapping_48b6.html",
"Filename Mapping",
"[[clep.main.filemap]] === Filename Mapping All filenames used by CLE/P(R) are additionally mapped based on the rules below: * The tilde character (`~`) is replaced with the string `<HOME>` * DD names on mainframes must be prefixed with 'DD:' * Data set names on mainframes are always fully qualified * Path names on mainframes must contain at least one slash (`/`) * Data set names on USS must start with `//` ** Fully qualified names with HLQ must be enclosed in apostrophes (`//''`) ** If apostrophes are not used the SYSUID is prefixed as HLQ * Normal file names on other platforms could be relative NOTE: If a requested environment variable is not defined, the replacement is done with the empty string. This can result in unexpected behavior. To use a '<' or '~' as a part of a filename the character must be specified twice. Beside this rules the replacement technologies of your shell can be used, but on some platforms $HOME, $USER or something similar might not be available, for such cases the possibilities above are implemented. This file name mapping is provided by the library CLEPUTL and should also be used for file names managed by the commands supported with this program. ",
"",
""
],
[
"flam4_manual-command_line_parser-key_label_mapping_dec8.html",
"Key Label Mapping",
"=== Key Label Mapping The key label name mapping works like the file name mapping, but you can additional use `^` to replace it with the OWNERID (`^=<ONWERID>`), `!` to replace it with the environment identifier (`!=<ENVID>`) and `~` is only replaced with login user id. If the environment ID not defined then `T` for test is used by default. ",
"",
""
],
[
"flam4_manual-command_line_parser-special_ebcdic_codepage_support_bc51.html",
"Special EBCDIC Codepage Support",
"[[CLEP.MAIN.EBCDIC]] === Special EBCDIC Codepage Support To interpret commands correctly the punctuation characters below are on different code points depending on the EBCDIC CCSID used to enter these values. These critical characters are interpreted normally dependent on the environment variable LANG. If the environment variable LANG is not defined then the default CCSID IBM1047 (Open Systems Latin-1) is used. Below is the current list of supported CCSIDs on EBCDIC systems. You can define the code page explicitly (LANG=de_DE.IBM-1141) or only the language code (LANG=de_DE, LANG=C). If only the language code defined then the CCSID is derived from the language code (DE=IBM-1141, US=IBM-1140, C=IBM-1047, ...). If possible, these critical characters are also converted for print outs. At output it is not possible to convert anything correctly, because some strings for print out are coming from other sources (like system messages and others). Only all known literals are converted, for unknown variables such a conversion is not possible and CLE/P(R) expects that such strings are encoded in the correct system code page, but there is no guaranty for this. To be independent of the environment escaping of the CLP strings is possible for the critical punctuation characters on EBCDIC systems. See list below: A escape sequence starts with the ampersand (&) followed be 3 character (not case sensitive) and is terminated with semicolon (;). With an X and 2 hexadecimal digit the definition of a binary byte value are possible. If such a sequence in the string required then the ampersand must be typed twice (&&). To mark a part or the of whole string in a certain CCSID the escape sequence must contain 1 to 6 digits. Few samples can be found below: At the beginning the system code page is active except the environment variable CLP_STRING_CCSID is defined. The defined CCSID is valid till the next CCSID definition. An unsupported CCSID (0) can be used to restore the interpretation to the system code page. NOTE: This is no character set conversion, only the UNICODE code points 0-127 which are on different code points in the different EBCDIC code pages are replaced. All other higher code points (e.g. German Umlauts ('ä','ü','ö')) are not touched. The partial CCSID conversion are mainly useful for application programming interfaces. At compile time the CCSID for literals must be defined. This CCSID could be differ from the system CCSID (local character set) of variable parameter. In such a case a application can mark the literal part in the CCSID used for literals at compile time, and the variable part could be conform to the CCSID defined over the LANG variable. See the C example below: C-Code are normally in 1047 and if no literal conversion defined then the literals also in 1047. The file name is a parameter in local character set. In Cobol the default code page for literals is 1140. To define the CCSID for CLP strings from outside, the environment variable CLP_STRING_CCSID can be defined. This is useful if an application cannot recompile with the correct code page for the literals. On ASCII/UTF-8 platforms a miss-interpretation of punctuation characters smaller than 128 is not possible. On such platforms the LANG variable is not used for command interpretation or printouts. The escape and CCSID sequences are supported but have no effect on these platforms. This helps to develop platform independent code for CLP strings. ",
"",
""
],
[
"flam4_manual-built_in_functions_178f.html",
"Built-in Functions",
"[[CLEP.BUILTIN.FUNCTIONS]] == Built-in Functions Numerous built-in functions are available to obtain extensive help about syntax, errors, commands and functions of a program with help messages, manual pages and documentation. Other built-in functions can be used for owner, property, environment and trace management. All built-in functions have the purpose to simplify handling of powerful and sometimes complex commands. [[CLEP.BUILTIN.SYNTAX]] === SYNTAX indexterm:[Built-in Function, SYNTAX] The syntax function shows how the arguments can be set on the command line. Depending on depth the syntax is printed in one line or in structured form. A structured print out means that you have a question or exclamation mark before the argument. * question mark    - optional parameter * exclamation mark - required parameter The *path* is a dotted keyword list in accordance with the syntax of the corresponding command. * DEPTH1 / DEPTH2 / ... / DEPTH9 ** Specifies the depth of the output. Default is DEPTH1. If the depth is    greater than 1 the structured print out is used. * ALL ** Shows complete syntax for the specified path, not just DEPTH1.    Structured print out is used. [[CLEP.BUILTIN.HELP]] === HELP indexterm:[Built-in Function, HELP] The help function can provide extensive information about each parameter which is adjustable on the command line. With the help functionality you get a structured list of arguments: * keyword           - the keyword for the argument * (TYPE: ...)       - the type of this argument * help message      - the short help text * (PROPERTY: [...]) - the current hard coded property value (optional) The keyword can be abbreviated, but it must be unique for this list. The required letters are upper case if case sensitive mode is used. With the case sensitive mode an additional line is required to mark the appropriate letter. The *path* is a dotted keyword list in accordance with the syntax of the corresponding command. Help can also be used to show the corresponding detailed description of the manual pages with keyword *MAN*. * DEPTH1 / DEPTH2 / ... / DEPTH9 ** Specifies the depth of the output. Default is DEPTH1. * ALL ** Shows complete help below specified path, not just DEPTH1 and includes    all aliases defined for a certain argument. * MAN ** Shows additionally the detailed description for this program, command    or parameter and the next level of arguments including the aliases. [[CLEP.BUILTIN.MANPAGE]] === MANPAGE indexterm:[Built-in Function, MANPAGE] Shows the manpages of the program, all commands and built-in functions and if available for each argument up to selections/constant definitions. This function prints the corresponding section from the user manual on the screen (doctype: *book*). If a filename is given then the doctype *manpage* of ASCIIDOC is written to the file. Do not use space characters between the key, assignment character (=) and filename. The files in ASCIIDOC format can be used to generate manpages with the tool http://www.methods.co.nz/asciidoc/[ASCIIDOC]. [[CLEP.BUILTIN.GENDOCU]] === GENDOCU indexterm:[Built-in Function, GENDOCU] The complete user manual is generated when only the filename is given. If a command, or command path, is specified the corresponding section of the user manual is written to a file. The generated files are in ASCIIDOC format, to be readable as normal text document on all platforms and easily convertible into HTML, PDF or other formats with http://www.methods.co.nz/asciidoc/[ASCIIDOC]. The example below generates the complete manual and convert it in a second step to a HTML5 document. The numbering will vary in places where the complete manual uses a bullet list for arguments and constants, when no detailed description is available and some of these arguments are required for the path. The numbering can be disabled by setting the optional keyword NONBR. This is useful if numbering is generated by a post processing utility (for example 'pdflatex'). To create a short manual without the CLP parameter description the optional keyword SHORT can be used. This is useful for example, if you deliver a text file and no dictionary can be used. In opposite to the built-in function <<CLEP.BUILTIN.HTMLDOC,HTMLDOC>> at text file generation the corresponding path string is written to the synopsis but index chapter and index terms are not generated anymore. Do not use space characters between the key, assignment character (=) and filename. [[CLEP.BUILTIN.HTMLDOC]] === HTMLDOC indexterm:[Built-in Function, HTMLDOC] This built-in function generates the complete user manual in HTML format into a folder. The folder can be defined as optional parameter. If no path given, then the current directory is used as default. With the optional keyword `NUMBERS` the numbering of headlines can be activated. The keyword `TYPE` add the type information to each generated headline. The keyword `SHORT` will result in a short version of the document, not containing the parameter of the commands and other CLP strings. In opposite to the built-in function <<CLEP.BUILTIN.GENDOCU,GENDOCU>> at HTML generation no path is written to the synopsis but index terms are generated by default. The built-in function can only be used if a call back function for HTML documentation provided. If not a error will be issued if HTMLDOC is executed. The callback function is called for each prepared page and the unique pointer to the original manual string can be used to determine if this page already created and if so then only a link to this existing page is required. This interface allows to generated more flexible (with dictionary, index, search) and redundancy free HTML documentation. To understand the service provider interface (open, close and callback function) for HTML generation see the DOXYGEN documentation of FLAMCLE/CLP.h [[CLEP.BUILTIN.GENPROP]] === GENPROP indexterm:[Built-in Function, GENPROP] A property file is generated for all commands if only a filename is provided. If a command is specified, a property file for this specific command is created. Property files can be used to define default settings for commands. For each parameter, a property entry is written to a text file. The text file contains comments to help in editing the properties. A property file can be activated with the built-in function SETPROP. Property files will be activated by their owner. A property file overrides hard coded properties and properties defined over environment variables. A specific property file overrides the general property file. At time of generation all current default settings are written to the property file. We recommend to work only with command specific property files, because the built-in function CHGPROP can be used to generate, update and  activate a property file for a certain command. Do not use space characters between the key, assignment character (=) and filename. To optimize the program performance, one can remove all unnecessary properties. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. [[CLEP.BUILTIN.SETPROP]] === SETPROP indexterm:[Built-in Function, SETPROP] The filename is set as current global property file when no command is specified. The file name is set as current local property file when a command is given. The property file can be generated with GENPROP and will be activated for the current owner. After generation you can activate the property file, but there will be no effect until you change the settings inside the property file, because the current default settings are written. The filename can contain replacement/mapping rules (<HOME>/<USER>). Do not use space characters between the key, assignment character (=) and filename. We recommend to work only with command specific property files, because the built-in function CHGPROP can be used to generate, update and  activate a property file for a certain command. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. [[CLEP.BUILTIN.CHGPROP]] === CHGPROP indexterm:[Built-in Function, CHGPROP] The built-in function updates property values in the currently active (see <<CLEP.BUILTIN.SETPROP,SETPROP>>) property file for a dedicated command. If no property file is activated, a property file is generated (see <<CLEP.BUILTIN.GENPROP,GENPROP>>), updated with the provided property list and activated (see <<CLEP.BUILTIN.SETPROP,SETPROP>>). The first argument of CHGPROP is the command name. All other arguments are key-value pairs of properties that should be updated. The key is internally prefixed with the root (owner.program.command.). The values are enclosed in double quotation marks. Multiple properties of a command can be updated at once by separating them with a space character (please do not use spaces between key, assignment character (=) and the value). This set of properties is parsed by the CLP. If no property is provided, the property file for the command is either parsed or generated (if it does not exist) and then activated without updating properties. This behavior can be used to generate and activate command specific property files for the different commands. The built-in function reads and parses the currently active property file. Then it parses the provided property list and writes the updated property file back to disk. The currently active property file could be a global, not command specific property file. In such a case, a new command specific property file is generated and activated. Properties from the global property file are copied into the newly generated one. If no property file is defined (see <<CLEP.BUILTIN.SETPROP,SETPROP>>) that corresponds to the owner, program and command, a property file is generated. The filename formats below are used to read or write property files from/to the home directory: On non-mainframe systems (WINDOWS, UNIX, MAC): On mainframe systems (ZOS, VSE, BS200, ...): If the default filenames and/or path are not sufficient, you can change the filename of each property file by setting environment variables using the following naming convention: If no home directory is defined, then the current working directory is used as default directory to save the property files. On mainframes SYSUID is used for the first level qualifier, to represent the 'home directory'. Property files are managed per owner: This means that updates are only done for the current owner. To delete a property you can simply specify the path without the root and with out a sign. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. [[CLEP.BUILTIN.DELPROP]] === DELPROP indexterm:[Built-in Function, DELPROP] Without a command the current global property file is deleted from the configuration data. A command specific property file can be deleted from the configuration data when the command name is given. Property files are managed per owner, this means that delete is only done for the current owner. We recommend to work only with command specific property files. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. [[CLEP.BUILTIN.GETPROP]] === GETPROP indexterm:[Built-in Function, GETPROP] All or certain properties can be shown for a dedicated path. The *path* is a dotted keyword list according to the syntax of the corresponding command. A help message for a certain parameter will also show the assigned property value. See <<CLEP.APPENDIX.PROPERTIES,Appendix Properties>> for the current property file content. * `DEPTH1 / DEPTH2 / ... / DEPTH9` ** Specifies the depth of the output. Default is DEPTH1. * `DEPALL` ** Shows all properties to the specified path, not just DEPTH1. * `DEFALL` ** Shows all defined properties to the specified path. [[CLEP.BUILTIN.SETOWNER]] === SETOWNER indexterm:[Built-in Function, SETOWNER] The current owner id (prefix or separation) can be changed. The owner concept is very powerful to separate different property settings. You can run the same command with different properties simply by switching the owner. The owner is a general solution to separate all settings and can be used for environment, client and other purposes. If not already defined, the owner is written to the environment table under the key word OWNERID. This environment variable can for example used as replacement in file names (~/<OWNERID>.dat) or to refer a  signature key. [[CLEP.BUILTIN.GETOWNER]] === GETOWNER indexterm:[Built-in Function, GETOWNER] The current owner id (prefix for separation) will be shown. The owner concept allows to manage different configurations as a logical separation of what is done with this id. [[CLEP.BUILTIN.SETENV]] === SETENV indexterm:[Built-in Function, SETENV] This function allows to set environment variables within the  configuration file for a certain owner. All defined environment variables are placed in the current environment table of the process before a command is executed. Do not use space characters between the key, assignment character (=) and value. *Attention:* The environment variables will be temporary overwritten [[CLEP.BUILTIN.GETENV]] === GETENV indexterm:[Built-in Function, GETENV] This function lists all environment variables which are set within the configuration file for a certain owner. All shown environment variables are placed in the environment table of the process. *Attention:* The environment variables will be temporary overwritten [[CLEP.BUILTIN.DELENV]] === DELENV indexterm:[Built-in Function, DELENV] This function will delete environment variables from the configuration file for a certain owner. [[CLEP.BUILTIN.LSTENV]] === LSTENV indexterm:[Built-in Function, LSTENV] This function will list the status of all possible useable environment variables. [[CLEP.BUILTIN.HLPENV]] === HLPENV indexterm:[Built-in Function, HLPENV] This function will print the help message for all possible usable environment variables. [[CLEP.BUILTIN.TRACE]] === TRACE indexterm:[Built-in Function, TRACE] Tracing for command line parser and commands can be enabled or disabled. A trace is only required to diagnose errors. In such a case a trace file must be defined first, then the trace can be activated, the erroneous command executed and the trace file sent to the support team. If no trace file is defined, stdout/stderr is used as default. To prevent tracing on the screen, please define a trace file first before tracing is switched on. Do not use space characters between the key, assignment character (=) and filename. [[CLEP.BUILTIN.CONFIG]] === CONFIG indexterm:[Built-in Function, CONFIG] The actual configuration list with owner id, property file names trace setting, environment variables and more is shown. With the option CLEAR the configuration data including the corresponding file will be deleted. The configuration file name can be defined by the environment variable: This can be used to work with a global configuration file. If this location is not defined, the configuration file is stored in the home directory with the name: If no home directory is defined for the current user (this case is very improbable), the working directory is used. To read the configuration file when the environment variable above is not defined, CLE first looks in the working and then in the home directory. This makes it possible to prefer a property file, by copying it to the current working directory. On mainframes the data set name 'SYSUID.FLAM4.CONFIG' is used as default. SYSUID as high level qualifier is a kind of replacement for the current home directory in other operating systems in this way. [[CLEP.BUILTIN.GRAMMAR]] === GRAMMAR indexterm:[Built-in Function, GRAMMAR] The grammar used for interpreting the command line and property files is shown. This is helpful for understanding how the commands and property files are interpreted by the command line processor. See <<CLEP.APPENDIX.GRAMMAR,Appendix Grammar>> for an explanation and the output of this command. [[CLEP.BUILTIN.LEXEMES]] === LEXEMES indexterm:[Built-in Function, LEXEMES] The regular expression used for the tokens of the command syntax will be shown. This could be helpful in understanding how the commands and property files are interpreted by the command line processor. Moreover it will be shown how to define a number, a string, a keyword and other values inside a command. See <<CLEP.APPENDIX.LEXEMES,Appendix Lexemes>> for an explanation and the output of this command. [[CLEP.BUILTIN.LICENSE]] === LICENSE indexterm:[Built-in Function, LICENSE] The license string of the software product is shown. This string is provided to the command line executer (CLE) by the calling program and should reflect the current license text for this program. [[CLEP.BUILTIN.VERSION]] === VERSION indexterm:[Built-in Function, VERSION] The version of the software product is shown. This string is provided to the command line executer (CLE) by the calling program and should reflect the current version information for this program. See <<CLEP.APPENDIX.VERSION,Appendix Version>> for the output of this command. [[CLEP.BUILTIN.ABOUT]] === ABOUT indexterm:[Built-in Function, ABOUT] Shows information about the software product like version, copyright, external libraries, license and other attributes. This string is provided to the command line executer (CLE) by the calling program and should reflect the current about information for this program (flam4). See <<CLEP.APPENDIX.ABOUT,Appendix About>> for the output of this command. [[CLEP.BUILTIN.ERRORS]] === ERRORS indexterm:[Built-in Function, ERRORS] This built-in function prints explanations for the return/condition/exit codes of the executable and, if available, the reason codes of executed commands. The command line executer (CLE) initialized the CLP structure. Calls the command line processor (CLP). Calls the mapping function, which converts the CLP structure in a corresponding command structure. Then it runs the command and as last step it calls the finish function with the command structure, to close all files and free all the allocated memory. If one of these steps fails, then a corresponding return (condition/exit) code is given back from the executable. Only the command execution can result in a error (return code 8) or in a warning (return code 4). The command it self must return a reason code for such a warning or error. This means that the return (condition/exit) code can be used to control the batch processing. The reason code gives more information about the error or warning. See sections <<CLEP.APPENDIX.RETURNCODES,return codes>> and <<CLEP.APPENDIX.REASONCODES,reason codes>> for an explanation and the output of this command. ",
"",
""
],
[
"flam4_manual-flam4_utility_af72.html",
"FLAM4 Utility",
"== FLAM4 Utility Frankenstein Limes Access Method (FLAM) 4 is a batch utility based on the Frankenstein Limes Universal Converter (FLUC(R), a FL5 component) to provide the old famous command line interface which was used up to FLAM version 4. It replaces the original FLAM4 utility. The new FLAM4 utility can be used like the old one on UNIX and Windows. On z/OS, the old FLAM utility is still supported and the new FLAM4 utility can be used if one of the new features is needed. The FLAM4 utility behaves like the FLAM command of the FLCL and can be used synonymously. This batch utility supports the following commands: * FLAM - default command for FLAM4 command line if no command specified * INFO - to determine several information The FLAM4 utility can be used in scripts to automate batch processing. The command interpretation is platform independent and optimized for different shells like WINDOWS(R) command prompt, UNIX bash or z/OS JCL. FLAM as a utility can be started on job control level via a job control command. Parameters define the mode of operation. Depending on the operating system, parameters may be supplied as a part of the command or may be entered via screen. Parameters can also be read from a parameter file. This file can be assigned to the process using job control commands or command parameters. === Compatibility with Version 4.3 To be compatible with the older flam4 utility on Windows and Unix the default record format can be adjusted by setting the properties. ",
"",
""
],
[
"flam4_manual-flam4_utility-overview_c326.html",
"Overview",
"[[flam4.main.overview]] === Overview This command line interface is an implementation of the FLAM algorithms and access method up to version 4. Its purpose is to compress and decompress files in a format that allows easy exchange of data with numerous computer types from a wide range of manufacturers. Moreover, it offers character conversion and the option of encrypting compressed or uncompressed data. Its heterogeneous compatibility also renders FLAM particularly suitable for long-term archiving of data, since the reproducibility of this data is no longer tied to the life cycle of a specific system. In addition, FLAM enables files to be converted in almost any way, i.e. to files with a different organization, a different record format or a different character set. The architecture of the software is layer-oriented, i.e. it is made up of a series of hierarchically arranged functional groups which are completely distinct from one another and which communicate via defined interfaces. Since these interfaces are open, it is up to the user to choose the extent to which he wishes FLAM to be integrated in his applications. FLAM can be invoked either by means of a command or by an application program via the corresponding interface. Although FLAM is capable of compressing any type of file, it was originally designed for files with a largely standardized record structure and character-coded data. It is most efficient at compressing such files. The above requirements are normally satisfied if the processing application programs are written in a high-level programming language. This chapter attempts to assist the user in deciding when, and if so how, FLAM can be used effectively and with the optimum benefit. The flam command may contain the necessary information either in the form of parameters in the command line itself or as FLAM parameters in a parameter file, which is referred to by the parameter parfile=parameter file. The FLAM command is described in a own chapter below and discusses these parameters in greater detail. Unless otherwise explicitly mentioned, all the information in this chapter relating to the use of parameters in the command line applies equally to the parameters in the parameter file. ",
"",
""
],
[
"flam4_manual-flam4_utility-mode_of_operation_4192.html",
"Mode of Operation",
"[[flam4.main.mode.of.operation]] === Mode of Operation When a file is being compressed with FLAM, one or more original files are read record by record, and a compressed file (optionally encrypted), called FLAMFILE, is created. When a file is decompressed using FLAM, the compressed file is read sequentially and one or more decompressed files are created. The compression process consists of a series of recurring cycles. Each cycle generally entails reading a fixed number of records in the original file; these records are then buffered in the matrix buffer, compressed and output in the form of a compressed block. The number of records is between 1 and 255 or 4095, depending on the compression mode used, and is specified when the compression procedure is invoked. A compressed block containing correspondingly fewer records is generated when the end of the file is reached or if the matrix buffer overflows. The compressed blocks created by FLAM are written into a sequential FLAMFILE. By the record-oriented reading, the file's structural information is preserved, which is of great importance for reproducing the original file in computing environments with data management systems. Depending on the compression mode, each record in the FLAMFILE is given either a binary checksum or a check character, which is used to verify the integrity of the data when the file is decompressed. The FLAMFILE can be saved or exchanged with another computer. When the file is decompressed, it may have a different organization, a different record format or a different record size from the original file, depending on the settings entered by the user or on the default settings. Independently from the Frankenstein-Limes compression method FLAM establishes a concept for file conversion that satisfies compatibility requirements as much as possible. The compressed file created by FLAM is a logical image of the records of the original file. This is the basis for any conversion with FLAM. The compressed file, the FLAMFILE, is stored by default as a sequential file in accordance with the above-mentioned principle (for random access, index sequential storage is also possible). The problems which occur with uncompressed files when the requirements are comparable must therefore not be simply ignored due to the fact that FLAM is being used. Some of these problems are made easier to solve by the FLAM concept. Others remain despite FLAM and must therefore be solved along application-specific or organizational lines as before, the only difference being that the original file can be substituted by a FLAMFILE. FLAM does not solve the problem of incompatible record and field structures in heterogeneous environments. Sometimes users are totally unaware about these problems. FLAM offers user exits that allow to embed special conversion routines. As FLAM is designed as an open system, it will be possible to offer standard solutions for special problem areas in the future. FLAM requires, that the original records are passed to FLAM record by record. The chosen compression method implies that FLAM works asynchronously. N original records may result in k compressed records where n is unequal k. This can be a problem in special cases. The FLAMFILE is always created with a fixed record length that may be specified by the user. This results usually in compressed records of equal length. This is necessary because some DP systems only support files with equal record length. This is also true for some data transmission products. The smallest record length is 80 byte. This allows to process the FLAMFILE in the punched card format (RJE file transfer!). The upper limits are defined by the environment: where the file is stored and which products are used to transfer the file. The upper limit defined by FLAM is 32764 byte. However, the user may define the format of the record as 'variable length' or 'fixed length'. For a fixed-length record that is not filled up, padding is applied. It is also possible to define different block sizes to optimize the I/O operations, file transfer and storage requirements. This flexibility makes it mostly possible to find a suitable solution for all participating software and hardware environments as well as for special applications. The FLAMFILE is principally a binary file where all 256 bit combinations are allowed. With this code the FLAMFILE can only be transmitted in transparent mode (MODE=CX8 and VR8). If transmission on a 7-bit line is performed, file transfer products expand such binary files in a way that ASCII compatibility is guaranteed. Some products convert each half byte into one byte, other products expand 3 bytes into 4 bytes. If the original file contains only printable characters, FLAM can provide a different code format of the compressed file (MODE=CX7). In this case characters from the original file are not combined with FLAM descriptors but simply copied into the compressed file. This mode is mostly more efficient than MODE=CX8 with following expansion 3 to 4. The FLAM descriptors itself under MODE=CX7 consist only of printable characters that are unambiguous in the international code systems ASCII and EBCDIC. These are all small and big Latin letters, the ten digits and the blank. Any kind of control character, special characters, umlauts are excluded. The advantage of this method is that the resulting FLAMFILE can be converted freely between ASCII and EBCDIC and vice versa at any time between compression and decompression. If the conversion is not handled by the data transmission system or on the data transmission path, the user may use the FLAM user exits and can apply the appropriate code conversions as part of the compression/decompression process. FLAM always works in MODE=CX7 in respect to the code system of its host. If source and target are of the same code system (ASCII or EBCDIC) no conversion is necessary. If source and target are of different code systems, FLAM requires that the FLAMFILE is converted to the code system of the target host system first to decompression. If the FLAMFILE in MODE=CX7 shall be transmitted via a 7-bit line as well as via an 8-bit line, it will be necessary to analyse the actual situation to maintain ull compatibility. It must be considered, that FLAM offers integrated code conversion functions not on all platforms. However, this problem can be solved with MODE=CX7. Because the FLAMFILE has records of equal length, the last record is filled with a padding character if fixed record format is used. In MODE=CX7 this padding character is blank, otherwise binary zero. If a variable record format is used, no padding is done for the last record - the last record is shortened instead. Each record in the FLAMFILE has (internal) overhead: the FLAM syntax, which organizes a frame for the compressed data to fulfil the different requirements. The overhead is the same for each record: 4 byte in 7-bit format and 6 byte in 8-bit format. The user should consider this when defining the record length for the FLAMFILE. The shorter the record length, the bigger the overhead. In addition, the FLAMFILE contains the following syntactical elements: an optional file header for each original file, a compulsory block header for each matrix, etc. Usually the FLAMFILE starts with a file header. This file header consists of a system independent on a system dependent part. The file header contains various information about the original file. During decompression FLAM will use this information - if not provided otherwise - to create the decompressed target file. It is possible to concatenate multiple compressed files. In this case the FLAMFILE contains multiple file header. The FLAM utility ignores these file headers during decompres-sion, and will use only the first one. However, the others appear in the protocol. With this feature FLAM is prepared for the insertion of identical file headers into archive files, a feature that may help to identify a file even in the case of hardware faults. If the FLAM record level interface is used, the different files can be separated during decompression. An empty file is converted into a FLAMFILE that consists only out of a file header. This implies that an empty file no longer must be treated as a special case. The usual problems with empty files in the job command language and during file transfer belong to the past. With a parameter it can be specified if and which file header shall be created during compression. The decompression function can be used to only print out the file header without doing the actual decompression. This allows a quick information about the origin of the compressed file. One block header is created per matrix. This block header contains all the necessary information for proper decompression even without a file header. However, in this case the user has to specify the target format via parameter, JCL or catalogue entry if another format than sequential and variable record length shall be created. The block header contains also all information that is needed by the FLAM nucleus for decompression, e.g. MODE, version, matrix size, etc. This information guarantees the upward compatibility of FLAM. The individual records of the FLAMFILE contain their length redundantly. If the FLAMFILE has variable record length an additional length field of 2- or 4-bytes length is part of each record. In MODE=CX7 on PC standard record separator characters of length 1 or 2 are used. Therefore the record length is not a physically unique size within a heterogeneous environment. Each FLAMFILE record created in 8-bit code is protected against manipulations via a 16-bit checksum. In addition, so called block pointers allow synchronisation (and restart on block level), if data cannot be decompressed properly because of manipulation or hardware faults. A FLAMFILE created in 7-bit code does not contain checksums, because this would inhibit code conversion from ASCII to EBCDIC and vice versa. Instead the number of bytes per record is checked. This function detects for example if a non 1:1 code conversion was applied. This may happen if printer control characters or tabulator characters are not converted 1:1. However, this does not comply with the preposition that the file must only contain printable characters. It has a clear advantage to use the 8-bit format if it is not really necessary to work in 7-bit format. Compression is faster, the compression ratio is better, the compressed file is better protected in respect to data security and data integrity and transmission of these files is faster in transparent mode. Also more possibilities for data encryption exist. The reason is, that a 7-bit FLAMFILE can only be encrypted by randomising the character string. Other encryptions do not comply with the purpose for which these files were created (see above). A FLAMFILE in 8-bit format, however, can be encrypted with all kinds of additional encryption methods to create a FLAMFILE not compatible with the market version. For such conversions, the original state of the FLAMFILE as created by FLAM must be restored before the FLAMFILE is decompressed. In MODE=CX7 the FLAMFILE in addition must be converted into the code system of the host where the decompression is performed. In the case that 1:1 code conversions shall be performed before compression or after decompression, FLAM offers the possibility to convert from EBCDIC to ASCII and vice versa as well from one EBCDIC dialect to another EBCDIC dialect. These conversions are implemented via code tables that can be replaced by the user. It is possible to use user defined code tables as well for encryption purposes. For all conversion problems not mentioned so far the user has the possibility to use the user exits for manipulation of uncompressed data. This is independent from the MODE parameter. The required conversions can be performed in connection with record processing. Independently from the user exits, the record level interface provides access on record level before compression and after decompression. Using this possibility the user may process original data that otherwise could not be handled by FLAM. This interface also allows the integration of FLAM with user applications and software packages. Also in the case when a FLAMFILE was created without a file header (HEADER=NO) FLAM can decompress this FLAMFILE. Principally a restoration of a damaged FLAMFILE is possible but requires the consultation of an expert from the manufacturer. Such damages are caused exclusively by hardware or material faults or by unauthorised manipulation. The ability to store several compressed files in one FLAMFILE has been realized in the form of the group file. If several files are read during compression, FLAM generates for each input file a file header (parameter HEADER=YES,default) in the FLAMFILE. A number of FLAMFILEs are written physically, in sequential order one after the other. (If the parameter HEADER=NO is set, no details about the respective file are stored in the group file. When decompressed, this file is then no longer recognized as a FLAMFILE containing a number of compressed files and it can only be decompressed altogether.) The file type and format of a group file can be adapted to suit any requirements, exactly as in FLAMFILEs. The parameter SHOW=DIR can be used to display the details of all of the compressed files in this group file, without the group file being decompressed. FLAM is able to decompress each individual file of this group file by specifying a selection rule (see chapter 3.1.4.3). The decompressed file can be specified by means of a command or FLAM creates the file dynamically and catalogues it. Libraries are compressed into a group file by FLAM on a member-by-member basis, i.e. it would be possible to decompress each member into a separate file using an appropriate conversion rule. Accordingly, a number of individual files can be used to generate library members. This group file allows libraries that have been generated under a range of different operating systems to be exchanged between heterogeneous operating systems in a compatible way. If neither a selection rule nor a conversion rule is specified, the compressed files are decompressed into a specified file as in earlier FLAM versions; i.e. all of the originally different files are now positioned one after the other, decompressed. Conversion is executed in accordance with the file attributes of the output. NOTE: If `FILEINFO=NO` was set when the group file was being created, no file name was stored for the compressed data in question. This also means that there would be no file name available for creating the files. Despite this, the compressed data can still be accessed and appropriate conversion rules compiled by means of the internal file names FILE0001 (for the 1st file) through FILE9999 (for the 9999th file). Compressed files may be ported to a target system via file transfer or via tapes, cartridges, etc. It is not necessary that source system and target system are of the same type. However, necessary requirement is, that a file transfer feature exists or that a compatible tape or cartridge format exists. If these requirements are fulfilled, data exchange is possible on both systems if FLAM exists and is installed. All FLAM versions are upward compatible. That means, that systems with both FLAM older and newer version can compress/decompress in the old manner. Since version 2.x the different formats of the compressed data are compatible on all systems where FLAM exists. For data exchange between heterogeneous and homogeneous systems only logical data formats should be compressed with FLAM. Physical data formats cannot be reproduced identically on a physically different system. Different methods for compression exist. With ADC, VR8 and CX8 data is compressed in 8-bit mode, with CX7 in 7-bit mode. For data exchange between mainframes any mode can be used therefore. It is also necessary to check if the file transfer works transparently for 8-bit binary data. If yes, an 8-bit method (which can be decompressed on the target system) should be chosen for compression. If file transfer is not transparent the CX7 mode must be selected. The file is only allowed to contain printable characters that can be converted 1:1 during the file transfer. Also in this case it should be checked if the selected compression mode is available on the target system. For file transfer also transfer mode, record length and record format (variable or fixed) must be considered. It is possible that on the target system it is necessary to insert or delete length fields before decompression. Some file transfer products allow only certain record length and certain record formats. One parameter that must be provided with the same value on both systems is the buffer size (MAXBUFFER) for the compression of one data block. This parameter has on mainframes the maximum value of 2.5 MB. FLAM uses on mainframes two alternating buffers, so double the memory is needed. File attributes of the original file are meaningless for data exchange. The reason is that the file transmitted in sequential form is the FLAMFILE. Within the target system the decompressed data can be stored in a file with any valid file organization. This may be an organization that allows for sequential, index sequential or random access. Important is, that the data must comply to this organization (e.g., a record key must be sorted in ascending order for index sequential organization). Files can be compressed immediately during or after processing and can remain stored in compressed form until they are transmitted. Or they can be stored in uncompressed form and are compressed directly before transmission. During compression and decompression any 1:1 code conversions can be applied to the original data. For the conversion from EBCDIC to ASCII a standard table is provided. It is also possible to load a user defined table by specifying its name (TRANSLATE). Generally spoken it is better to apply code conversion during decompression because the compression algorithm treats some frequent characters (like zero or blank) in a special way. Code conversion could reduce the compression effect. Also, because of the smaller character set of the ASCII code, it may happen that characters not contained in the ASCII code set are lost during code conversion, which cannot be reconstructed for decompression. A delicate problem during the exchange of compressed data are index sequential files. Caused by the conversion the binary or alphanumeric keys may be out of order because of different collating sequences in the code systems. No problem, however, exists for keys that consist out of printable letters or for printable numeric keys. A special conversion before or after processing with FLAM is necessary for index sequential files that contain binary and alphanumeric keys. Target files may be created during decompression with a file organization and record format differing from the original file. This is especially true for compressed files received from another operating system. If no other specifications are made by the user, all files that were compressed under the same operating system are reconstructed using the information in the file header. In addition it is possible to convert the compressed file into any file format supported by FLAM on the target system. However, dependencies between file organization and record format may exist: If the file is transformed to fixed record length, the original records can be longer or shorter than the new record length. Longer original records are truncated if parameter TRUNCATE=YES is specified. Shorter original records are padded up to the new fixed record length with blanks (PADCHAR). If an index sequential file is transformed into a sequential file, the keys are removed if parameter KEYDISP=DEL is specified. If a sequential file is transformed into an index sequential file, the original records must contain a field with key properties (unique and sorted in ascending order). Otherwise a printable key or arbitrary length can be inserted at the key position (KEYDISP=NEW). Records of length 0 or gaps within relative files are removed if the file is converted into index sequential format. If relative files are converted into sequential files, gaps are converted into records with length 0. For a conversion into fixed format gaps are removed. If files are converted into relative format, records of length 0 are represented as gaps, except if records of length 0 can be represented in the relative file format. LDS files are managed on the disk by VSAM in units of 4096 bytes. If there is an 'internal' format it is known only to the user and it is not used by VSAM. In this regard, FLAM offers support not only for compression, but also for decompression. Through the use of the parameters IRECSIZE, IBLKSIZE, and IDSORG=LDS for input and ORECSIZE, OBLKSIZE and ODSORG=LDS for output, it is possible to specify 'internal' fixed record lengths with appropriate blocking. There is no requirement for the block size to be an exact multiple of the record length, any remainder will be ignored. These specifications enable every file to be converted into an LDS format; that is, a considerably greater degree of efficiency can be achieved during compression. ",
"",
""
],
[
"flam4_manual-flam4_utility-compression_mode_b48c.html",
"Compression Mode",
"=== Compression Mode FLAM supports four compression modes: adc, cx7, cx8, and vr8. In the adc, cx8, and vr8 modes, it creates the FLAMFILE as a binary file. Mode adc is the most efficient one. It compresses the datastream by removing the redundancy of repetitive sequences and can be used universally. The other modes mainly eliminate 'vertical redundancy', i.e. their efficiency relies on the recognition of re-occurring column contents in table-structured data. Compression mode adc can be combined with one of two encryption methods supported by FLAM. The first is AES, that has been declared standard for US government agencies by NIST (National Institute of Standards and Technology), the second - flamenc - is a proprietary algorithms of limes datentechnik gmbh. None of the other compression methods allows encryption. In all binary modes the compressed information is largely independent of the characteristics of the system on which the compression took place, i.e. the FLAMFILEs must not be modified, for example, if they are transmitted on a line which translates codes automatically. FLAMFILEs which are compressed in the cx7 mode, on the other hand, are insensitive to code translations, since they represent all control information by means of alphanumeric characters, the codes for which are standardized internationally in the ASCII and EBCDIC systems. Providing the original data is character-coded and suitable for exchange between systems with different character sets, the information content of the FLAMFILE remains fully intact after it has been converted to the character set of the destination system, despite the altered binary contents, thanks to the character-oriented interpretation. The compression mode is identified automatically when the file is decompressed. The user thus does not need to know the compression mode in order to decompress a file. ",
"",
""
],
[
"flam4_manual-flam4_utility-flam_and_aes_ca37.html",
"FLAM and AES",
"=== FLAM and AES Below you can fined some remarks for the use of AEs within the different compression modes of FLAM4. FLAM uses this algorithm for encrypting compressed data. Keys of up to 64 characters can be specified (see also the description of the PASSWORD parameter in version 3). Internally, a key of 128 bits is derived (AES- 128) and data security is enhanced by the insertion of verification fields created also with AES (hash-MACs). This encryption method is activated by setting the parameters CRYPTOMODE=AES and CRYPTOKEY=key and is available with compression modes ADC and NDC (MODE=ADC or MODE=NDC). With CRYPTO-MODE=AES the compression mode defaults to ADC when no MODE-parameter is set. This fast algorithm, combined with the ADC compression, enables the user to encrypt large amounts of data with a worldwide accepted algorithm. Using CRYPTOMODE=AES and MODE=ADC/NDC the full FLAMFILE is secured. Any manipulationes will be detected. Therfore a VSAM-KSDS-FLAMFILE cannot be used with this feature. It is created to insert, update, delete any records in the file. This is not allowed. In some cases it is not necessary to guarantee the completeness of the whole file (file transfer!) but the records must be encrypted. The file itself is not moved. Using CRYPTOMODE=AES and MODE=CX8/VR8 the full functionality as without encryption is possible for a VSAM-KSDS-FLAMFILE. You can update, delete, insert any original record as before. All records are com-pressed in CX8/VR8 mode, encrypted with an AES-256 algorithm. It is still a FLAMFILE, but all segments are secured independent from each other and not all together. At least FLAM (MVS) V4.7 is required for decryption. ",
"",
""
],
[
"flam4_manual-flam4_utility-components_and_details_1526.html",
"Components and Details",
"=== Components and Details The following sections describe several components of FLAM4. ==== FLAM Utility FLAM is a utility that is able to compress and encrypt whole files or to expand compressed and to decrypt files. By using the parameters COMPRESS or UNCOMPRESS/DECOMPRESS, you select the operation mode: Compression of an uncompressed file or expansion of a compressed file. As FLAM compresses a file it will write the result into a sequential or index sequential file, the FLAMFILE. This file may have a header that will store information about the original file. FLAM is able to process all PS, PO and VSAM files. To adapt the compression process to the requirements of the user, it is possible to specify parameters during the program call interactively. It is also possible to define the parameters using a parameter file or while generating the system. FLAM creates a job protocol for each execution (on screen or into a log file). During compression FLAM processes a set of 1-4095 (logical) records within one block (Matrix). FLAM can process input and output from both disc and magnetic tape or cartridge. This is also true for the compressed file, the FLAMFILE. FLAM always compresses a set of records in one step. The size of the intermediate buffer can be specified via the parameter `MAXBUFFER`. FLAM will read only as many input records in one step as can be stored within the intermediate buffer. For compatibility reasons to all FLAM versions the size of the intermediate buffer is restricted by 32 kB. However, if the target computer (i.e., the computer on which the compressed file will be decompressed) is known and the FLAM version installed on this computer allows for it, a bigger buffer size for optimal compression can be defined. It is also possible to restrict the number of records within one set using the `MAXRECORDS` parameter. If you define `MAXRECORDS=1`, FLAM will use a serial context free compression method that is only useful with long records. The typical compression ratios are usually achieved with 16-32 records within one set. With a bigger set a slightly better compression ratio can be achieved (which also leads to less CPU utilization!), but the intermediate buffer has to be bigger. The better the compression ratio is, the less CPU time is needed! The compression method is always the same - based on the Frankenstein-Limes-Access-Method. Only the treatment of the matrix columns and the representation of the compressed files differs from case to case. This is controlled with the MODE parameter. With MODE=CX8 FLAM will only compress repeating characters (horizontally and vertically). With MODE=VR8 the remaining data is compressed in addition using the FL-B(4) code. This process first translates the characters into a special 8-bit code and then homogenizes them using specially designed logical operations. The results are bit strings that can be compressed efficiently. One reason for this is that the data resulting from the Frankenstein-Limes-Access-Method can be grouped into partial equalcharacter classes. In both cases, the compressed file, the FLAMFILE, is a sequence of 8-bit combinations that are written into sequential or index sequential files. Record size, record format, block size can be defined by the user. Each record of a file is in addition protected with a checksum. Code conversions within the FLAMFILE are not allowed. During transmission the file has to be treated as a binary file. For files that contain only printable characters and shall be transmitted using a 7-bit-line, FLAM offers MODE=CX7. This mode creates a compressed file which will 'behave' during transmission in the same way as the uncompressed file. FLAM does not check, if the original file is suitable for transmission, but will create a compressed file using a very restricted character set that is neutral to the different code conversion utilities on the marketplace. Using this mode one can create compressed files that can be converted from EBCDIC to ASCII and vice versa (e.g., during a file transfer). However, it is necessary that the code conversion is reversible without any changes. Otherwise FLAM will signal a syntax error in the compressed file due to differences in the byte numbers and will stop decompression. Such cases are possible, if the original file contains printer control characters or tabulator characters, which are not converted 1:1. Apart from this, code conversion can be performed integrated with the compression step. FLAM offers the possibility of code conversion (before compression, or after decompression). Code conversion is controlled via standard code tables or user defined code tables. For special cases where a 1:1 code conversion is not possible for all characters, user exits are provided. FLAM reads a compressed file (FLAMFILE), decompresses the content and writes the result into a target file. FLAM automatically configures itself according to the parameters (e.g., buffer size or record set size) used during compression. The general layout of the compressed file is described in a separate chapter. FLAM version 2.7 can decompress all FLAMFILES created with FLAM V1.0 - 2.6 (upward compatibility). FLAM V2.0/ V2.1 can decompress sequential FLAMFILES created with FLAM V2.5 - V2.7 (downward compatibility). To adapt the decompression process to the requirements of the user, it is possible to specify parameters during the program call interactively. It is also possible to define the parameters using a parameter file or while generating the system. FLAM creates a job protocol for each execution (on screen or into a log file). During decompression the characteristic parameters of the original files are restored depending on the information in the file header. By specifying certain parameters it is possible to generate a target file differing from the original file. All conversions are possible provided that the target system caters for the appropriate access method. That the FLAMFILE eventually was created in a different environment (e.g., different operating system) lacks influence on the operation of FLAM. Data is decompressed into equivalent file formats or in user-defined file formats. By specifying code conversion tables it is possible to change code systems after compression. To be even more flexible, FLAM provides user exits that allow the user to apply user defined post processing. FLAM is able to compress complete files and to reconstruct complete files from compressed data. For original files all file and record formats of type PS, PO or VSAM for disc or tape are supported. The user interface for file IO (`DEVICE=USER`) allows to support additional access methods. The user exits allow to pre- and post process original data as well as compressed data. The user exits are implemented as subprograms that are loaded dynamically during execution time from a module library (STEPLIB). Using predefined or dynamically loaded conversion tables, character conversion can be applied to the original data. It is possible to change file and record formats during decompression. Conversion from variable to fixed format or from sequential to index sequential organization is possible. The compressed data (FLAMFILE) can be stored in sequential or index sequential format in any record or file format. The record and file format of the compressed data is independent from the record and file format of the original data. An index sequential FLAMFILE provides efficient random access to original data by using the record level interface. At the other hand, sequential organization of the FLAMFILE is better suited for file transfer between computers with different operating systems. FLAM compressed data is always heterogeneously compatible. This means that compressed data, which was generated under a certain operating system, can be decompressed on all operating systems supported by FLAM. Depending on the available record and file formats on the target systems, record and file conversions may be necessary. FLAM can be executed online as well as in batch. It can be adapted in a flexible way to the requirements of the users. Several parameters are supplied for this purpose. These parameters may be entered or may be stored via the `PARM` interface. An additional parameter file is also possible. Default values for the parameters may be created during installation (see: Generation of Default Values). File attributes can be also defined via the DD command. During processing, parameters are evaluated in the following sequence: * First the installation parameters are used. * During decompression this values are substituted by the values from   the file header of the FLAMFILE, if available. * Then the values from the parameter file are used. The input PARM in   the EXEC statement overwrites these values. * File attributes defined in the `DD` or `ALLOCATE` command overwrite   again. According to this hierarchy, a very flexible mode of operation is possible. Please be aware that the sequence is not always chronological: For example, it is possible to select a parameter file via `PARM` input. This parameter file is read in after the input despite of the fact, that the `PARM` inputs will overwrite the specifications of the parameter file. Independently from the input medium, parameters are evaluated always using the same syntax. Only upper case letters are allowed. Parameters may be passed in one or more lines or records. In each line the parameter interpretation ends with the first blank position. After the blank any type of comment may follow. Single parameters must not be separated by end of line. Evaluation of the parameters is ended at the keyword `END` or by an empty input line (length = 0) or by `EOF` for the input medium. There are parameters with or without keywords. Keywords and values can be abbreviated. Within brackets [] alternative keywords are presented as used in other operating systems (z/OS, DOS/VSE, BS2000). Keywords from previous versions are presented within angle brackets. This keywords should not be used any longer. Because of compatibility reasons all parameters are presented although not all parameters are evaluated under z/OS. Keyword parameters can be specified in two different modes as usual under z/OS: or: A string value (file names, module names, password, ...) may be passed as C'.....' (characters) or X'....' (hexadecimal). All string parameters are assigned with blanks if '(NONE)' or no value is specified: or: The sequence of parameters is arbitrary if not otherwise specified. Only parameters that differ from the default values must be specified. In the following we describe all parameters in alphabetic order: Parameter may be abbreviated as long as they stayunique. Otherwise the first matching entry of the following summary is used. For more about every parameter see section <<CLEP.COMMAND.FLAM,FLAM COMMAND>>. It is also possible to control FLAM via environment or system variables. An environment variable overwrites a system variable. [width='90%',cols='^1,4',align='center'] |*Environment variables* |are stored in or set by an LE-Routine (like a C-program). They are used only in the actual step. |`FL_ZEDC_SUPPORT` |controls how to use a zEDC-Hardware. *Possible values:* *Default:* no value. Use it, if found. *Valid for:* * compression * decompression. NOTE: When a hardware is not found and the algorithm is required for decompression, a software routine is used. |*System variables* |are stored in `SYS1.PARMLIB(IEASYMxx)`. When for the same function an environment variable is found, the environment variable is used. |`&FLZEDC` |Controls how to use a zEDC-Hardware system wide. This is same as the environment variable `FL_ZEDC_SUPPORT`. *Possible values:* *Default:* no value. Use it, if found. *Valid for:* * compression * decompression. NOTE: When a hardware is not found and the algorithm is required for decompression, a software routine is used. |`&FLOGQL1` |First qualifier in logstream name of LOGR. *Possible values:* + * 1-8 characters as with IXCMIAPU defined. Activates FLAM logging. |`&FLOGQL2` |Second qualifier in logstream name of LOGR. *Possible values:* * 1-8 characters as with IXCMIAPU defined |`&FLOGQL3` |Third qualifier in logstream name of LOGR. *Possible values:* * 1-8 characters as with IXCMIAPU defined *Valid for:* * compression* decompression. *Example:* + IXCMIAU defines the logstream name FLAM.USAGE Then in Parmlib-Member must be stored: + NOTE: Without any system variable FLAM cannot log any data. Look for some examples to define a logstream in FLAM.JOBLIB. This description is valid for batch processing. Appropriate commands must be used for dialogue processing (TSO). FLAM is started via the EXEC command: Parameter specification must be made according to the JCL conventions (max. 100 characters, inclusion in quotes in case of special characters, like '=', '(', etc. ). FLAM parameters specified via `PARM=` will overwrite FLAM parameters stored in the FLAM parameter file. If the FLAM modules are not stored within a system library a FLAM load library must be specified: The input and output files can be assigned to FLAM via DD cards. The DD names used are predefined default names. Other DD names can be chosen via parameters. The following file types are supported by FLAM: * Physical sequential PS (also members of a PO library) * PDS / PDSE libraries (but no PDSE-LOADs) * VSAM ESDS / KSDS / RRDS / LDS The following record formats are supported: * V / VB / VS / VBS / F / FB / FS / FBS / U Print files (A or M) are also supported. The specification of a parameter file is possible but not mandatory (usually the PARM= instruction is sufficient): It is also possible to define the parameter file directly embedded into the JCL: For compression, an input file must be specified: This file must already exist and must be catalogued. It is allowed to be 'logically empty', which means that it does not contain a data record. For the creation of a compressed file (FLAMFILE) it is sufficient to write: With this card a sequential data set with a fixed record length of 512 and a system determined block length will be created. However, this may depend on the default parameters specified or on additional parameters supplied with the job. Using DCB attributes this assignment overwrites the `MAXSIZE` or `BLKSIZE` parameters for the FLAMFILE. The file is created according to the specifications in the DD statement. One example for using flexible configurations with the FLAMFILE comes from the area JES / NJE: If the FLAMFILE is already catalogued (`DISP=OLD`) FLAM will use the configuration details from the catalogue entry (even, if it is a VSAM file). For decompression an output file must be assigned. With this specification a decompressed file will be created that has identical characteristics regarding file format, record and block length with the original file. If a PO library has been compressed and a new PO file is to be defined for decompression by JCL, the selection rule `FLAMOUT=PO-file-name(*)` must always be specified. Otherwise member names are not known. If the original file came from a foreign system (VM, VSE, UNIX, Windows, If the FLAMFILE does not contain information about the original file, e.g. caused by parameter `HEADER=NO` during compression, the output file is created as variable blocked (VB) and with a maximum record length of 32756 bytes and a block length of 32760 bytes. Each DCB specification within a DD statement will overwrite the values automatically chosen by FLAM or specified as FLAM parameter. If the output file is already catalogued the catalogue entry will specify the file characteristics: All messages are written into a message file by default: or If no file is specified despite the fact that the parameter `MSGDISP=MSGFILE` is set, a message is written to the console via `WTO, ROUTCDE=11` and the program is terminated with a condition code. If messages shall be suppressed, `SHOW=NONE` must be specified in the `PARM=` entry within the EXEC card. Each file can be assigned as: This will suppress file output or inhibit file input. Since this does not affect the general processing of FLAM, it can be used conveniently for testing purposes: * evaluation of compression ratio * general testing of control flow * using own read and write routines from user exits (we recommend the USERIO interface instead, but in principle the possibility mentioned above can be used, too). The DUMMY assignments are not suitable for benchmarks. Because all physical disc or tape I/O is suppressed, this leads to a much shorter elapsed time, especially in case of later tape assignments or VSAM I/Os. NOTE: The record length in the DD statement must always include the length of the record length field in case of variable length records. Opposite to that, FLAM requires the actual length of the data (without length field) in it's own parameters and displays also only the actual length of the data in the protocol. To make this difference clear the parameter name `LRECL` has been changed to `MAXSIZE` for the FLAMFILE parameter printout. `IRECSIZE` and `ORECSIZE` are equivalent notations for the input file and the output file. The FLAM user interface for TSO users removes the task of writing JCL tatements from the user (including creation of VSAM files). All specifications can be made interactively. Also batch job streams can be generated with this facility. The specified files are allocated automatically by FLAM (dynamic allocation, SVC 99) by means of parameter input (`FLAMIN=filename`, `FLAMFILE=filename`, `FLAMOUT=filename`, ...), as long as a DD statement has not been specified. If the files are already catalogued, FLAM will use the configuration details from the catalogue entry. For reading the file is assigned with `DISP=SHR`, for writing with `DISP=OLD`. If the file is not already catalogued, it is created (`DISP=(NEW,CATLG)`). For decompression (`FLAMOUT=...`) data such as file organization, record length, block length, format and file size are taken from the FLAM file header, which means that the output file essentially corresponds to the original file. Parameter inputs, however, take priority over the stored data. When the parameter `FLAMOUT=<*>` is set, the file names stored in the file header are used (see section <<CLEP.COMMAND.FLAM.FLAMOUT,'File names in FLAMOUT'>>). The storage assignment contains the file size as primary specification, 1/4 of the file size being the secondary specification. In the case of PO libraries, the number of directory entries is also known. The file is thus stored in one extent on the disk. If the file size is not known, because e.g. a FLAMFILE is assigned or the compressed data has not been generated under MVS (and therefore does not contain the file size), default values are used (TRK,(30,900),RLSE). If the default values are inadequate, a DD statement specifying other values must be made or the file can be created before the job is run (e.g. with function 3.2 in ISPF). All file types supported by FLAM (PS, PO, and VSAM) can also be created dynamically again. However, since important information required for creating new files is missing (such as UNIT and VOLUME), SMS must be used. The fact that this information is missing is on the one hand due to data protection reasons (data exchange via file transfer!); on the other hand, they would usually not be useable due to transferral of the compressed data to other computers. After all, compressed data from foreign operating systems (VMS, VSE, UNIX, etc.) cannot even contain these specifications. NOTE: If parameters are specified and FLAM finds a DD statement via the DD-NAME, all the specifications in this statement take priority over the parameters specified or values stored in the file header. For job control FLAM returns the following condition codes: [width='70%',cols='^1h,4',align='center',options='header'] |Condition code|Description |0 | Normal termination (no error) |4 | Not all I/O files were processed during processing of group files |8 | Less severe error occurred (e.g. parameter error) |12| Usually a data management error |16| Severe error during compression or decompressi on |80| Compression ratio was less than the specified limit (see <<CLEP.COMMAND.FLAM.CLIMIT,CLIMIT>> parameter) |88| The file assigned was not a FLAMFILE Only for condition code 0 and 80 compression was done properly. In all other cases no or a faulty compressed file was created. We recommend to rename this file in order to avoid using it for processing at a later time. If a condition code greater 0 was returned an error message was already displayed by FLAM. Condition code 16 could be caused by a FLAM system error. The library `FLAM.SRCLIB` contains the call module FLAM. This can be customized as required, allowing other condition codes to be returned. Specifying a filename is an alternative to assigning the file by means of a DD statement. The specification can contain a conversion rule for filenames. The name can be specified in wildcard syntax for decompression. The character `>` in front of the filename means that the flamfile contains a list of filenames to be decompressed. `DUMMY` acts like the DD-statement `//.. DD DUMMY` In principle, FLAM is able to process all filenames via JCL valid in z/OS. FLAM stores the name of the compressed file into the FLAMFILE, if required. To avoid any conflicts with national character sets or naming conventions in other systems, all filenames stored in ASCII character set are translated for message and selection in the following way: All national characters are translated to 'X', a backslash '\\' to slash '/', and whitespace ' ' to underline '_'. So it is easier to enter foreign filenames that are unsupported in the z/OS environment. The filename itself remains unchanged in the FLAMFILE.  Entering `DUMMY` as a filename causes FLAM to use this file as dummy like the JCL command `//ddname DD DUMMY`. I.e. reading an input file leads to EOF (end of file), writing to an output file has no effect. So, DD-statements are not necessary for DUMMY files. By prefixing the '>' character (greater than) to the filename or DD-NAME, the FLAM parameters `FLAMIN` and `IDDN` are able to specify a list of files for compression instead of one single file. It is also possible to specify a file list for decompression by means of the `FLAMFILE` or `FLAMDD` parameter. In this list, each filename must be contained in a separate record; leading or trailing space characters (X'40') are ignored. A comment can be inserted after the first space character following the filename. Empty records or records with an asterisk '*' in the first column are regarded as comment lines. All filenames usable in z/OS are legal. Wildcard syntax is allowed. *Example:* If the records in the file USER.DAT.LIST contain the following filenames: the specification leads to all the files specified being compressed into one FLAMFILE (group file). The file that contains the list of filenames can have any format supported by FLAM and be of any type. For 'in-stream files', i.e. input files temporarily created by JES, it is advisable to assign the filenames by means of DD names: This allows the filename list to be specified directly in the job. Filenames can be specified in FLAM by means of parameters written with wildcard syntax. Correspondingly, the entry `FLAMIN=USER.*.DATA.%BC` leads to the compression of all files with the 1st qualifier USER, any 2nd qualifier, DATA as the third part of their name, and a three-digit 4th qualifier which ends with BC and begins with any character. The asterisk '*' stands for any (even an empty) character string. The percent character '%' stands for any character. These special characters are also allowed within members of one or more PO libraries: specifies all members of the library USER.POLIB, that begin with FL; specifies all members whose 4-digit names begin with A and end with B and whose libraries have the identification USER, LIB as their final qualifier, and D as the last character of the second to the last part of their name. All input files are stored in this way in one compressed file (group file). Correspondingly, the wildcard entry in the selection rule for decompression leads to the decompression of only those items of compressed data whose original names conform to the syntax specified. (Comment: this procedure requires a FLAM file header (`HEADER=YES`) and the file information `FILEINFO=YES`) for compression). *Example:* All files with names that conforming to the FLAMIN specification are to be compressed into the file USER.DAT.CMP. If the files are catalogued, the 1st file does not conform to the wildcard syntax and is ignored during compression. If is now specified for decompression, only the files `USER.DATCB.CLIB` and `USER.DATCB.DLIB` will be decompressed. Correspondingly, it is also possible to select a number of FLAMFILEs for decompression: means all FLAMFILEs with the identification USER, CMP as their 2nd qualifier, any character string as the 3rd part of their name and VR8 as their last qualifier are to be decompressed. NOTE: Pointed brackets '<>' explained blow are dropped in FLAM 5, because this conversion rules cause too much data transfer in case of remote processing. If pointed brackets '<>' are used, a migration for FLAM 5 is necessary. See section <<flcl.input.output.name.mapping,Input to Output Name Mapping>>. During decompression, the files can be created and cataloged by FLAM automatically. This requires the existence of a valid filename in the file header of the FLAMFILE (i.e. the parameters `HEADER` and `FILEINFO` must not be set to `NO` for compression). In addition, a FLAMFILE can contain several files (i.e. it is a group file) and it is possible to decompress specific files from such a group FLAMFILE on a targeted basis by specifying a selection rule. In order to distinguish it from a 'genuine' filename, a selection rule s written between angle brackets '<>' (!! deprecated !!). With the above rule set, the file `USER.FILE.ORG` is decompressed from the FLAMFILE. (Comment: if thepointed brackets were left out, the entire FLAMFILE would be decompressed and written into the file `USER.FILE.ORG`). This name must be contained in a file header of the FLAMFILE. If the FLAMFILE contains other compressed files, they are ignored due to the unique selection rule set. If several files are to be decompressed from a group file, a wildcard syntax can be specified. The simplest entry possible is a lone asterisk: This decompresses all of the files from the FLAMFILE and locates them on the disk under their original names. A selection rule is implicitly regarded by FLAM as having an asterisk at the beginning and at its end, i.e.: When analyzing the file names, FLAM synchronizes itself to the character string specified. *Example:* The FLAMFILE contains the data `USER.DAT1.PS` and `USER.DAT2.PO`. The specification decompresses only the file `USER.DAT1.PS`. Since there is no asterisk specified in the name, decompression is termimated after the first hit. NOTE: If, in addition to the selection rule, a file is assigned by means of JCL, the JCL specification takes priority. I.e., the above specification together with the DD statement leads to decompression of the USER.DAT1.PS file from the FLAMFILE and it is written into the PO library `USER2.POLIB` as the member `MEMBER`. This, then, allows the changing of file names during decompression by means of JCL specifications. NOTE: Angle brackets '<>' explained below are dropped in FLAM 5, because this conversion rules cause too much data transfer in case of remote processing. If pointed brackets '<>' are used, a migration for FLAM 5 is necessary. See section <<flcl.input.output.name.mapping,Input to Output Name Mapping>>. This simple method of selecting files for decompression by means of a selection rule can, however, not normally be used for compressed data that has been generated under a different operating system (heterogeneous exchange of compressed data). The file names do not normally conform to the rules of the MVS operating system and can therefore not be used without being modified. For this purpose, it is possible to specify a conversion rule as the parameter for the output file. This character string describes how a new name is to be generated from a file name selected. At the same time, precisely those files that conform to the rule (selection rule) are selected. A conversion rule is a selection rule that is extended by an equals sign '=' and a second character string. In order to distinguish it from a 'genuine' filename, it must be written between pointed brackets '<>'. The rule comprises a character string that may contain an asterisk '*' as a substitute character for any number of characters or a percent sign '%' as a substitute for precisely one character. An ignore character (apostrophe ') is also defined. Each asterisk '*' or percent sign '%' in the selection rule must be assigned an asterisk or percent sign or an apostrophe in the conversion rule. The asterisk means that the character string in the input file is to be transferred unchanged to the output file. Correspondingly, the '%' transfers precisely that character located in this position. The apostrophe sees to it that the character string or character represented in the input file by an asterisk or percent sign respectively, is not transferred to the output file. The remaining characters from the input file are translated into the corresponding characters from the conversion rule. The length of the character string an be changed as desired. With this rule, all file names beginning with `USER` are converted to the new identification `USER2`. The rest of the name is retained. With this rule, all files with the identification `USER` are given the prefix `DEC` before their old name. In the process, only those files are affected whose second part of their name begins with `DAT`, is followed by any character and ends with `B`. This `B` is converted to `C` in the name of the output file. Above all, empty character strings are also allowed in the conversion rule, so that characters can be deleted. E.g.: Old name: `USER.FLAMUP00` + New name: `USER.CMPFLAM00` The UP part of the name is not mentioned in the output name and is therefore left out. A conversion rule is implicitly supplemented by FLAM, e.g.: This can be particularly useful when converting the filenames from other systems. *Example:* The FLAMFILE created under DEC/VMS contains the following filenames: This corresponds to specification of the file versions of the user ABC on disk volume `DUA1`, with the version number stated after the semicolon. In order to be able to create these files in MVS, the following conversion rule could be specified: This implicitly deletes the name prefix `DUA1:[ABC]`, takes over the part of the name beginning with DE and supplements it with the identification, and deletes the rest of name: The conversion rule is also important with respect to generating members of a PO library: This rule means that the 2nd name qualifiers of the original file are used as member names of the PO library. So far, the conversion rule has only been described for decompression from a (group) FLAMFILE. It can, however, also be used for compression with simultaneous generation of several items of compressed data in different files. In this respect, the conversion rule relates to the FLAMFILEs whose names are generated from the file names of the input files (FLAMIN). This is how all compressed data could be given a prefix: It is, however, also possible to store each item of compressed data as a member of a library by means of the following specification: The member name is, in this case, the 2nd qualifier of the input file. Also valid here: if a library is specified for the FLAMFILE by the JCL, the name of the library as specified in the rule is ignored and only the members in the specified PO file are generated. The reverse also applies: file names of the FLAMFILEs are used to generate file names for the decompressed files: NOTE: If a group file has been created with `HEADER=YES` but `FILEINFO=NO`, no filename has been stored for this file. The individual files can then be accessed for decompression via the internal file name: the name is in the range from `FILE0001` (for the first file) to `FILE9999` (for the 9999th file). is for the third file in the group file; or is for decompressing all files according to the conversion rule. *Comment:* As a 'final rescue option' for automatic generation of the decompressed data with 'impossible' filenames from foreign operating systems, the parameter `FILEINFO=NO` can be specified for the decompression process. With this parameter, the stored filenames are ignored and the internal names `FILE0001` to `FILE9999` are generated. These must then be converted to valid filenames by means of a conversion rule. ==== Subprogram FLAMUP FLAMUP differs from FLAM in that respect, that it can be called as a subprogram out of an application. All accesses to data are performed via FLAMUP. All parameters can be passed to FLAMUP using the CALL interface or methods as provided by FLAM (interactive parameter definition or parameter file) can be used. Using FLAMUP within a driver program allows for example to select a certain set of files and to compress/decompress all the selected files in one step. A typical example is, to select only files that were modified after a certain date (archiving). ==== I/O User Interface This interface allows the user to integrate own access methods into FLAM. One possibility is to pass the compressed records immediately to post-processing routines without creating a compressed file. Vice versa, during decompression the compressed records may be received from a preprocess instead of reading them from a file. A direct application could be the integration of FLAM with a file transfer application avoiding the creation of intermediate files. Generally this interface allows to intercept all input and output data of both FLAM and FLAMUP. This allows the user to adapt FLAM easily to specific access methods. ==== User exits This user exit interfaces the record passed to FLAM for compression. Special processing can be defined for: Start of file, record level, end of file. Records can be passed on, modified, deleted or inserted. This exit can be used to modify records in a structure dependent way. EXK10 is only available in FLAM and FLAMUP and corresponds with EXD10 during decompression. This exit interfaces the compressed data before it is written into the FLAMFILE. Special processing can be defined for: Start of file, record level, end of file. This exit can be used to modify records in a structure-independent way. With this exit it is possible, to modify the data with an own encryption routine, or a special code translation can be applied if a non-transparent file transmission method shall be used.It is possible to insert own records in front of the compressed records, for example archiving control records or origin information. Another possibility is the extension of records to append specific revision information. EXK20 is available in FLAM, FLAMUP and FLAMREC and corresponds with EXD20 during decompression. This exit interface the decompressed record immediately before it is written into the target file. Special processing can be defined for: Start of file, record level, end of file. Records can be passed on, modified, deleted or inserted. This exit can be used to modify records in a structure dependent way. EXD10 is only available in FLAM and FLAMUP and corresponds with EXK10 during compression. This user exit interfaces the compressed data immediately after it is read from the FLAMFILE. Special processing can be defined for: Start of file, record level, end of file. This exit can be used to modify records in a structure-independent way. With this exit it is possible, to decrypt the data with an own decryption routine or to apply the reverse code translation as used during compression. For a proper operation of FLAM it is indispensable that all changes applied to the compressed data are reversible. User exit EXD20 must deliver exactly the same data as user exit EXK20 received. All modifications applied to compressed data with EXK20 must be undone with EXD20.  EXD20 is available in FLAM, FLAMUP and FLAMREC and corresponds with  EXK20 during decompression. This user exit returns a key to the FLAM utility for en/decryption of a FLAMFILE. So it is possible to enter any PASWORD/CRYPTOKEY in a secure way without notice to the JCL or the protocol. This exit is implemented as an interface to special key management systems, without influence to the FLAM utility programs. ==== Utilities Some utilities are released that improves support form FLAM and FLAMFILEs for z/OS only. FLAMCKV analyses a cataloged VSAM-KSDS FLAMFILE. It displays the procentual distribution of record lengths and the number of records needed for one FLAM matrix (in FLPRINT, RECFM=VB,LRECL=124). This is very important for direct access to a VSAM-KSDS FLAMFILE. _Please remember:_ FLAM needs a complete matrix (i.e. a block of self-contained compressed records) for decompression. Even for direct access to a single record this complete matrix is requirerd. So performance is best when this matrix is stored in one VSAM record. If the VSAM record is too small to fit a complete matrix, FLAM has to read or write mutiple records. This decreases perfomance. These requirements are not so important for a small amount of data. But if thousands or millions of records are stored it becomes more and more relevant. *Example:* Utility FLAMCTAB should not be used anymore in order to create translation table modules. All common translation table modules are provided and can be downloaded from our website under: https://flam.de/en/technology/download/addons/[FLAM4 Translation Tables]. Please use further information described there and the precompiled load modules for the most common convertions you can find under download. Another alternative under FLAM5/FLCL is usage of command 'FLAM' with keyword 'FROM' (conversation from CCSID) and 'TO' (conversation to CCSID [UTF-8]). FLAMDIR reads a FLAMFILE (DD-name FLAMFILE) and logs the directory of the compressed/encrypted files. The output (DD-name FLPRINT) looks like an ISPF panel 3.4 or option 'I' in FLAM start panel or FLTOC clist. Using the FLAM-parameter `D,SHOW=DIR` you still get a full protocol of the directory of the FLAMFILE. But using FLAMDIR the protocol is a conveniently laid out short summary of the directory of a Group FLAMFILE. *Example:* ",
"",
""
],
[
"flam4_manual-flam4_utility-matrix_buffer_details_7adc.html",
"Matrix Buffer Details",
"=== Matrix Buffer Details The size of the matrix buffer and the number of records which are stored there can be specified for the compression procedure using the maxbuffer and maxrecords parameters. As a general rule, the efficiency of the compression procedure increases the more records are compressed together in the same block. If there are no other factors which need to be taken into account, it is normally best to choose the highest possible number (255 or 4095, resp.). This preset number is, however, merely an upper limit. There may be fewer records if the space in the matrix buffer is exhausted or if the end of the original file is reached. The size which must be set for the matrix buffer is dependent on the number and size of the records that need to be buffered.The space requirement for files with fixed-size records is calculated simply as the product of the number of records and the record size. If the files have a variable record size, it is not normally possible to predict the memory requirement exactly. The value which is chosen is bound to be approximate. However, the matrix buffer must always be at least large enough to hold every individual record in the file. ",
"",
""
],
[
"flam4_manual-flam4_utility-flamfile_details_61cd.html",
"FLAMFILE Details",
"[[flam4.main.flamfile.details]] === FLAMFILE Details Below you can find more details about the construction of a FLAMFILE. In order to achieve the aim of universal interchangeability, the structure of the FLAMFILE must be such that it can be represented in any operating system. This 'least common denominator' is the sequential file with fixed-size records. Although other FLAMFILE record formats are allowed for the FLAMFILE in addition to the fixed format, the compressed data which is generated by the compression procedure is broken down into 'abstract' records - known as FLAM records - with an identical size; these records are then mapped to the 'concrete' structures of the installed operating system. In addition to the compressed data, each FLAM record contains a FLAM record size field at the beginning and either a checksum or a check character at the end. The FLAM record size field and the checksum or the check character are elements of the FLAM syntax. This permits the start and end of a FLAM record to be identified irrespective of the record format in which the FLAMFILE has been stored by the operating system. In FLAM4 terminology, a FLAM record is the same as a record if the FLAMFILE has fixed and variable record formats. The specified FLAM record size is thus the same as the record size or the maximum record size. The residual data in a compressed block belonging to a FLAMFILE is merged with the data in the next block to form a FLAM record with the fixed or maximum size. With the possible exception of the final record, all the FLAM records have the same length. This enables optimum use to be made of the storage medium; however, it is not possible to assign the records of the original file to the records of a FLAMFILE uniquely. A FLAMFILE of this type can therefore only ever be decompressed in its entirety. FLAM supports fixed and variable or stream record formats for the FLAMFILE. Irrespective of the record format, the minimum permissible size of a FLAM record is 80 bytes and the maximum size 32,760 bytes (4095 for `mode=cx7`), providing a lower upper limit has not been set by the user. This span is sufficient in practice to allow any FLAMFILE to be transferred, even in situations where this would not necessarily be the case with the original file, owing to restrictions imposed on the record size or the record format by the file transfer product. Even though many data exchange problems can be eliminated to a greater or lesser extent with the FLAM4 concept, there are some which still cannot be solved. If a file is unsuitable for uncompressed transfer with a particular file transfer product, for example on account of the binary data it contains, it will still not be possible to transfer it after it has been compressed with FLAM, even if it is compressed in the cx7 mode. The reason for this is that every bit combination which occurs in the original file also occurs in the FLAMFILE. In addition to the compressed data, a FLAMFILE may contain other information which is stored in the FLAM file header. FLAM distinguishes between two information categories in two different types of file header: Common information is stored in the common FLAM file header. This includes all information about the original file, such as the file organization, record format, length and position of the primary key, etc., as well as details of the FLAM version and the operating system in which the FLAMFILE was created. User-specific information of any kind is stored in the user-specific FLAM file header. This header type can be inserted additionally if the record interface is used, for example for information which must be evaluated by the application program. Creation of the common FLAM file header is supported by all interfaces (command, subprogram and record) by means of parameters and arguments. A user-specific FLAM file header can only be created if the record interface is used. This interface incorporates the following functions for creating and evaluating the various file header types: [width='60%',cols='^1,^1,^1',align='center',options='header'] |FLAM file header type| Created by| Evaluated by |Common               |flmphd     |flmghd |User-specific        |flmpuh     |flmguh It is not mandatory to insert FLAM file headers in the FLAMFILE. If they are inserted, it is essential to observe the stipulated order when invoking the functions of the record interface. FLAM file headers are always inserted in the FLAMFILE directly preceding the compressed version of the file to which they belong. If a FLAMFILE contains compressed versions of several files, a FLAM file header can be inserted in front of each compressed file. When the files are decompressed, the compressed data originating from different files can be distinguished and decompressed into separate files. Each record in a FLAMFILE is protected against manipulations and transmission errors by an appended checksum. In compliance with increased requirements regarding cryptographic security, additional security features for encrypted FLAMFILEs have been implemented which improve the protection against a greater variety of attacks. A FLAMFILE provided with these features is called 'Secure FLAMFILE'. * The new protection mechanisms work on three levels * the segment level, * the member level, and * the file level. Here, 'segment' denotes the compressed result of a single matrix and 'member' the entirety of segments from a single original file. In a Secure FLAMFILE, there are byte and record counts both for each member as well as for the entire file, members are numbered consecutively, and a timestamp marks the creation time. When encrypted with AES, MACs (Message Authentication Codes) are attached to the FLAMFILE. Those are checksums calculated with a secret key that allow verifying the authenticity of the data. A MAC is calculated for each segment. To ensure the completeness of a member, a second MAC is chained through all segments of the same member, and a third MAC, chained through all members of the FLAMFILE, ensures the completeness with regard to the file. Similar features are included when FLAMFILEs are created with `mode=flamenc`. To include the information necessary for these checks, such as counts, timestamps, MACs, etc., a member header is inserted in front of each member and each member is followed by a member trailer. In addition, a file trailer is appended at the end of every Secure FLAMFILE. Secure FLAMFILEs may not be concatenated since this would create discontinuities of numbering, counters, and MAC chaining that would make FLAM assume integrity violations and break off processing. Individual members of a FLAMFILE, however, can be extracted, since checking of the member chaining is suspended, whenever members are skipped, and only the segment chaining is then tested. All formats and file organizations for the original file are supported for the compressed file, called FLAMFILE (PS, IS, VSAM-ESDS, -KSDS, -RRDS). Compressed files in VSAM KSDS format can be modified record by record using record level interface. With parameter `CRYPTOM=AES`, `MODE=CX8` or `VR8` it is possible to update, insert, delete original records in a compressed and AES-encrypted VSAM-KSDS FLAMFILE. The use of this record level interface and the facility to store compressed data in index sequential files (VSAM KSDS) allows a fast random access to compressed data. This is well suited for setting up online archives for documents and similar data. ",
"",
""
],
[
"flam4_manual-flam4_utility-interfaces_d00d.html",
"Interfaces",
"=== Interfaces FLAM provides a set of interfaces that allow the use of the product within different environments and for different applications. The simplest application is the execution of FLAM via the EXEC command. This allows to compress or decompress complete files. In addition, FLAM provides a set of subprogram interfaces for integration with other programs and products. This also allows to develop tailored applications where FLAM is embedded in dedicated control programs. User exits provide the pre- and postprocessing of the original data as well as of the compressed data without the additional step via intermediate files. All interfaces are designed in regard to higher level programming languages like COBOL. Only in cases where the usage of address pointers is a conditio sine qua non, assembler (or equivalent, e.g. C) interfaces must be used. FLAM can be embedded in user-defined applications or vice versa by means of calls at different levels. The available interfaces are listed in the table below: [width='90%',cols='1,1,2',align='center',options='header'] |Interface | Call level | Purpose |*FLAM utility* via EXEC command | System | Compress/decompress entire files interactively or in procedures |*flamup subprogram* | Application programs | Compress/decompress entire files in user-defined applications |*flamrec record interface* | Application programs | Transfer and recall individual records in user-defined applications |*User-defined input/output* | FLAM | Replace FLAM input/output routines |*User exits and File access exits* | FLAM | User-defined file and record pre-processing and post-processing for   compressed and non-compressed data Key management These interfaces have a hierarchical order, which defines which interface can be used or invoked from where. The interfaces are subdivided into two categories: active and passive. Active interface calls are initiated either by the user or by his application program; they activate the FLAM routines which support them. These routines include the command and the subprogram and record interfaces. FLAM uses passive interfaces to activate user routines which are required to perform a particular range of functions, but whose calls are not synchronized with the logic of the application program. This category includes the user-defined input/output and the user exits. The next few sections contain a brief description of the ways in which the different interfaces can be used, without covering every single detail. Each of the following chapters contains a detailed description of one of the interfaces and can be used as a reference document. All the program interfaces, i.e. all interfaces other than the command, are represented in C notation in the reference chapters. However, these interfaces do not support C programs only. Rather, they can be used with any programming language, since all arguments are also referenced by addresses instead of the typical C referencing by values. Addtional beside the C calling interface and the load module interface (COBOL, PLI, ASSEMBLER) Java and other object oriented class library interfaces are available. Even though, in a strict C context, a name without an '*' operator still identifies the argument address with this form of transfer, all references to such arguments in the descriptions below in fact relate to the argument values. ==== The FLAM Utility FLAM as a utility can be started on job control level via a job control command. Parameters define the mode of operation. Depending on the operating system, parameters may be supplied as a part of the command or may be entered via the screen. In addition can be parameters read from a parameter file. This file can be assigned to the process using job control commands or command parameters. The FLAM command can be used to compress or decompress individual files or groups of files either interactively or by means of procedures. The compress or decompress parameter specifies which operation is to be performed. All the information necessary to execute the command can be specified in the form of inputs made directly in the command line, in a parameter file or as property values. The FLAM command permits a separate FLAMFILE to be created from each original file. It is also possible to compress a group of original files into one FLAMFILE. The attributes of the decompressed file, such as its organization and record format, may otherwise differ from those of the original file. FLAM can thus also be used for file conversions. The FLAM command and all its parameter is described in detail in this manual below. ==== The FLAMUP Subprogram The interface to the FLAMUP subprogram permits roughly the same operations as with the FLAM Utility to be initiated in an application program. This interface makes the same range of functions available to the application programmer as to the user, with the exception of the built-in functions. FLAM parameters are used to specify these settings, similar to the procedure for the parameter file. These parameters are specified consecutively in an character string, which is transferred to the subprogram in the form of an argument. Once again, it is possible to refer to a parameter file using the parameter parfile=parameter file. If any information is omitted, the same default settings and properties are used as for the FLAM Utility command. When flamup has been executed in its entirety, the invoking program receives a return code indicating either the success of the call or the cause of the error. The FLAMUP load module interface and the flamupc interface is described in detail in the FLMUP interface spezification. See also: https://flam.de/en/technology/products/flam/api-subprogram/[FLMUP] ==== The FLAMREC Record Interface The FLAMREC record interface permits file processing and compression to be integrated in an application program. Decompressed records can be read sequentially from a FLAMFILE. A new FLAMFILE is created when the compressed data is output. A FLAMFILE can thus be opened either for read accesses only (decompression) or for write accesses only (compression). FLAM's record interface consists of a class of functions, which allow the application program to access and process compressed data in the same way as is possible with ordinary input/output instructions in the case of non-compressed data. The use of these functions is governed by rules similar to those which apply to the standard input/output. After the file has been opened, records can be read or written; the file is closed again when all processing has been completed. The compression or decompression that takes place during processing is completely transparent to the programmer, so that compared to programs using conventional input/output operations, there are almost no differences in the program logic. By using the record interface, compressing (or decom-pressing) the processed data no longer requires an extra step after (or before) running the application. In addition, it is no longer necessary to provide sufficient temporary storage space for both the compressed and the uncompressed copy of a file. The FLAMREC load module interface is described in detail in the FLMREC interface spezification. See also: https://flam.de/en/technology/products/flam/api-record-interface/[FLAMREC] ==== The User-Defined Input/Output FLAM supports all inputs and outputs to and from disk files using standard input/output instructions. However, it also allows the user to replace these standard input/output routines with routines of his own. This may be a good idea, for example, if there is a possibility of an input/output device other than a hard disk being used or if the file contains a record format which is not supported. It is not possible to describe every single aspect of every function of the user-defined input/output in detail, since these vary according to the device and to the nature of the data. Data which is received via a modem line, for example, requires different actions from data supplied by measuring instruments. FLAM considers the origin of the data to be 'file', even though in a particular instance other objects may be involved. The functions of the user-defined input/output are as follows: [width='60%',cols='^,^,^',options='header',align='center'] |Function |Purpose                         |Corresponding I-O calls |usrcls   |Terminating processing of file  |fclose |usrget   |Reading one record              |fgets |usropn   |Opening file                    |fopen |usrpos   |Positioning to record           |fseek |usrput   |Writing one record              |fputs FLAM specifies a range of functions based on the file processing requirements for this interface, in accordance with the above point of view. It is up to the user of the interface to optimize the design of the functions, to ensure that the desired results are achieved with them. In order to be able to use a user-defined input/output, the routines concerned must be linked to the application program. This option is therefore only supported by the program interfaces, i.e. by the subprogram and record interfaces. The support by the record interface of course only applies to accesses to the FLAMFILE, since these are the only types of access which take place via it. A user-defined input/output is initiated by invoking flmopd with device=7. This input/output can be activated at the subprogram interface for all the files which are concerned by the compression or decompression procedure, by means of the FLAM parameters user_io, inuser_io and outuser_io. Whereas, with the functions of the record interface, the programmer is obliged to observe a series of rules regarding the order and consistency of the calls, the correct interaction of the functions of the user-defined input/output is the responsibility of FLAM, which also takes the initiative for the calls. The programmer of the user-defined input/output routines is merely required to make sure that the actions and behavior of the individual functions are correct. The description in this chapter is therefore restricted to these aspects. usropn is invoked first of all once, and once only, for each assigned file. The workio argument causes a work area of 1024 bytes to be made available as file-specific memory. This area is adopted automatically for all subsequent calls until the usrcls. The openmode argument specifies the desired access type (input, output). The record_format, record_size, etc. arguments specify the file and record attributes, which can be adapted to each particular file if necessary. The successful termination of the function and any special states or errors can be reported by means of predefined and freely assignable return codes. Each return code is evaluated by FLAM, and passed on to the invoking programs if an error is established. A record is transferred for writing with usrput. If the record cannot be written with the specified size, the return code must include the information that it has been either shortened or padded with the characters specified by padchar in the usropn. FLAM requests the next record with usrget. The maximum number of characters which can be transferred is specified in the buffer_length parameter. If the record needs to be shortened as a result, this must be indicated by the return code. The return code must also indicate when the end of the file is reached. The record size must be returned for each record which is read (even if the record format is fixed). usrcls causes the file to be closed. The work area for this file is released again by FLAM after control has been handed back. ==== The User Exits User exits allow pre- and post processing of records before compression and after decompression under FLAM as utility as well as pre- and post processing of compressed records under both FLAM as utility and FLAM record level interface. E.g., this user exits can be used for encryption purposes or for selective processing of original data. A user exit is a user-provided program that is invoked by FLAM at specific events during the processing via the defined interface. These user-provided program has to be linked statically. FLAM supports two catagories of user exits: file access exits and an exit for automatic key management. ==== File Access Exits (s. also FLAM4 manual in paper form) These exits permit the user to postprocess the records output by FLAM (both those contained in the FLAMFILE and those in the decompressed file) before they are finally saved, i.e. they can be modified, deleted or given additional records. The records which are read by FLAM can be prepared for processing by FLAM in the same way. The term 'access' refers in this context either to an input/output instruction or to a corresponding call of the user-defined input/output, and not to a call of a record interface function. Thus - at least as far as the FLAMFILE is concerned - the user exits are not synchronized with the application program, since the latter is not able to establish, for example, whether or not a flmget call actually does initiate one or more read operations. These user exits can be activated via the subprogram interface or the record interface, the latter being able to activate the user exits for FLAMFILE accesses only. The programs invoked through these interfaces must be staticly linked to the application. A user exit is invoked each time the file is opened, read, written or closed. The functioncode argument indicates to the user exit the access type, to permit it to respond in the appropriate manner to each particular situation. FLAM supports the following user exits for file accesses: [width='40%',cols='^,^',options='header',align='center'] | User exit | Invoked for accesses to | EXK10     | Original file (compress) | EXK20     | FLAMFILE (compress) | EXD10     | Decompressed file (decompress) | EXD20     | FLAMFILE (decompress) User exits exk10 and exk20 can be used during the compression procedure for accesses to the original file or to the FLAMFILE, whereas exd10 and exd20 can be used during the decompression procedure to access the decompressed file or the FLAMFILE. If records contained in the FLAMFILE were modified by user exit exk20 when they were compressed, they can only be decompressed if the modifications are undone again by the complementary user exit exd20, i.e. if every FLAM record is reset by exd20 to the state in which it was originally transferred by FLAM at user exit exk20. ==== User Exit for Automatic Key Management Automatic key management facilitates handling encrypted files by relieving the user from duties like generating, exchanging and storing passwords, in whatever way. When invoking the key management exit routine for encryption, FLAM also passes an optionally user-supplied character string via the interface. The exit returns a key value which is used by FLAM for encryption. In addition, the exit may also return a byte string that FLAM attaches to the encrypted FLAMFILE. When decrypting, FLAM passes this string back to the exit for the retrieval of corresponding decryption key. This exit can be activated by the flam command or the subprogram interface. It is also available via the record interface. Programs invoked through these interfaces must be created as shareable objects and are linked dynamically. IMPORTANT: Throughout this manual the terms 'password' and            '(encryption) key' are used synonymously. An exapmle for a professinal solution which use the FLAM Key Management Extension (FKME) together with Hardware/High Security Modules (HSM) for PCI DSS conform handling of card holder data in paymant systems can be found on the link below (in german only): https://www.flam.de/ftp/specifications/SpecFKME_HYB_SYM_AES.pdf[FKME] The interface specification for FLAM4 FKME can be found at: https://www.flam.de/ftp/FL5/doxygen/FKME/[FKME] ",
"",
""
],
[
"flam4_manual-flam4_utility-installation_1b21.html",
"Installation",
"=== Installation The product FLAM with all its components (FLCL, FLCC, FLSSRV, ...) is delivered in two parts. The main package contains the whole software and is available as download or via package repository (various Linux distributions). The second part is the license, which determines the features and platforms that can be used, where and for what you can use the software. If only the main package is installed, then a limited DEMO license can be used. ",
"",
""
],
[
"flam4_manual-flam4_utility-installation-license_aabb.html",
"License",
"==== License FLAM is protected against unauthorized use. The authorized usage of FLAM is only possible with a licence module provided by Limes Datentechnik. A licence allows the usage of FLAM on one or multiple computers, capacities, users or per usage. There is a difference between test licences for a limited period and unlimited (or limited) production licences. A test licence allows the testing and benchmarking of FLAM with all functions for a defined period (e.g. 30 days). * Test licenses must not be given to a third party. * During the test period, no backup copies of the   test programs are allowed. * After the test period is expired all test programs must   be deleted. A production licence allows the limited or unlimited usage of FLAM on any computer for which a licence was obtained. FLAM compresses structure-oriented using an algorithm that is a part of the Frankenstein-Limes method. This method has been patented in the Federal Republic of Germany and the United States of America and at the European Patent Bureau, registered by the inventor on 19th September 1985. ",
"",
""
],
[
"flam4_manual-flam4_utility-installation-download_7b88.html",
"Download",
"==== Download FLAM(R) can be downloaded from our website with the following link: https://flam.de/en/download/flam/ INSTALL and README text files are included as guides for installation. The download area distinguishes several operating systems: [width='50%',cols='2,5',options='header'] |Operating system | Link to installation instructions |AIX              | https://flam.de/en/download/flam/latest/aix/install.txt |Linux            | https://flam.de/en/download/flam/latest/linux/install.txt |Solaris          | https://flam.de/en/download/flam/latest/solaris/install.txt |Windows          | https://flam.de/en/download/flam/latest/windows/install.txt |zSeries Linux    | https://flam.de/en/download/flam/latest/zSeries/linux/install.txt |zSeries USS      | https://flam.de/en/download/flam/latest/zSeries/uss/install.txt |zSeries z/OS     | https://flam.de/en/download/flam/latest/zSeries/zos/install.txt Manuals can be found at: https://flam.de/en/technology/download/documentation/ ",
"",
""
],
[
"flam4_manual-flam4_utility-installation-replace_external_libraries_db74.html",
"Replace External Libraries",
"==== Replace External Libraries External libraries under LGPL are linked in dynamic form and can be replaced by another dynamic library which fulfills the corresponding interface. This can be done by deleting the library in the program directory if the replacement library is located in the library path or by overwriting the library in the program directory. The list below contains all LGPL based libraries used by FL5 per platform. glibc on Linux:    This library is part of the operating system and a prerequisite to    run the FL5 infrastructure on Linux systems. FL5 can be used with    different version and distributions of linux. Replacement of glibc    will be done by the normal update process of your linux installation. libfuse on Unix:    This library is part of the operating system and a prerequisite to    run the FL5 file systems on Linux systems. The file systems are    delivered for libfuse version 2 and 3. Replacement of libfuse    will be done by the normal update process of your Unix installation. libssh:    The libssh library can be found in the installation directory. A    customized version is used that is not compatible with the official    libssh releases. The modified libssh source can be found at:    https://github.com/limes-datentechnik-gmbh/libssh Attention: In all cases we recommend using the tested and supported libraries from this package. If a supplied library is replaced, the license terms and warranty of the new library become valid, replacing the license and warranty of the replaced library. ",
"",
""
],
[
"flam4_manual-flam4_utility-filename_handling_d885.html",
"Filename Handling",
"=== Filename Handling All filenames are mapped by CLE/P, which means that all replacement mechanisms it supports are also valid for each filename used within a command. See <<clep.main.filemap,filename mapping>> of <<clep.main,Command Line Processor>>. All filenames specified in command strings are parsed and handled in a unified way across the different platforms. Standard replacements by shells are usually not usable within the command syntax. There are some special attributes that can be appended to a filename when using paths or the URL-like syntax by using one of the following separators followed by a value string: * `/?` - member name (to access a member in an archive by name) * `/:` or `/#` - member index (to access a member in an archive by position) * `/&` - CCSID that the file's contents are encoded in If the URL-like syntax is used, special characters can be URL-encoded as a percent character followed by two hex digits (%xx). If no schema is provided, but a raw path, URL-encoded characters are not decoded because the string is not a URL. The schema `file://` can be used to access a local file on the system in URL-like syntax. Providing a CCSID is mainly intended to be used for parameter files which are read to memory from a remote location which may require conversion to the local character set. The filename is the only way to specify the CCSID for this type of files. Filenames in archives (ZIP, TAR, FLAM) or certain file headers (GZIP, PGP) are sanitized when reading or writing to prevent directory traversal attacks. This type of attack aims at writing files in arbitrary locations in the filesystem by storing specially crafted paths in the archive or file header. For example, extracting a ZIP file containing paths such as `/etc/passwd` or `../../../../../../etc/passwd` as user root on a Unix-based system could lead to a lock-out of all users. Path sanitization removes all path components that lead to an extraction outside the desired output directory. This includes turning absolute paths into relative ones and removing all `..` directory components. Both example paths above would be transformed to `etc/passwd` which are safe for extraction. The filename handling works as follows: Usually, a filename has to be specified fully qualified, because a dynamic allocation is done in most cases. The following substitutions can be used, which are automatically replaced by their respective value during execution: If the environment variables below are not defined, the following defaults are used: The syntax to define a DD name is: A replacement may also be used in a DD name definition: Additionally, you can specify member names in a DD name definition if a PDS(E) is allocated. The member name can be fully qualified or contain wildcards. Member names for archives can be specified as part of the URL-like notation or it can be specified separately. When using static allocation (DD name) for writing, the DCB parameter must be provided if the file does not exist. Otherwise, the defaults of the runtime environment (often `PS RECFM=UNDEFINED LRECL=0 BLKSIZE=6144`) are used. A static allocation is only useful to write the logical byte stream in a certain physical file format. In all other cases, we recommend to use dynamic allocation when writing new files. Since version 5.1.22-28565 the DD name must not be prefixed with 'DD:' anymore. If only one qualifier given, if it a valid DD name and if a allocation for it found, then the qualifier will be used as DD name. If you use FILE=STREAM when reading the file descriptor STDIN (DD:SYSIN) and when writing STDOUT (DD:SYSPRINT) is used. All other messages are printed by default to STDERR (DD:SYSOUT). For read the default DD name 'FLAMIN' and for write the default DD name 'FLAMOUT' is preferred if no file specification given. If such a allocation not found at write the default dataset name (original name plus extension) is used. For read or write of a FLAMFILE additional the DD name 'FLAMFILE' are supported to be backward compatible with the old FLAM utility. A Unix path name must contain a forward slash (`/`). To use a file in the current directory `./filename` must be used. Paths relative to the home directory may start with a tilde character (`~`) as an abbreviation for <HOME> for UNIX pathnames or <SYSUID> for host dataset names. NOTE: Starting with version 5.1.5, the plus sign (`+`) can no longer be used as abbreviation for the user's home directory. The tilde (`~`) remains unaffected and is now the only valid abbreviation. The plus sign (`+`) is now a wildcard character. It was supported as alternative for EBCDIC systems, because tilde is located on different code points depending on the EBCDIC code page. Since version 5.1.5, we support the correct interpretation of diacritical characters on EBCDIC systems based on the CCSID defined in the environment variable LANG. see <<clep.main.usedenv,Used environment variables>> and <<CLEP.MAIN.EBCDIC,SPECIAL EBCDIC CODE PAGE SUPPORT>> of <<clep.main,Command Line Processor>> To specify the casing (mainly useful for USS on ZOS) for a user ID, the following definitions can be used (if not defined as environment variable): A filename may be an absolute or relative path and may contain any of the substitutions (including ~) mentioned in the previous section. To use a smaller than character (`<`) as part of a filename, the character must be escaped by doubling it. We recommend not to use special or whitespace characters in filenames. The ampersand character (`&`) can be used instead of at sign (`@`) because the letter has different code points in EBCDIC. (the alternative character on EBCDIC, if `@` is not working, is `§` (the command line parser converts the `@` corresponding to the environment variable LANG on EBCDIC systems, if the value not set or wrong, then you can use `&` or try `§`)). On USS and Micro Focus EDZ, DD names are supported. A UNIX path name is distinguished from a data set name in the same way as it is done in the z/OS runtime environment. Example on USS or EDZ: If the variable FLAM4MF is set to `yes` or a valid CCSID, a DD name is assumed unless it contains a dot character and is used as the dataset name. Otherwise a DD name must be specified as DD:name and a dataset is given with `//'name'` This corresponds with the syntax for host dataset names on USS of z/OS. With the Microfocus support for Windows and Linux, you can work on x86 Windows and Linux systems with the local MF-EDZ-Enterprise-Server like you work with the catalog access on USS for MVS files. If you work with EBCDIC on the record interface in a EDZ environment then you must set the FLAM4MF environment variable to the used CCSID (e.g. IBM1141). If a CCSID is defined and starts with `IBM`, this will also override the default CCSID in the character conversion component and mark it as z/OS platform. In an error situation, it is possible to enable writing a trace to a file, which can be used to analyze problems. The environment variable `FLAM4MF_TRACEFILE` must contain a valid filename to write the trace output. To set the missing system variables for MF-EDZ, several solutions are implemented including `DD:SYSVAR` and the environment variables `FLAM4MF_STATIC/DYNAMIC_SYSVAR` documented above. Instead of local filenames, complete URLs defining all communication parameters and (if required) the member name or index can be used. Optionally a CCSID for this file can be added. The syntax is: If the URL-like syntax is used, special characters can be URL-encoded as a percent character followed by two hex digits (%xx). If no schema is provided, but a raw filename, URL-encoded characters are not decoded as the string is not a URL. The schema `file://` can be used to access a local file on the system in URL-like syntax. Currently, remote file access via SSH is supported for all file types including FLAM4 archives. The `ssh://` prefix indicates remote access via SSH. The userid is optional, the default is the current login user ID. You can use replacements also in the connection parameter. I.e. `<cuser>` gets replaced with the lower case login user id, which is useful mainly on mainframes, where the SYSUID is in upper case. The password is optional. If no password is specified, public key authentication is attempted. The hostname/IP is mandatory and the port is optional, defaulting to the SSH standard port 22. The hostname and the remote file path are separated by a slash. An IPv6 address must be put in square brackets (e.g. `[::1]`). An absolute path requires another slash (i.e. // after the hostname). Otherwise, the path is relative to the current directory after login to the SSH server. See examples below: This URL notation is a simplified form of accessing files via SSH. For even more connection options, you can use the `net.ssh()` object which allows, e.g., the configuration of the public/private key file path or different host key check procedures. See the documentation for the `net.ssh()` object for further details. If both, URL notation and `net.ssh()` object, are used to configure the SSH connection, communication parameters specified in the URL have higher priority. So, if a username is given within the URL as well as the through the object, the username from the URL is used. The file for an inverse command cannot be on a remote system. If a remote report, info or log file is specified, the output data written to the remote system is in the local system's character set. When reading user tables, checksum files, password files or other miscellaneous text files, an automatic character conversion to the local character set is performed. When accessing files via SSH from a mainframe system, the remote file is handled like a file from a non-mainframe platform that does not support datasets since SSH file access is block-oriented and not record-oriented. This means that, if record I/O is used, records are written or expected in one of the open formats on the remote system. For example: This statement for the CONV command of FLCL reads a local physical sequential variable block dataset with a logical record length of 133. A pair of 4 byte length field followed by the record data is written to the remote file for each read record. This is because the default mapping of the host record format (`VB`) to a non-host platform is `OPN_VAR`. With version 5.1.21 the file name specification was extended to an array. This make it possible to provide a list of files/URLs in the forms below: In the last case a parameter file containing the list with the URLs can be provided using dynamic or static allocation (DD: only for z/OS). In the case a lot of URLs with several connections can be used. FLAM supports now a connection cache with the result that only the required connections are open. The `NET` overlay provides the default settings for each different URL. In each file specification wildcards are still possible. The feature can be used to combine different files in one archive. ",
"",
""
],
[
"flam4_manual-flam4_utility-directory_support_e9bb.html",
"Directory Support",
"=== Directory Support Multiple input files can be processed at once by using wildcard patterns as input filename and recursion into directories. It is also possible to select only certain members of FLAMFILEs by pattern or index and to specify how directories are traversed. Input file or member names can contain the wildcards below. The wildcards are supported on subprogram level, i.e. wildcards are available in the batch utility and in subprogram calls. Wildcards are not supported on record or byte interface level. If one of the wildcard characters is part of the filename itself, you can escape the wildcard character with the caret (`^`). For MVS datasets each qualifier is separated with a period (`.`). If you want to let the asterisk (`*`) or plus sign (`+`) match more than one qualifier, you must put it twice (i.e. `**` or `++`). On non dataset based systems (UNIX, Windows, USS, Linux) this mechanism is not available as there are no qualifiers in filenames and hence periods are handled like any other character. Below you can find some examples: The directory support for MVS includes Generation Data Groups (GDG). If you want to read only the previous generation of all GDG's under your SYSUID, you must type as follows: Is a wildcard used at read and the different files should be written into a generation data group as several versions. The file index in minimal amount of digest '[ind0]' could be used the define the next generations '(+[ind0])'. The enclosing quotation marks are required because the file name string contains round brackets. Strings without quotation marks are terminated at the first space character or curved or squared bracket. NOTE: If you use a wildcard in the first/high level qualifier, the catalog search interface (CSI) is used to return each dataset in the catalog. All these datasets are then compared against the corresponding pattern. This can consume a lot of time. Be careful with wildcards in the first/high level qualifier at ZOS dataset names. NOTE: Using wildcards at the beginning of a pattern (for example '**(MEMBER)') could result in opening a dataset which is stored on a tape which is not available immediately. This could result in the process waiting for console input. By default, datasets on tapes are not included in the dataset list retrieved by the wildcard mechanism. If you want to include datasets on tapes, then you must enable the corresponding switch. However, this will not prevent a console request. Files in catalog where the volume is not available, will result in the same behavior. Be careful with wildcards at the beginning of the search pattern. The escape character can be used for datasets, but this is not required. If the match string contains parenthesis `()`, only PO datasets are matched. To match GDG, the first character inside the parenthesis must be `+`, `-` or a number. In all other cases, a PO dataset is assumed. Relative generation numbers are currently not supported for PO datasets. To process only certain members inside archives, a match string for members can be used. A member can be defined as part of the URL with `?` as separator. Alternatively, for FLAMFILEs, a dedicated member specification can be used. In this case a leading question mark (`?`) is ignored. For a question mark as first wildcard, specify two of them. You can also select members from archives based on the member index. In this case, the member name must start with a hash (`#`) or colon (`:`) and can contain a list of indexes and/or index ranges (two indices separated by minus (`-`), inclusive) separated by comma. For example: All four variants read the 3rd, 5th, 8th, 9th, 10th and 15th member from files in the current directory that end with '.adc'. To define how wildcard strings are matched, there is an object called 'DIR' that contains some switches. These include recursion into sub-directories, recursion into archives, inclusion of hidden files, symbolic link, etc. See the chapter to the 'DIR' object below for more information. Missing directories are created automatically. To prevent this the switch 'NOMKDAR' must be activated. Overwriting of existing files can be prevented with the 'REMAIN' switch (see below). To convert the file names matched to a certain file name for writing see <<flcl.input.output.name.mapping,INPUT TO OUTPUT NAME MAPPING>>. ",
"",
""
],
[
"flam4_manual-flam4_utility-input_to_output_name_mapping_7f46.html",
"Input to Output Name Mapping",
"[[flcl.input.output.name.mapping]] === Input to Output Name Mapping When creating/extracting an archive, converting files or (more generally) doing batch processing, one might wish to automatically generate new filenames based on a pattern applied to the input filenames. Example: You might want to read a member from a FLAMFILE which was created on a mainframe and contains dataset names. You wish to convert the dataset name into a path-based file name. You can achieve this by defining a pattern for the output file or member name. An output filename pattern can consist of simple text strings and tokens. Text strings are used as-is as output filename. Tokens are enclosed in square brackets (`[]`) and describe processing rules applied to the original file or member name. The pattern can consist of an arbitrary number of text strings and tokens (including none at all). A token can consist of one or more processing rules. Multiple processing rules are separated by a pipe character (`|`). Every processing rule within a token receives the output of the previous rule as its input. This allows chaining of processing rules. Characters inside tokens can be escaped by a preceding caret (`^`) to avoid interpretation as pattern syntax. Outside of tokens, carets are treated literally, except in front of squared brackets to treat a bracket literally and not as token delimiter. The keywords of the tokens below are not case sensitive. This is the list of supported processing rules: * [path]   - Extracts the string before the last slash or backslash, i.e. the path without trailing (back)slash * [name]   - Extracts the part after the last (back)slash, i.e. the filename * [base]   - Extracts the part between the last (back)slash and the last dot, i.e. the filename without extension * [ext]    - Extracts the part after the last dot, i.e. the file extension * [member] - Extracts a string enclosed in round brackets from the filename part of the string, e.g. a PDS member name on z/OS * [copy]   - Simply copies the input string (useful if you only want to add an extension) * [upper]  - Converts all characters to upper case * [lower]  - Converts all characters to lower case * [title]  - Converts the first character to upper case, all others to lower case * [cutX]   - Cuts off the string after the X-th character, where X is a positive or negative number              indicating how many characters to keep, counting from the front (positive) or back (negative) * [indN]   - Inserts the current index as decimal number of at least length N (padded with preceding zeros)              N is any number between 0 and 9, where 0 results in variable length numbers with their shortest              possible representation (no preceding zeros) * [rndN]   - Inserts random numbers of length N (with preceding zeros)              N is any number between 0 and 9, where 0 results in variable length numbers (no preceding zeros) * [AX]     - A is a place holder for a single-byte character, X is a positive or negative number;              Extracts the string part between the X-th occurrence of the specified character and the next              occurrence of that same character. If X is negative, search starts at the back and in reverse.              If X is 0, the part before the first occurrence of A is extracted. * [AX-]    - A is a placeholder for a single-byte character, X is a positive or negative number;              Extracts the string part after the X-th occurrence of the specified character.              If X is negative, search starts at the back and in reverse.              If X is 0, the input string is copied. * [AX-BY]  - A and B are placeholders for a single-byte character, X and Y are positive or negative numbers;              Extracts the string part between the X-th occurrence of A and (relative to that occurrence)              the Y-th occurrence of B. Like above, negative numbers mean counting from the back. * [search=replace]  - Replaces the first occurrence of the string 'search' with the string 'replace' * [search=*replace] - Replaces all occurrences of the string 'search' with the string 'replace' * [regex:/pattern/replace/modifiers] - String replacement with Perl-compatible regular expressions * [table]  - Evaluates to the current table name if end of table handling is activated (only when reading tables) Regular expressions (short: regex) can be used to apply arbitrarily complex matching rules and substitute these matches using the syntax `[regex:/pattern/replace/modifiers]`. They can be chained like any other processing rules using the pipe character, e.g. `[regex:/pattern/replace/modifiers|upper]` The character immediately following the keyword `regex:` is a delimiter to separate the pattern, replacement string and optional modifiers. The delimiter can be any single-byte character that does not occur in the pattern or replacement string and is expected exactly three times. You can also use pairs of brackets as delimiters in which case the matching closing bracket is expected to follow an opening bracket. A few examples using different delimiters, all performing the same replacement: * `[regex:/pattern/replace/modifiers]` * `[regex:#pattern#replace#modifiers]` * `[regex:{pattern}{replace}modifiers]` The pattern and replacement strings must not be escaped with carets (`^`), even though they are inside a token (`[]`). Regular expression patterns in the Perl flavor are matched against the input string to find the substrings that are to be replaced. Writing regular expressions may seem like a daunting task if you never did so before. Understanding the basics is not as complicated as it may seem. You can find a tutorial that will get you started quickly here: + https://www.regular-expressions.info/quickstart.html Countless other tutorials and documentation for regular expressions can be found on the web. We recommend to consult these ressources to familiarize yourself with regular expressions. Advanced users can find the complete syntax documentation for writing regular expression patterns by following this URL: + https://www.pcre.org/current/doc/html/pcre2pattern.html Replacement strings are mostly string literals, except for the dollar character. A dollar character is an escape character that can specify the insertion of characters from capture groups and names from `(*MARK)` or other control verbs in the pattern. In other words, it can be used to insert parts of the match into the replacement string. Capture groups in a regex pattern are sub-expressions in parentheses. These can be accessed by their numerical index starting at 1 (`$1`, `$2`, ...). The capture group accessed by `$0` always references the whole match. Capture groups can also be referenced by name. A named group in a regex pattern uses the syntax `(?<name>subpattern)`. This group can then be referenced in the replacement with `\$\{name}`. Modifiers change the behavior of regular expression matching and/or replacement. Modifiers are optional and must be placed after the final delimiter. Multiple modifiers can be combined. Currently, these modifiers are supported: * `g`: Enables global matching. The regular expression is applied        repeatedly and all matches are replaced. By default, regular        expression matching stops after the first match has been replaced. * `E`: Fail with an error if the regular expression does not produce any        match. By default, the input string remains unchanged if there        is no match. * `R`: Instead of replacing matches in the input string, only the        replacement string is returned. * `i`: Enables case insensitive matching. * `m`: Enables multi-line matching. By default `^` and `$` only match at        the start/end of the entire input string. With multi-line matching,        they also match after/before newlines. Note, however, that unless        the `s` modifier is set, the 'any character' metacharacter (`.`)        does not match at a newline. * `s`: If set, a dot metacharacter in the pattern matches any character,        including one that indicates a newline. However, it only ever        matches one character, even if newlines are coded as CRLF.        By default, a dot does not match at a newline. * `x`: Enables extended matching mode. Most whitespace characters in        the pattern are ignored except when escaped or inside a character        class. Characters between an unescaped `#` outside a character        class and the next newline, inclusive, are also ignored, which        makes it possible to include comments inside complicated patterns. * `n`: Disables numbered capturing groups (inside parentheses) in the        pattern. Any opening parenthesis that is not followed by `?`        behaves as if it were followed by `?:` but named parentheses can        still be used for capturing (and they acquire numbers in the        usual way). The last example shows a wildcard used at read and the different targets should be written into a generation data group as several versions. The file index in minimal amount of digest '[ind0]' could be used to define the next generations '(+[ind0])'. Patterns can be used for output file and member names. This mapping mechanism is very powerful. For example, it can be used to compress each directory into a separate FLAMFILE, with each FLAMFILE containing all files of that directory. If you define an output filename pattern that results in the same path being generated more than once, the second and further occurrences will append the data to previously written files. If no pattern defined, this means that all matching files on input, will be written to one output file or archive, the append flag is automatically enabled starting with the second file. ",
"",
""
],
[
"flam4_manual-flam4_utility-key_label_handling_291f.html",
"Key Label Handling",
"=== Key Label Handling For cryptographic operations (signing, encryption) keys are required. Beside passwords and passphrases FLAM supports professional key management solutions, based on different cryptographic infrastructures and hardware security modules. For example, on z/OS ICSF on other IBM platforms CCA and on distributed platforms PKCS#11 are supported. If a key protected by a shielded hardware module it must be normally referenced by a name called key label. These names or better the convention for these key labels can be different from client to client. To support different key label conventions FLAM supports key label templates. Key label templates using the same replacement mechanismen for environment variables (<ENNVAR>) described in the file name handling above. Only the sepcial characters used as abbrevation are differ. FLAM use hard coded default key label templates for the different encryption solutions. For the OpenPGP support for example: Depending on the application several %x replacments can be supported. These qualifier (%u/%t) are replaced with the corresponding variables. In the OpenPGP example above %u are replaced with the USERID or KEYID and %t are replaced with the internal used key type definition. If you provide as USERID for example '~' or '<SYSUID>' then the current logon name is used a user id. First the %x is replaced by the variable and then the replacement with the defined environemnt variables is done. Below you can see a few examples with an environment id 'T' for TEST and the internal types 'PUBLIC' or 'PRIVATE': The internal type is defined by the application (mainly the used FLAM key management extension version 5 (FKM5)). Over the key template only the position of the internal type can be defined, the value is given by FLAM. The key template handling and limitations (how long, which characters, how many qualifiers also) are depending on the FKM5. The underlying cryptographic infrastructure defines what is possible. For example, a key label in PKCS#11 can be free defined and for ICSF/CCA it must conform to host data set names. Have a look at the FKM5BOOK for these details. Since version 5.1.16, the replacement characters are no longer case sensitive. The two templates below are equivalent This change is making it easier to define such templates in JCL (CAPS ON) on z/OS. ",
"",
""
],
[
"flam4_manual-flam4_utility-password_handling_9a9d.html",
"Password Handling",
"=== Password Handling Several components allow entering passwords, for example to encrypt files or establish SSH connections. Putting such sensitive information inside a script, a JCL or entering it directly on the command line can be serious security issue. Therefore, any string assingment within a command can be sourced out to a file which is much easier protected against prying eyes. The prefix 'f' tells CLE/P that the string must be read from the specified filename. The file itself must contain the CLE/P string value. With SSH you can provide the password as part of the URL: In this case, it may not be very useful to put the whole URL inside a file. Instead, the password can be specified through the corresponding NET object, where the password is a separate parameter. The rest of the connection information can remain in the URL: If you wish, you could also put all connections parameters inside the NET object, so that the URL form is not needed: If a connection parameter is specified in the URL as well a in the SSH NET object, the values from the URL takes precedence. The special replacement capabilities (~) for file names, however, are only available for the URL. In the NET.SSH object only the simple string replacements (<cuser>) can be used. Sometimes it is convenient to use a parameter file for an object, overlay or command which contains the password. All these capabilities can be used to protect passphrases, but we recommend to use public key authentication with SSH and the use of our key management extension (FKME/FKM5) for PGP or FLAMFILEs to protect the keys by professional cryptographic infrastructure (e.g. with a HSM (hardware security module)). ",
"",
""
],
[
"flam4_manual-flam4_utility-handling_of_empty_records_2dea.html",
"Handling of Empty Records",
"[[flcl.handling.empty.records]] === Handling of Empty Records The handling of empty records is complicated on z/OS. FLAM5 uses the language environment (LE) to read and write records. If the environment variable '_EDC_ZERO_RECLEN' is not defined, it defaults to Y(es) for the record I/O operations. When reading, this results in an empty record being converted to a neutral FLAM5 record element. When writing, however, an empty variable length record is not written at all by the LE. To circumvent this, a padding character (default: 0x00) is written for an empty variable length record. To suppress this added padding character when reading the output file later, a record of length 1 with 0x00 or 0x40 will result in an empty record of length 0 if the environment variable '_EDC_ZERO_RECLEN' is set to 'Y'. In any other case, empty variable length records are converted to a record of length 1 containing the padding character by default on z/OS (binary files: 0x00, text files: whitespace character (0x40)). On platforms which support writing empty variable length records, when writing fixed-length records or when print control characters are used, this kind of dirty padding of empty variable length records is not done. ",
"",
""
],
[
"flam4_manual-flam4_utility-handling_of_spanned_records_b7e0.html",
"Handling of Spanned Records",
"[[flcl.handling.spanned.records]] === Handling of Spanned Records Spanned records are supported by FLAM5 components with a record length of up to 1 MiB. This length can be extended on request. The old FLAM4 components do not support such large records. To write large records to the old FLAMFILE, the matrix with the records must be convert to a block with record length fields in order to write this block into a FLAMFILE. The FLAM4 components will handle such a block as an undefined byte stream. When reading, the conversion from block to records must be requested with the same method to restore the original records. With XCNV, block/record formatting or conversion capabilities can be used. The CONV command offers the LARGER switch when reading and writing FLAMFILEs to activate the this type of conversion. When LARGER is used the block conversion is performed with the B4X method. There is currently no automatic approach implemented for it. The following example uses the XCNV command to read a VBS file and write the large records to a FLAMFILE with block formatting. To read the created FLAMFILE back to records and write it as VBS, the job below can be used, using record conversion. The READ/WRITE.FLAM4() objects with the LARGER switch actived will do the same, but without the possibility to change the format of the length field with the METHOD parameter. The FLAM command of FLCL and the new FLAM4 utility will also support the LARGER switch when reading and writing FLAMFILEs. By default, the record length for VS/VBS is 1 MiB. To save memory, this can be reduced with the RECLEN parameter. The FLAM5 I/O will read large V(B)S records by default. This can be deactivated for record I/O by using the switch NOSPAN. This switch is active for the FLAM command of FLCL, or the new FLAM4 utility, if the LARGER switch is not enabled to ensure backwards compatibility. NOTE: Automatic record length detection will not work with large records (>=32768). This requires to set the record formatting method when reading such a FLAMFILE. ",
"",
""
],
[
"flam4_manual-flam4_utility-use_of_ibm_unicode_services_e434.html",
"Use of IBM Unicode Services",
"[[flcl.use.of.unicode.serives]] === Use of IBM Unicode Services Since version 5.1.27, FLAM supports the use of IBM Unicode Services on system Z. The Unicode Services are used only if no user table, transliteration, case mapping, subsets, whitespace handling, reporting, normalization or other complex conversion is requested. If a simple conversion is done, in a few cases the implementation of FLAM is faster and FLAM will still use this faster implementation. In all other cases, the IBM Unicode Services will be used by default to reduce CPU and memory utilization. It is important to note the differences in behavior of the IBM Unicode Services: * If an incomplete character is encountered and the error handling is not   STOP, the FLAM character conversion module ignores or substitutes this   incomplete character. The IBM Unicode Services does return an EINVAL   error in this case. * IBM Unicode Services can produce errors for technically valid code   points when processing UTF-8 encoded data. The FLAM character   conversion module first decodes UTF-8 and verifies the code point   afterwards, independent of the encoding. This means you can encode   code points in multiple forms (e.g. the character 0 as 0x30 or   0xFC80808080B0). The IBM Unicode Services support only the shortest   form (0x30) of an encoding for a code point and all other possible   encodings are not accepted and will result in an error (invalid   character). * Depending on the Unicode Services version (APAR) a BOM character in   the data might remain for UTF character sets or might be replaced by   a substitution character for single byte character sets.   When calling the Unicode Service FLAM will request the BOM removal, and   FLAM will remove a BOM character if it is causing an invalid character   error, but both will not work with certain versions of Unicode Services. * No error is caused by a wrong BOM (invalid character) in the middle of   the data and a BOM change from LE to BE or vice versa is also not detected.   For data with mixed endianness the Unicode Services should be deactivated. To prevent these changes in behavior you must set the system symbol `&FLIBMUS` or the environment variable `FL_IBM_UNICODE_SERVICE` to `OFF`, but this will result in more CPU and memory utilization for simple character conversions (see chapter <<clep.main.usedenv,Used Environment variables>>). The environment variable's default is `AUTO` which ensures that only the minimal behavior changes above are in place. To use the Unicode Services also for character conversion mode `STOP` the environment variable has to be set to `ON`. This will cause FLAM to use the round trip conversion technique of the Unicode Services, which results in the behavior changes below: * A lot of non-convertible characters will be converted to a unique   character in the target character set without an error using the round   trip conversion scheme. * A substitution character is only converted with activated substitution.   Without substitution, the substitution character 0x1A in ASCII/UTF or 0x3F   in EBCDIC will cause an error. Based on that behavior FLAM will request   the substitution if Unicode Services are used. We recommend to set FL_IBM_UNICODE_SERVICE=ON to maximize performance if the limitations described above are acceptable because checking each character if it is valid or not has a significant performance impact. ",
"",
""
],
[
"flam4_manual-flam4_utility-use_of_built_in_functions_cf72.html",
"Use of Built-in Functions",
"=== Use of Built-in Functions The generated description of the built-in functions are independent of the program, owner and command names. This may make it difficult to use them. Below, you can find some examples for the use of built-in functions of FLAM4. All built-in functions not listed here do not require any parameters. On mainframe systems, using built-in functions in JCL looks like: For documentation, help and syntax you can also use the ISPF commands FLDOC, FLHLP and FLSYN under menu 6. ",
"",
""
],
[
"flam4_manual-flam4_utility-security_considerations_8164.html",
"Security Considerations",
"=== Security Considerations Safety is an important issue for FLAM. FLAM can help to fulfill many security requirements (e.g. PCIDSS, ISO27001, ...), using encryption (OpenPGP, SSH), hardware security modules (PKCS#11 and IBM CCA/ICSF for key exchange and signing), strong access control and checksums, antivirus scanning and much more, nevertheless the following points must be observed for the secure operation of FLAM. TODO: With a maintenance contract you can register in the customer portal for a newsletter about security vulnerabilities. This newsletter will be sent if a security vulnerability for FLAM comes up. This is useful in supporting your secure operating center (SOC). In the `install.txt` for your platform under prerequisites you will find the software on which FLAM is based or depends. If nothing is listed, then only the operating system with the language environment and the corresponding libc is affected. In the `about.txt` you can see all the external libraries and their versions that FLAM integrates. Both pieces of information can be used to determine whether the use of FLAM might be affected by an emerging security vulnerability.  With the call `flcl version` a version of each software component is written. The installation of FLAM will be coherent if all build numbers are the same. The build number is the last number of the version behind the minus character. Especially for dynamic linked parts of the software it will be important to check if the installation was well done. We recommend establishing an installation verification process which runs the built-in function `VERSION` and verifies that the build numbers are all the same. limes support code signing for modules and installation packages if it is possible on a platform. If not limes provides secure checksums to allow verification of the packages after download. There are a lot of environment variables or system symbols which are security related. Below you can find some important examples (please note: this list is incomplete): * FL_PGP_PREF_SYMALG_AES128 - Invert order of preferred symmetric algorithms from AES256/192/128 to AES128/192/256 in PGP certificates * FL_ALLOW_LOW_ENTROPY      - If defined and no source of entropy is available, the random number generated is seeded with a low entropy which may result in weak encryption keys * FL_DEACTIVATE_HW_CRYPTO_ACCELERATION - Deactivate hardware acceleration for cryptographic operations (enforce use of software implementation) * FL_SSH_HOME_DIR           - Directory containing SSH key files and known_hosts file (/home/user/.ssh) * FL_KEY_EXPIRE_WARN_DAYS   - Amount of days to warn before a key will expire (default is 90 (3 months)) See <<clep.main.usedenv,Used Environment Variables>> and verify these settings. To get a list of the current environment please use the command below: For operating systems implementing a secure access facility (e.G. z/OS) FLAM supports a lot of policies and additional resources for better control about the usage of FLAM. For more information about this see <<flcl.saf.considerations,SAF Consideration>> and the `install.txt`.  Unfortunately, there is no such additional protection of application-specific resources for other operating systems. With the SAF support it is possible to ensure minimal key, password or hash length. Critical operations like input logging, packet capturing, antivirus scanning etc. can be deactivated and more. There are a lot of policies and resources defined for the supported cryptographic features (PGP, EDC, SSH), which will not be explained below in more details. Credentials (Passwords, PINs, Keys, ...) entered using the CLP strings are flagged as protected and will not be printed in clear form. Such values are replaced by `****** SECRET ******` unless the input logging is activated. In this case the complete command string is written to the log and might contain critical values. After parsing the command line FLAM knows the critical values and is replacing them. Additionally it is better to provide such sensitive input within parameter files. The file can be better protected. But the best solution in such cases is to use a hardware security module (HSMs).  FLAM supports hardware security modules (HSMs) over a service provider interface for session key procedures and signing (PGP, FLAMFILE, ...). Currently, the use of PKCS#11 and IBM CCA (including ICSF) are supported. We recommend using the HSM support instead of clear passwords for key stores or such critical things. The misuse of the service provider interface can be prevented completely with SAF support. All software cryptographic operations are done using a central crypto kernel (CryCore). This singleton determines the optimal implementation depending on the computer used. It supports hardware acceleration if possible. But before the concrete algorithm is used the first time a self test against the NIST test vectors is done, to ensure that the loaded functions do implement the algorithm correctly. For IBM mainframes mainly the CPACF functions are used to implement the cryptographic algorithms. For all other platforms the library libcrypto of the OpenSSL project is used.  To generate keys (mainly for SSH) it is important to have a high entropy. By default, FLAM ensure a high entropy which could result in an error, if only weak randomness is available. The environment variable  `FL_ALLOW_LOW_ENTROPY` allows low entropy to prevent such errors and the policy `LOW.ENTROPY` can be used to prevent this. In some cases the quality of randomness is not so important, in such cases it could be useful to allow low entropy and in another context it will be dangerous, and then it will be better to prevent this. FLAM supports secure delete of sensitive data (keys, passwords, pins). This means that erasing the memory is done as early as possible and the overwriting of the memory will not be eliminated by the optimizer for the release code. FLAM supports antivirus scanning over a service provider interface. It will be required by certain security standards to scan the clear content of a file before it is encrypted and stored on a remote system. In such a case the antivirus scanner can be used. Our standard implementation uses clamAV, but the interface can be implemented against each kind of antivirus scanner. Simultanously, this interface is a backdoor to intercept clear data and should be closed for all other cases. FLAM implements a complete set of SAF control mechanism which can be used to ensure this.  The input logging will write the complete input parameter string to the log (this is not done by default and only important for debugging in a few cases). In this case the content is not known and might contain critical data or credentials. The SAF policy `LOG.INPUT` can be used to prevent the activation of input parameter logging. Packet capturing is useful to find errors for remote connections (e.g. SSH) but packets might contain critical or sensitive data. With the SAF policy `SSH.PCAP.ALLOWED` you can control the usage of the PCAP feature and prevent this kind of backdoor for normal processing. The command pre- and post-processing is a powerful feature of FLAM and can be used in once or per file, locally or remote at read or write. The feature was implemented mainly for process automation but to run commands (often executable code) on remote systems could be dangerous. To prevent misuse FLAM has implemented a set of SAF controls. The FLAM started task (FLMSTC) on z/OS is an active component running in the background providing services to implement the subsystems, including the LE-less interface for the FLUC record interface. The FLAMSTC provides the scheduling of SRBs in another enclave for the zIIP support and the possibility to run authorized functions. This is realized with three different PC routines. The FLAMSTC does not implement own supervisor calls (SVCs). Functions of the FLAM and FLUC subsystems are called as part I/O SVCs. The QA process is using zACS to penetrate the PC routine and the corresponding recovery routines. The only findings of the zACS scan are regular program terminations of the FLAMSTC with 0C4. TODO: sollte nur under eigenen user laufen The error trace is an important feature of FLAM which help a lot to analyze errors. For a good cause determination the data involved in the error is often written to the error trace. This means that the error trace could include parts of sensitive data items. In a case of an error this trace might need protection. It is similar to a dump processing in an error situation. Such a dump could contain critical data and must be protected. limes is using vulnerability scanners and static code analysis for conformance with certain Coding Standards to prevent critical mistakes in our programs. Additional CPPCHECK and ScanBuild are used for static code analyzes. For each platform limes uses the standard memory checker (e.g. valgrind on linux) for dynamic code analysis running over all test cases. But there are a lot of platforms without a tool for runtime analyzes. Therefore, limes has implemented an own resource checker (memory, file handles, stack, ...) in the debug code to detect stack and memory overflows, missing frees(leaks) or unclosed or misused files.  Limes is using Coco(r) to determine the code coverage of FLAM and ensure that each part of the code is tested. Squish(r) is used to automate testing of our GUIs. For automated testing of each ISPF panel and limes command we use the API of the x3270 terminal program. For all testing limes is using an own test framework which runs all the unit and regression tests on all platforms. The cross-reference tests nsures that data produced by standard tools (e.g. gzip, openssl enc, gpg) is understood on each platform and produced output of FLAM from each platform can be read with the standard tools. We use continues integration, this means that all the build tests are running after each build, a rebuild must be successful before the code is taken over from the developer repository to the main repository and all the long-running tests (performance, large files, ...) will be started automatically each night and anything will be checked each morning. This allows us to deliver rolling releases, where a customer can request a new parameter on Wednesday, and we can deploy a new revision or release on Monday. For this each weekend is currently used to clean anything, rebuild anything, tests anything, package anything, install the new package to a clean system, test anything again. And if anything was successful then we can publish the new build for our users. Sometimes it takes long to get all tests to run with success, and we cannot release a new version each week. All regression tests must be successful before we publish a new version of FLAM. The publishing include an encrypted code escrow for the complete source used to build this release. All build results, all test results anything will be stored in an archive for this publication. So we can review the complete state if a customer has a problem with a certain build including all tests results, all compile and link lists and so on. We can install from this repository easily each published build, to set up the customer environment to reproduce an error or a behavior. limes is using a mixture of SCRUM and team concert with strict coding guidelines where requirement, design, development, build, test, packaging, installation, testing again and the deployment runs in parallel. Version control is done with GIT and anything is integrated in an eclipse workspace under Arch Linux for our developer. The software development process ensures that all described QA measures are adhered to. The documentation is generated from the source code and based on that it must be totally in sync with the application and components used. The quality of the description for a parameter or the manual page for an object or overlay could be bad, but any implemented feature is documented and vice versa. We use the FLAMCLEP command string parser and anything what this compiler is accepting is defined in tables and the help message and the manual page must be provided otherwise a table error occurs. The same method is used for interface specifications (API), where each function and each parameter for each function must be documented in form of comments in the code otherwise the docu generation will fail. This process ensures that the documentation is always up-to-date and in sync with the implementation and the user can trust that anything is documented. ",
"",
""
],
[
"flam4_manual-flam4_utility-performance_considerations_fc32.html",
"Performance Considerations",
"=== Performance Considerations Performance (CPU/memory utilization and throughput) is an important topic when using FLAM. The following points describe some major factors that contribute to the overall performance of FLAM. They should give you a good starting point if you experience performance issues. In order to minimize consumed CPU cycles during mass data processing, FLAM pre-calculates as much as possible before processing any data, which requires memory on the one hand and spends some CPU time on the other. If you process many small files with FLAM, this can have a negative effect on performance. FLAM is not designed and developed to process small amounts of data. FLAM uses special instructions of the respective hardware platforms to be able to accelerate some algorithms. On IBM's mainframes, for example, this concerns the use of CPACF and zEDC. For IBM mainframe systems, it is possible to outsource memory-to-memory functions (compression, conversion, formatting) as SRBs to so-called zIIP processors. Although this does not result in a performance advantage, it does save chargeable CPU time (MSU). FLAM processes data in self-sufficient segments, which represent a block or a certain number of records. The amount of data that is processed in one go determines the throughput performance. It is important to understand that there is an overhead per segment, so the segments should not be too small. However, if too much data is put into a segment, then the processing constantly takes place outside the caches, which also reduces the performance. Here, the block size or the record count must be optimally selected for the respective platform. For historical reasons, FLAM works with a default block size of 64 KiB and a record count of 512. This is a good average value across all platforms, but not always optimal. It should also be noted that such a segment is expanded after decompression, i.e. in this case one should always start with a smaller block size. On many systems, 256 KiB is now a good block size. The optimal record count is the optimal block size divided by the average record length. Character set conversion can take up a lot of CPU time. By default, FLAM checks each character for validity and stops processing with an error if invalid or unconvertible characters are found (MODE=STOP). This form of error handling is relatively expensive in terms of CPU utilization, but ensures detection of incorrectly encoded text data. Enabling error handling that leads to the replacement of these incorrect characters, processing can be accelerated. The character set conversion is faster if all characters of the input alphabet result in data of the same length in the output alphabet. With the environment variable `FL_DEFAULT_CHAR_MODE` (or the system variable `&FLCHARM` on z/OS), the default mode for error handling during character set conversion can be changed from `STOP` to `SUBSTITUTE`, for example, in order to achieve higher performance here. On z/OS, FLAM uses the IBM Unicode Services as long as it supports the required character set conversion and is known to be faster than FLAM's implementation. This only works for simple conversions without mappings, subsets, reporting or transliterations. The environment variable `FL_IBM_UNICODE_SERVICE` (or the system variable `&FLIBMUS`) can be used to enable/disable the use of IBM Unicode Services. By setting the variable to ON instead of the default AUTO, the IBM Unicode Services will also be used if STOP is selected as the character conversion mode, which saves a lot of CPU cycles, but at the cost of no longer noticing some errors in the character data. FLAM writes many log messages by default, which also takes up CPU time and I/O. The `QUIET` or `SILENT` keywords and the `MESSAGE` object can be used to control the amount of output and thus limit or increase the amount of work involved. Often, during the transition from test to production, people forget to reduce FLAM's chattiness, which cost both disk space and CPU cycles in production. FLAM uses a global literal cache to save memory and CPU when comparing strings. Here a hashtable is used. Its size can be defined via the environment variable `FL_LITERAL_CACHE_SIZE` (or system variable `&FLITCS`). In the debug log, the appropriate statistics are output, which may help you to make adjustments if necessary. When creating ZIP archives, offsets and statistics values must eventually be written into the member headers, which requires repositioning (fseek()) within the file. This is possible for host datasets on z/OS via so-called RBA access. In a PS-VB file, this requires a tree in the background where the OS remembers which relative byte address (RBA) is in which block, in which records at which offset in the record. This is extremely time-consuming and if there are many members in the ZIP archive, this can increase the runtime considerably. The maintenance of this tree also costs a lot of CPU, which is not charged to the application. To avoid this, you should use file types for ZIP archives that are suitable for RBA access. Under z/OS, these are primarily never files in the USS. Alternatively, FLAM also supports streamed ZIP archives, as they were developed for piping under Unix systems. With the keyword `STREAM`, you can force a purely sequential write, which then also works with a PS-VB, but you should check whether ZIP tool used for extraction understands this streamed format. With PS-FB datasets, the RBA access is faster because you do not need a tree, but there is padding at the end of the ZIP file. Since ZIP archives have to be read from behind, many other tools cannot cope with this padding because they expect the ZIP directory and not 0 bytes or blanks. With FLAM this is not a problem, but as already mentioned, many other tools then recognize the ZIP file as incomplete or not even as a ZIP file. For memory allocation, don't use the realloc control feature of CEE. FLAM is only tested with default settings. With some memory allocation strategies out of memory errors can occur. For good performance and enough memory we recommend the IBM default runtime options except for run CEEOPTS below: With `ALL31(OFF)` and `HEAP(,,BELOW,,)` the available memory is too small for the stack in some cases, especially when using the FLUC subsystem, table or large-record support. Since version 5.1.25, FLAM uses application-specific run-time option defaults with the `CEEUOPT` assembly language source program to set these application-specific option defaults. The `CEEUOPT3` member used for 31 bit and the `CEEUOPT6` member used for 64 bits are located in hlq.FLAM.SRCLIB. We recommend building and linking the examples if you are going to write applications that use our APIs (e.g. FLCREC). For batch processing we recommend to create a storage report (RPTSTG(ON)) and define the CEEOPTS like recommended in the report. ",
"",
""
],
[
"flam4_manual-flam4_utility-jcl_considerations_3437.html",
"JCL Considerations",
"=== JCL Considerations If you use JCL to run FLCL batch programs, it is recommended to use the parameter file feature for inlining commands. Parameter files can also be used for each object and overlay (see example below): The parameter files (DD:PARM, DD:ZIPARCH) are read by the command line parser and executer (CLE/P). This works only in the expected manner if NUMBER=OFF is specified for this job in the ISPF editor. With NUMBER=ON, the numbering is part of the inline code and will result in a syntax error from the CLE/P. The same is valid for the DD name STDENV. In a parameter file, you can add a semicolon at the end of each line to handle the line number as comment. Since version 5.1.20-23372: On command level if no parameter given and no parameter file assigned, then the DD name 'FLAMPAR' is read. See the example below: To execute our commands we recommend the stack and heap definitions for the memory management of the language environment below (the IBM defaults are in comment above). If for example the increments to low (128 bytes), then the run and CPU time could increase significantly. Please use the storage report (above as comment) to determine the best values for your usage. With does a lot of work depending on the parameter given. It could possible depending on what is done with FLAM that better values increase performance and lower CPU utilization. With ALL31(OFF) and HEAP(,,BELOW,,) the available memory is too small for the stack in some cases, especially when using the FLUC subsystem, table or large-record support. Since version 5.1.25, FLAM uses application-specific run-time option defaults with the CEEUOPT assembly language source program to set these application-specific option defaults. The CEEUOPT3 member used for 31 bits and the CEEUOPT6 member used for 64 bits are located in hlq.FLAM.SRCLIB. We recommend to build and link the examples if you are going to write application that uses our APIs (e.g. FLCREC). To interpret commands correctly, some of the punctuation characters are on different code points depending on the EBCDIC CCSID used to enter these values. The environment variable LANG must be set to the correct CCSID to interpret tilde and other characters correctly. see <<CLEP.MAIN.EBCDIC,Special EBCDIC code page support>> of <<clep.main,Command Line Processor>> Since z/OS 2.1, a new service (CEEGTJS) is available to determine the values for exported JCL symbols in the application. The service is called dynamically and the language environment must be in the steplib concatenation to use it. If the service is not available, the exported JCL symbols cannot be used. If the environment variable replacement fails the exported JCL symbols are tried. This feature allows you to use exported JCL symbols in the control statements of FLCL like environment variables. This is mainly useful to build powerful JCL procedures. The environment variables have a higher priority. If there is an environment variable with the same name as an exported JCL symbol, the value of the environment variable is used. System variables available as JCL symbols (if SYSSYM=ALLOW is specified in the class definition) can be exported and used in the control statements. Since version 5.1.17 of FLAM, the system symbols are generally available for replacment (e.g '...<&LDAY>...') if no environment variable with the same name exists. This means that the system symbols have the lowest priority in the replacement process. To export all JCL symbols for an application, you can use 'SYMLIST=*'. The '&name.' replacment of JESS (DD *,SYMBOLS=JCLxxxx) can also be utilized if inline coding is used. For an external parameter file, however, the JCL symbols are only available with '<name>'. ",
"",
""
],
[
"flam4_manual-flam4_utility-saf_consideration_7b95.html",
"SAF Consideration",
"[[flcl.saf.considerations]] === SAF Consideration Beginning with version 5.1.21 a lot of additional checks against a System authorization facility (SAF) can be activated. These SAF support gives for example an RACF administrator on z/OS the possibility to activate different security policies and control a lot of resources used by FLAM. * Several security policies (disable PCAP, ensure finger prints, minimal key length, ...) * CLE/P parameter strings (complete control about the functionality) * Control access to pre- and post-processing commands (executed on remote or local systems) * To secure all service provider interfaces (FAVE, FCPE, FKME) ** Control to which AV daemon the clear data is transfered * Control access to complete URLs containing connection, path, filename and member ** Allow to protect members of PDS/E, ZIP or FLAM archives * Secure SSH connections (Control user, server and port) * PGP key management (User ID to import, export, generate, delete) * Control access to PGP user and key IDs for signing and key exchange * Control methods, algorithms, modes and a lot more of the en/decryption component * Activate and enforce additional SMF logging (e.g. record type 119 (SSH)) * All feature codes of the FLAM license module The complete SAF setup is documented in the corresponding install.txt and can be simply extended on user request. For z/OS with RACF we recommend at minimum the definitions below (be careful with this example, we are no RACF specialists): First (in step 1 and 2) the general resource class $FLAM must be setup. The last step defines the rights for the certain entities. The recommendation defines all the policies and enable anti virus scanning only with the defined ClamAV daemon (DSN must be adjusted). The entities for command execution or parameter string can include whitespace or one of the other 4 invalid characters '(),;'. If such an invalid character is encountered in an entity string, it is replaced by an underscore '_' before the SAF check. For example the PDS(E) 'HLQ.PO(HUGO)' results in the resource name 'FIOURL.HLQ.PO_HUGO_'. The global pre-write pre-processing command 'ls -l' results in the resource name 'CMD.PRE.WRITE.GLOBAL.ls_-l'. ",
"",
""
],
[
"flam4_manual-flam4_utility-flam4_synopsis_7207.html",
"FLAM4 Synopsis",
"=== FLAM4 Synopsis The synopsis collects the help, syntax and other important information for a program, function or parameter. It is a kind of quick reference and will used over the complete hierarchies in this document. Below you can find for example the synopsis for program FLAM4. ",
"",
""
],
[
"flam4_manual-flam4_utility-syntax_of_flam4_d437.html",
"Syntax of FLAM4",
"=== Syntax of FLAM4 Below you can see the main syntax for this program. This content is printed on the screen if the built-in function <<CLEP.BUILTIN.SYNTAX,SYNTAX>> is used. Each command can be entered as an argument list on the command line or in a parameter file. To define a parameter file the assignment character (`=`) must be used. For an argument list a blank or if the command (main table) is of type overlay a dot (`.`) or if the command is of type object a round bracket open (`(`) must be given. If the round bracket open is used then the corresponding round bracket close (`)`) at the end of the command is mandatory. The dot and parenthesis are in accordance with the normal syntax. If an argument list is used all parameters (argv[]) are concatenated to one long string and this string is passed to the parser, to allow usage of all features of the shell to build the command line input. To make sure that anything you enter is passed one by one to the parser please use double (WINDOWS(R), UNIX) or single (z/OS(R)) quotation marks at the beginning and end of the argument list. If the dot for overlays or parenthesis for objects are used then the complete command must be included in double quotation marks. The examples below show all possible command entries for the type object: For a command of type overlay it looks like: In a parameter file you can start with a dot for an overlay or with parenthesis for an object or with the argument (overlay) or argument list (object) directly. ",
"",
""
],
[
"flam4_manual-flam4_utility-help_for_flam4_96b1.html",
"Help for FLAM4",
"=== Help for FLAM4 Here you can see the static main help for this program. This content is printed on the screen if the built-in function <<CLEP.BUILTIN.HELP,HELP>> is used without any further arguments. ",
"",
""
],
[
"flam4_manual-flam4_commands_a0ac.html",
"FLAM4 Commands",
"== FLAM4 Commands Commands are used to run powerful subprograms. The command line processor compiles a table defined syntax in a corresponding preinitialized data structure. This structure will be mapped to the parameter structure of the corresponding subprogram. The subprogram can be executed with the defined arguments/parameters. To support these variable commands several built-in functions are available and described in a separate <<CLEP.BUILTIN.FUNCTIONS,chapter>>. Each supported command is explained in a separate section in this document. Each section contains a synopsis including the help message, the path, the type and the syntax followed by a detailed description. If an argument of this command is an object or overlay or, if a detailed description is available for this argument, a separate section with synopsis (help, path, type, syntax) and description is written,  otherwise a bullet list is printed which contains the keyword, the syntax and the help message. For the syntax of an overlay braces `{}` are used to keep all possible arguments of an overlay logically together. These braces are not part of the real syntax. The braces are only written to demonstrate clearly that one of these arguments must be selected with the DOT operator (optional) for defining the overlay. To be compatible with certain shells, the features below are implemented: * Strings can be enclosed with single '' or double '' quotation marks * Integrated strings (without spaces) can also defined without quotes * Keywords can also start with '-' or '--' in front of the qualifier * If it unique then parenthesis and the dot can be omit for object and overlays Commands can be declared in deep hierarchical depth. In order to simplify their handling the path is a powerful instrument for managing only relevant parts of it. Because of that the path is printed for each synopsis. To run commands under different owners, the owner id can be defined in front of the command. To suppress the outputs of the command line executer you can set QUIET or SILENT as the last parameter. Additional to QUIET, SILENT suppressed also the error messages. These options has no effect of the outputs of the commands and built-in functions. For job control, the maximum (and minimum) condition code (MAXCC=[max][-min]) of the command execution can optionally be set as the last parameter for each command. The value 'max' is the maximum condition code. If the condition code, that would be returned if MAXCC was not specified, would be greater than 'max', it is reduced to the value of 'max'. If the condition code would be smaller than 'min', the actually returned condition code is reduced to 0. Both, 'max' and 'min', values are optional. To only specify the minimum, simply omit the 'max' value, i.e. the MAXCC value starts with a hyphen. Example: The clause `MAXCC=8-4` will set each condition code greater than 8 to 8 and each condition code smaller than 4 to 0, while `MAXCC=-4` only sets condition codes smaller than 4 to 0. The parameter for each command can be provided as argument list on the command line or as parameter file. ",
"",
""
],
[
"flam4_manual-flam4_commands-info_b5eb.html",
"INFO",
"[[CLEP.COMMAND.INFO]] === INFO indexterm:[Command, INFO, INFO] The INFO command provides further information about local or remote files, CCSIDs among others. To use CONV and other commands it is sometimes useful to know which CCSIDs are supported or which members are in a FLAMFILE or how the file attributes are named. The system information (environment, default values, hardware support) may be helpful information to diagnose errors. To get syntax information, please use: To get help for a parameter, please use: To read the manual page for a parameter, please use: To generate the user manual for a command, please use: Parameters can be defined by the command line (directly or per file) or by properties read from the corresponding property file. * `NUMBER: FMT=LIST/XML - Specify formatting of information [LIST]` ** `LIST - Provide information as list` ** `XML - Provide information in XML-structure` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-net_184b.html",
"NET",
"[[CLEP.COMMAND.INFO.NET]] ==== NET indexterm:[Overlay, NET, INFO.NET] With the overlay NET you can choose the protocol for the remote read access. Below, you can find the currently supported protocols and the corresponding parameters explained in a dedicated chapter. This feature requires a FLIES server. ",
"",
""
],
[
"flam4_manual-flam4_commands-info-net-ssh_ed72.html",
"SSH",
"[[CLEP.COMMAND.INFO.NET.SSH]] ==== SSH indexterm:[Object, SSH, INFO.NET.SSH] The SSH method provides secure remote file access through the SSH file transfer protocol (SFTP). Due to the transport encryption of the SSH protocol, the transferred data is safe from eavesdroppers even if the data itself is unencrypted. The remote host only needs a running SSH server (e.g. OpenSSH). FLAM can read and write most locally supported types of files also via SSH, including the use of wildcards and recursion into directories. Only FLAMFILEs (work in progress) and record-oriented host datasets are currently not supported via SSH (limitation of the SSH server). Authentication methods supported are password and public key authentication. There are two ways of specifying authentication parameters: via the NET-SSH object or the file URL. The file URL may contain the SSH username, the password (is using password authentication), hostname and port. The NET-SSH object also allows to specify the paths of the known hosts, public and private key files as well as the private key password (if applicable) when using password authentication. Parameters specified in the file URL always take precedence over parameters set via the NET-SSH object. To successfully establish an SSH connection, at least a hostname/IP is required. Other options can be specified or can be loaded from a OpenSSH config file. By default, options are loaded from the per-user (~/.ssh/config) and system-wide (/etc/ssh/ssh_config) OpenSSH config files, if they exist. To disable loading those default config files, use the NODEFAULTCONFIG switch. A custom OpenSSH configuration file can be set with the CONFIGFILE option. SSH configuration options are priorized in the following order: Example: The known_hosts file path is set via net.ssh(knownhosts=...) and in one of the config files with the UserKnownHostsFile keyword. Since the options specified in the command string has higher priority, it is used. Below is an (incomplete) list of keywords of the most important keywords that are supported in SSH config files. They follow the OpenSSH syntax. Please refer to OpenSSH's documentation for a description: * Ciphers * Compression * ConnectTimeout * GlobalKnownHostsFile * Host * HostKeyAlgorithms * Hostname * IdentityFile * Include * KexAlgorithms * MACs * Match * Port * ProxyCommand * RekeyLimit * StrictHostKeyChecking * User * UserKnownHostsFile The port defaults to 22 and the username defaults to the local username unless specified in the command or one of the loaded config files. If a password is specified, authentication via password is attempted. For public key authentication, the paths to a public and/or private key file can be specified (via the net.ssh() object). A private key is mandatory. There are three cases:   this keypair is performed   by appending the extension .pub to the private key file path. If no   such file exists, the public key is extracted from the private key.   This has a security implication: If the server rejects the public key   for authentication, the private key was decrypted unnecessarily. If   the public key is stored in a separate file, the private key would   remain encrypted in the case of public key rejection by the server.   with only a public key. If the public key filename ends with .pub,   this extension is stripped to build the private key filename. If no   such file exists or the public key filename suffix is not .pub,   authentication will fail. If neither a password nor a public/private key file are specified, public key authentication in automatic mode is attempted. First, authentication via an SSH agent (e.g. from OpenSSH) is attempted if one is running and the environment variable SSH_AUTH_SOCK is set to the socket path of the SSH agent. If authentication via SSH agent fails, the keys defined in ~/.ssh/config and /etc/ssh/ssh_config are tried (keyword: IdentityFile) if present. If that fails as well, a series of default keys of the local user account is used (stored in ~/.ssh/id_*, e.g. id_ed25519, id_ecdsa, id_rsa, id_dsa). When establishing a connection, a known host check is performed to prevent an attacker from performing a man-in-the-middle attack and impersonate the destination host. For this purpose, the per-user known_hosts file (~/.ssh/known_hosts) and the system-wide file (/etc/ssh/ssh_known_hosts) are used by default. A different per-user known_hosts file can be specified with the KNOWNHOSTS option. A known_hosts consists of one line per previously seen host, each containing the hostname (or hash), key type and public key of the host. Establishing a connection will fail by default (strict hostkey checking) if the host is not in the known_hosts file or if the public key presented by the server during connection establishment does not match the key in known_hosts file. FLAM is designed to run without human interaction. Therefore, by default, connecting fails if no known_hosts entry is found. To connect to a host you have never connected to before, a known_hosts entry can be added manually. FLAM can also add the missing host entry for you to the per-user known_hosts. This, however, requires to activate interactive mode (hostkeycheck=ask). When you connect to a new host in interactive mode, the fingerprint of the remote host is displayed. You should verify that the fingerprint is correct (to avoid adding a key from a man-in-the-middle attacker that might have control over the communication path to the server) and confirm the key to have it added to your known hosts file. There are more hostkey check mechanisms implemented and described in a <<CLEP.COMMAND.INFO.NET.SSH.HOSTKEYCHECK,dedicated chapter>>. The parameter VERBOSITY (or VERBOSE) activates connection debug logging (CONDBG) in the log output. There are several levels of verbosity to control the amount of logged messages. The SYSTEM level logs some details about the connection (e.g. negotiated algorithms). Levels other than SYSTEM additonally log messages from the SSH library (libssh). Examples: Establish a connection to an SSH host for the first time by trying to read a dummy file (does not necessarily have to exist) in interactive mode: Read a file 'myfile.bin' from the home directory of a remote host using the default username (either from config file or the local username) in different but equivalent ways by using default public key authentication: Read a file with password authentication and a custom username: Read from an absolute path: Read and write from/to different remote hosts, one with public key, the other with password authentication and a non-default port: Get information for all text files in a remote home directory with several connection debug information and specification of the known host file: * `STRING: HOST/SERVER/DAEMON='str' - Hostname/IP` * `NUMBER: PORT/SERVICE=num - Port number [22]` * `STRING: USER='str' - User name [optional]` * `STRING: PASSWORD='str' - Password [optional]` * `STRING: CONFIGFILE='str' - Custom config file to load (OpenSSH format) [none]` * `SWITCH: NODEFAULTCONFIG - Don't automatically load default config files (~/.ssh/config & /etc/ssh/config) [OFF]` * `STRING: KNOWNHOSTS='str' - Known host file [system]` * `STRING: PUBKEYFILE='str' - Public key file [system]` * `STRING: PRIKEYFILE='str' - Private key file [system]` * `STRING: PWDKEYFILE='str' - Password for key file [none]` * `STRING: PCAPFILE='str' - File path for (unencrypted) packet capture) [disabled]` * `NUMBER: VERBOSITY/VERBOSE=SYSTEM/INFO/PROTOCOL/PACKET/FUNCTION/ALL - Logging verbosity of SSH connection [NONE]` ** `SYSTEM - Log connection info (enables CONDBG log type)` ** `INFO - Log informational messages of libssh` ** `PROTOCOL - Log high level protocol information of libssh` ** `PACKET - Log lower level protocol information (packet level of libssh)` ** `FUNCTION - Log every function path of libssh` ** `ALL - Log all messages of libssh` * `NUMBER: TIMEOUT=num - Timeout for SSH connection in seconds [30]` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-net-ssh-hostkeycheck_7804.html",
"HOSTKEYCHECK",
"[[CLEP.COMMAND.INFO.NET.SSH.HOSTKEYCHECK]] ==== HOSTKEYCHECK indexterm:[Parameter, HOSTKEYCHECK, INFO.NET.SSH.HOSTKEYCHECK] When an SSH client connects to an SSH server, the server identifies itself by sending its public key. It is an essential part of the security of SSH that the client must validate the server's public key to make sure that it belongs to the intended (trusted) host and not to an eavesdropper / man-in-the-middle. The file in <HOME>/.ssh/known_hosts is used to store combinations of trusted hosts and their public keys. Entries to this file can be added manually or can be added when establishing a connection for the first time. In any case, you should have verified the host keys you add belong to the indended party. The known hosts file format is identical and fully compatible to the known_hosts format of OpenSSH. The HOSTKEYCHECK selection is used to specify how strict the host key sent by the server is verified to decide whether to continue connecting and whether to add the key to the known_hosts file. Here are the available options in descending order of security: * `<Fingerprint>` - You can specify a specific fingerprint that must   match the public key sent by the server. If it does not, the connection   is terminated. If the key is not in the known hosts file, it is added.   Hence, this mode is also suitable to add a host key to the known_hosts   file upon first connection to a host in an environment where you cannot   manually verify the host key (e.g. in a batch job), but without accepting   any (potentially untrusted) arbitrary key.   The fingerprint is a hexadecimal MD5 checksum of the   host's public key with bytes separated by colons (e.g.   00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff). It is always printed   to the log (INFO level) when connecting. * `STRICT` - The host key sent by the server must match one of the keys   that are stored in the known_hosts file for this host. Otherwise, the   connection is terminated, which includes new/unknown hosts. * `ASK` - Like STRICT, but prints an interactive prompt when connecting   to a server for the first time and offers to add the known_hosts entry   after you confirm the key's authenticity. * `WARN` - Connecting will continue even if the server sends an unknown   host key. If no matching known_hosts entry exists, a warning is printed   to the log about the connection being potentially compromised. * `ACCEPTANY` - Like WARN, but additionally adds the host key to the   known_hosts file if no such entry exists. Hence, you explicitly trust   any key that the server sends which also extends to future connections   in STRICT mode. WARNING: Don't use host key check levels below ASK unless you know what you are doing. By allowing arbitrary host keys, your connections can be intercepted easily. * `STRICT - Verify host key against known_hosts, abort if not present or on host key mismatch` * `ASK - Like STRICT, but asks when the key is not present (interactive)` * `WARN - Prints a warning when there is no matching entry in known_hosts file, but continues (unsafe)` * `ACCEPTANY - Accepts any host key and adds it to known_hosts if not present (unsafe)` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-net-ssh-algorithms_bc11.html",
"ALGORITHMS",
"[[CLEP.COMMAND.INFO.NET.SSH.ALGORITHMS]] ==== ALGORITHMS indexterm:[Object, ALGORITHMS, INFO.NET.SSH.ALGORITHMS] SSH clients and servers support various cryptographic algorithms to secure an SSH connection. In the handshake phase at the beginning of each SSH connection, both parties negotiate the algorithms that will be used for this connection. For this purpose, client and server exchange multiple lists of their respective supported algorithms for each type of algorithm. The algorithm lists are sent in order of preference. In other words, putting an algorithm at the beginning of the list is a suggestion to the other party to prefer this algorithm over others. Algorithms that do not appear in the list cannot be negotiated. The `algos` object can be used to specify custom lists of acceptable / preferred algorithms. Each list is a comma-separated string of one or more of the supported algorithms. Unsupported algorithms are silently ignored. Algorithm lists specified via `algos` object override those specified in any SSH config file. NOTE: The handshake will fail if none of the specified algorithms is supported by the server. Preferences for the following algorithm types can be customized: * KEX: The key exchange algorithms you want to use to negotiate the secret session key * HOSTKEYS: Acceptable host key algorithms for the server's public key in order of preference * CIPHERS: The cipher algorithms allowed for data encryption in order of preference; can be specified separately for each transmission direction * COMPRESSION: The compression algorithms allowed (or 'none'); can be specified separately for each transmission direction * HMAC: The HMAC algorithms allowed for integrity protection; can be specified separately for each transmission direction To get a list of algorithms supported by the libssh library (shipped with FLAM), connect to any existing SSH server with verbose logging enabled (`net.ssh(verbosity=all)`) and without specifying the `algos` object. (For example: `flcl info 'get.file=ssh://example.com/anypath net.ssh(verbosity=all)'`) Look for a line containing 'Changing host key method to' to find the default algorithm lists (which might already be modified by your SSH configuration files). The relevant log output looks similar to this: There is another list in the log containing the algorithms supported by the server. For some algorithms, HW-accelerated cipher and hash functions are used, reducing CPU utilization for cryptographic operations considerably. On IBM Z hardware, the appropriate CPACF Message Security Assist (MSA) extensions must be available and enabled. The supported MSA version determines which algorithms are implemented in hardware. This is detected automatically during SSH connection establishment. The appropriate implementation is used by default to accelerate data encryption with AES as well as HMAC computation based on MD5, SHA-1 and SHA-2. On other platforms, the hardware accleration implementation of OpenSSL is used transparently. * `STRING: KEX='str' - Preferred key exchange algorithms (comma-separated)` * `STRING: HOSTKEYS='str' - Acceptable hostkey algorithms (comma-separated)` * `STRING: CIPHERS_CS='str' - Preferred cipher algorithms client-to-server (comma-separated)` * `STRING: CIPHERS_SC='str' - Preferred cipher algorithms server-to-client (comma-separated)` * `STRING: COMPRESS_CS='str' - Preferred compression algorithms client-to-server (comma-separated)` * `STRING: COMPRESS_SC='str' - Preferred compression algorithms server-to-client (comma-separated)` * `STRING: HMAC_CS='str' - Preferred HMAC algorithms client-to-server (comma-separated)` * `STRING: HMAC_SC='str' - Preferred HMAC algorithms server-to-client (comma-separated)` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-get_a81c.html",
"GET",
"[[CLEP.COMMAND.INFO.GET]] ==== GET indexterm:[Overlay, GET, INFO.GET] With the overlay GET you can choose which information will be printed. * `SWITCH: SYSTEM - List system information` * `SWITCH: CCSIDS - List of supported CCSIDs` * `SWITCH: ENCODINGS - List of all encodings` * `STRING: FILE='str'/STREAM/DUMMY - Information about a file (flam4/gzip/xz/bzip2/pgp/zip...)` ** `STREAM - Read from stdin or write to stdout` ** `DUMMY - Read EOF or write nothing` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-get-fkme_cf9c.html",
"FKME",
"[[CLEP.COMMAND.INFO.GET.FKME]] ==== FKME indexterm:[Object, FKME, INFO.GET.FKME] Through the object FKME you can define the library and function of an FKME module to get information, help and documentation of the corresponding FLAM Key Management Extension. By default, the 'libfkme' of FLAM is used. If no function name is specified, all known entries of this library are used. This works only for 'libfkme' as we do not know the function names for other libraries. The function codes for help and documentation might not be implemented by other FKMEs, i.e. these switches are mainly useful with the 'libfkme' from limes datentechnik. To get FKME info for load modules on mainframes, which must be fetched from STEPLIB, you must type a * for the library name. * `STRING: LIBRARY='str' - Library name [libfkme]` * `STRING: FUNCTION='str' - Function name (entry)` * `SWITCH: HELP - Get help message` * `SWITCH: DOCU - Get documentation` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-get-fkm5_1f4c.html",
"FKM5",
"[[CLEP.COMMAND.INFO.GET.FKM5]] ==== FKM5 indexterm:[Object, FKM5, INFO.GET.FKM5] Through the object FKM5 you can define the library and function of an FKM5 module to get information, help and documentation of the corresponding FLAM Key Management Extension v5. By default, the 'libfkm5' of FLAM is used. If no function name is specified, all known entries of this library are used. This works only for 'libfkm5' as we do not know the function names for other libraries. The function codes for help and documentation might not be implemented by other FKM5s, i.e. these switches are mainly useful with the 'libfkm5' from limes datentechnik. To get FKM5 info for load modules on mainframes, which must be fetched from STEPLIB, you must type a * for the library name. * `STRING: LIBRARY='str' - Library name [libfkme]` * `STRING: FUNCTION='str' - Function name (entry)` * `SWITCH: HELP - Get help message` * `SWITCH: DOCU - Get documentation` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-get-usagelog_b8ca.html",
"USAGELOG",
"[[CLEP.COMMAND.INFO.GET.USAGELOG]] ==== USAGELOG indexterm:[Object, USAGELOG, INFO.GET.USAGELOG] Through the object USAGELOG you can specify the start and end dates as well as other parameters for FLAM usage reporting. If no parameters are specified, the log stream name (only on mainframes) and the SYSLOG identifier (which is used for usage logging) are printed. If an end date is specified, then a summary about FLAM usage is generated. You can also specify start and end date lists (arrays) to calculate usage summaries for these time intervals. For example, it can be useful to evaluate the FLAM usage on system peak hours. These reports are useful to determine CPU usage that can be offloaded to co-processors and accelerators. Additionally, it provides the amount of bytes processed by FLAM. * `NUMBER: FROM=num/OLDEST - Indicates the starting time of the first record to be processed [OLDEST]` ** `OLDEST - From oldest entry` * `NUMBER: TO=num/YOUNGEST - Indicates the ending time of the last record to be processed [no report]` ** `YOUNGEST - To youngest entry` * `SWITCH: LOCAL - Specifies the time is local time [GMT]` * `SWITCH: SHORT - Print short report [FALSE]` * `SWITCH: JOBNAME - Add job names to list [FALSE] (only relevant for z/OS)` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-out_6984.html",
"OUT",
"[[CLEP.COMMAND.INFO.OUT]] ==== OUT indexterm:[Parameter, OUT, INFO.OUT] With the OUT parameter you can choose the file (as STRING) or stream (STDOUT/STDERR) where the information is printed. If it not provided the log is used by default. * `STDOUT - Write output to stdout` * `STDERR - Write output to stderr` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-dir_2917.html",
"DIR",
"[[CLEP.COMMAND.INFO.DIR]] ==== DIR indexterm:[Object, DIR, INFO.DIR] This object defines multiple switches that control how input files are found. This is especially important when using wildcards in input filenames. There are switches to enable recursion into subdirectories, following symbolic links, finding hidden files, recursion into archive files, include files on tapes, resolving aliases and enforcing to not leave the filesystem. If the `recursive` flag is set, the filename portion of the input file string is searched for recursively. If a directory path containing wildcards is present, the filename portion is searched for recursively in all paths that match the directory path pattern, e.g. '*/path/*.txt' matches my/path/hugo.txt, another/path/hugo.txt as well as my/path/subdir/hugo.txt. Without the recursive flag, the last file would not be found. If the `archive` switch is enabled, FLAMFILES, TARBALLS, ZIP files and other kinds of supported archives are searched. All the matching members are extracted. In other words, archives are interpreted like subdirectories if the flag is enabled. If the `tape` switch is enabled, then datasets stored on tapes or if migrated (if VOLSER = 'MIGRAT' or 'ARCIVE' on z/OS) files are searched. If the name of such a file matches the pattern, then it might occur that console input and a manual intervention is required to retrieve the respective dataset(s). A special behavior was implemented for z/OS for files on DASD, where a SVC27(OBTAIN) is issued for nonVSAM data sets (normal PS/PO). To collect also files if the SVC27 failed the obtain switch must be set. Normally this will result in a warning and completion code 4. If the obtain switch is not defined, files without a corresponding control blocks are skipped. If the `link` switch is enabled, symbolic links are followed (otherwise they are ignored). Links are mainly supported on modern file systems. For dataset aliases on mainframe systems, see the alias flag. With the `alias` switch enabled, datasets names which are aliases of the real dataset are resolved to their actual names (otherwise they are ignored). Dataset aliases only exist on mainframe systems. This flag has no effect on other platforms. If a transparent read method (e.g. read.auto()) is used, then the `archive` flag is enabled by default and cannot be disabled. * `SWITCH: LINK - Include symbolic links` * `SWITCH: ALIAS - Resolve data set aliases` * `SWITCH: HIDDEN - Include hidden files` * `SWITCH: RECURSIVE - Include sub directories` * `SWITCH: ARCHIVE - Include archives (FLAMFILEs, ZIP, ...)` * `SWITCH: ONEFILESYSTEM - Don't cross file system boundaries` * `SWITCH: TAPE - Include files deposited on tapes (or if migrated or archived)` * `SWITCH: OBTAIN - Obtain control blocks if DSAD (z/OS only, warning if SVC27 failed)` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-log_cde2.html",
"LOG",
"[[CLEP.COMMAND.INFO.LOG]] ==== LOG indexterm:[Object, LOG, INFO.LOG] The LOG parameter allows flexible adjustment for the logging of messages. It is possible to specify the destination as well as which kind of message will be written. ",
"",
""
],
[
"flam4_manual-flam4_commands-info-log-message_a712.html",
"MESSAGE",
"[[CLEP.COMMAND.INFO.LOG.MESSAGE]] ==== MESSAGE indexterm:[Object, MESSAGE, INFO.LOG.MESSAGE] The log message specification is a classification of the messages to write to the selected log destination. Each type is selectable individually by adding its argument inside this object. For added convenience, the special types NON, ALL, MINIMAL select the proper message types with just one argument. If no message specification is given, a DEFAULT is used which writes out messages of these types: * ERROR * ERRTRACE * WARNING * NOTICE * PARAMETER * STATISTICS * INFO * LICID * SUMMARY * OUTPUT * SOURCE * TARGET * `SWITCH: NONE - No messages will be logged` * `SWITCH: ERROR - Error messages will be logged` * `SWITCH: ERRTRACE - Error trace will be logged` * `SWITCH: WARNING - Warnings will be logged` * `SWITCH: NOTICE - Notices will be logged` * `SWITCH: DEBUG - Debug information will be logged` * `SWITCH: ABOUT - About information will be logged` * `SWITCH: VERSION - Version information will be logged` * `SWITCH: INPUT - Input data will be logged (dangerous for passwords)` * `SWITCH: PARAMETER - Parsed parameters will be logged` * `SWITCH: STATISTICS - Statistics will be logged` * `SWITCH: SUMMARY - Summary will be logged` * `SWITCH: INFO - Requested information will be logged` * `SWITCH: LICID - License ID will be logged` * `SWITCH: LICENSE - License summary will be logged` * `SWITCH: PROGRESS - Progress bar will be logged` * `SWITCH: OUTPUT - Output values will be logged` * `SWITCH: USAGE - Usage reporting will be logged` * `SWITCH: CONDBG - Debug information for remote connections` * `SWITCH: SOURCE - List final physical source names at read` * `SWITCH: TARGET - List final physical target names at write` * `SWITCH: STDOUT - Standard output from third-party application` * `SWITCH: STDERR - Standard error output from third-party application` * `SWITCH: MATCH - Match count will be logged` * `SWITCH: REPLACE - Replacement count will be logged` * `SWITCH: ALL - All messages are logged` * `SWITCH: DEFAULT - Relevant messages are logged` * `SWITCH: MINIMAL - Only important messages are logged` * `SWITCH: ERRONLY - Only errors and error trace are logged` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-log-destination_ec01.html",
"DESTINATION",
"[[CLEP.COMMAND.INFO.LOG.DESTINATION]] ==== DESTINATION indexterm:[Overlay, DESTINATION, INFO.LOG.DESTINATION] Each log message starts with the current time and date. All the possible destinations allow to specify a custom identification string which will be printed after time and date of each message. This is done with the IDENT argument. If no IDENT specified the default will be 'owner.program.command' If no log destination defined stream will be used as default. ",
"",
""
],
[
"flam4_manual-flam4_commands-info-log-destination-stream_4c1e.html",
"STREAM",
"[[CLEP.COMMAND.INFO.LOG.DESTINATION.STREAM]] ==== STREAM indexterm:[Object, STREAM, INFO.LOG.DESTINATION.STREAM] The STREAM object allows the log messages to be written to the standard output or the standard error output. Standard error output is used if STDOUT is not specified. NOTE: The FLAM log output is written to STDERR. It can be written to a       file with `log=FILE NAME` or `2>FILE NAME`. * `STRING: IDENT='str' - Identifier used to identify log entries [owner]` * `NUMBER: FORMAT=STANDARD/DIALOG/MINIMAL - Format of log message [STANDARD]` ** `STANDARD - Standard logging format (timestamp ident *level* message)` ** `DIALOG - For dialog processing (ident *level* message)` ** `MINIMAL - For output processing (message)` * `SWITCH: STDOUT - Log messages to STDOUT instead of STDERR` ",
"",
""
],
[
"flam4_manual-flam4_commands-info-log-destination-file_a138.html",
"FILE",
"[[CLEP.COMMAND.INFO.LOG.DESTINATION.FILE]] ==== FILE indexterm:[Object, FILE, INFO.LOG.DESTINATION.FILE] The flat file option allows the log messages to be written to a normal file. The name of the file must be specified for this destination. The log messages will be appended to this file if it already exists. For the log file, all rules and replacements are valid which are described under 'FILENAME HANDLING' above. For example: NOTE: Parallel process cannot share the same log file. * `STRING: IDENT='str' - Identifier used to identify log entries [owner]` * `NUMBER: FORMAT=STANDARD/DIALOG/MINIMAL - Format of log message [STANDARD]` ** `STANDARD - Standard logging format (timestamp ident *level* message)` ** `DIALOG - For dialog processing (ident *level* message)` ** `MINIMAL - For output processing (message)` * `STRING: NAME='str' - Filename for appending log messages` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam_3de3.html",
"FLAM",
"[[CLEP.COMMAND.FLAM]] === FLAM indexterm:[Command, FLAM, FLAM] The FLAM command can be used to compress or decompress individual files or groups of files either interactively or by means of procedures. The compress or decompress parameter specifies which operation is to be performed. All the information necessary to execute the command can be specified in the form of inputs made directly on the command line, in a parameter file or as installation-specific default values. The FLAM command is backward-compatible with the FLAM4 utility and designed to work with FLAM4 archives, also called FLAMFILEs. There are a few differences to the old FLAM4 utility: * Completion/Condition codes are defined by CLE/P ** Return code 0, 4 and 8 have the same meaning (OK, WARNING, ERROR) ** Higher return codes are different and correspond to more critical issues ** There are also completion codes between 0 and 4 or 4 and 8, for example 1 if a warning in the log (can be deactivated) ** Special condition codes (>64) are the same ** Please use the built-in function 'ERRORS' or refer to the appendix 'Return Codes' for more information ** The main difference in completion codes are: *** DMS errors result in a return code of 8 and not 12 with FLAM5 *** If directory walk (wildcards) fail for all files FLAM5 returns 8 instead of 4 (it returns 4 like FLAM4 if not all files processed successfully) * The log output is in FLAM5 syntax and looks different to the old FLAM4 utilities but is now the same on each platform * The default value file is replaced by the FLAM5 property management (and much more intelligent default behavior) * The default behavior differs a little bit and if required the property management must be used to adjust it * If squared, curly brackets or other operators are required, the parameters must be enclosed in quotation marks ** This was minimized as much as possible to be compatible with the old syntax * If keywords used insaide a string value in a parameter assignment the string must enclose in quotation marks ** IDDN=FLAMDD will result in a syntax error, because FLAMDD is a valid keyword and CLP try to assign the value of FLAMDD ** IDDN='FLAMDD' will work because 'FLAMDD' is interpreted a string value * The selection of members to read from a FLAMFILE is now made via the member definition of the FLAMIN parameter ** As part of the URL: FLAMIN='FLAM.FILE.ADC/?HUGO.PDS(*)' ** Or by the new parameter MEMBER: MEMBER='HUGO.PDS(*)' ** Instead of: FLAMOUT=<HUGO.PDS(*)> * The file name mapping (selection and replacement rules) is different and works like documented below (see INPUT TO OUTPUT NAME MAPPING) * No support of VSAM-LDS as FLAMIN or FLAMOUT (original data) on z/OS (not supported by LE) * The new FL5 system header is not supported by the old FLAM4 components ** VSAM data sets archived with FLAM4 can be reproduced with FLAM5 but not vice versa ** Sizes of original files are only known by FLAM5 (FLAM4 uses hard-coded defaults for primary (2/4MiB) and secondary space (40/50(MiB))) * Recreation of archived PDS load libraries is not yet supported within FLAM5 ** FLAM4 archived PDS load libraries and can be recreated ** FLAM4 does not support this for PDSEs ** FLAM5 does not support it at all till the XMIT support will be available * FLAM5 uses the CEE runtime environment (LE) and FLAM4 works LE-less on z/OS, which may result in different behavior ** Writing KSDS with new key position and length with FLAM5 results in re-ordered records and in a FIOPUT error on FLAM4 if reordering is required ** Empty records are really empty records (length=0) with FLAM4, with FLAM5 (LE) a empty record is written as one padding byte (see <<flcl.handling.empty.records,Handling of Empty Records>>)  * FLAM4 recognizes some errors only after an open of an output file, which may result in an empty file ** FLAM5 detects a lot of such errors before opening to avoid creation of empty files * FLAM5 recognizes from the combination of specified parameters whether compression or decompression is requested ** FLIMIN FLAMFILE (=COMP) and FLAMFILE FLAMOUT (=DECO) ** On z/OS, COMPRESS or DECOMPRESS must be specified for FLAM4 ** On Unix and Windows DECOMPRESS is the default for FLAM4 * The print control character handling is more intelligent in FLAM5 ** To be backward compatible: +    In the case you set a certain record format without print control character    and the original file contains print control character you must define OPRNCTR=RETAIN    to ensure the print control character as part of the record like in FLAM4.    If this new parameter not defined to RETAIN the print control character is not part of the record in this case. ** The provided record length in FLAM5 don't include the print control character (is one byte shorter then in FLAM4) * The default padding character is in FLAM4 always x'40' and in FLAM5 x'40' only used if text (ASA/MCC or CCSID defined) else it is x'00' * With FLAM4 for undefined files the record length must be provided by the caller, FLAM5 use the block size instead * The LIST switch on Windows will be the same as HELP. To get the current default values (properties) the built-in function GETPROP must be used. * FLAM4 on z/OS often requires upper case. FLAM5 syntax is not case sensitive,i.e. lower case can often be used * Given IRECFM and IRECSIZE are override by FLAM4 if the file is cataloged, FLAM5 try to allocate and open the file with the given parameter ** This result sometimes in errors with FLAM5 because the read file don't match with the given parameter (file attributes in conflict) ** Sometimes the runtime environment converts the data to the requested record format (original is VBA and requested is VB) * The FLAM4 UserIO is no longer supported for original data (`IDEVICE=USER` and `ODEVICE=USER` is ignored) * FLAM4 don't support large files (`DSNTYPE=LARGE`) at dynamic allocation, a corresponding data class must be used in this case ** FLAM5 supports large files by default if the amount of required tracks above the limit ** With version 5.1.22 the FLAM4 components set the DSNTYPE too large if more than 64K tracks allocated ** Only FLAM5 supports since version 5.1.22 extended attribute datasets (up to 16 TiB) * FLAM4 works with hard-coded defaults for space allocation (primary 2/4MiB secondary 40/50MiB) ** FLAM5 determines the file size and allocates depending on the space used by the original file by default ** This does not work for multi-volume datasets, in this case only the space used of the first volume will be allocated ** If you write a PO and you will extend this dataset later it is recommended to provide custom space values * FLAM5 supports also the default DD name 'FLAMOUT' at compress if 'FLAMFILE' not allocated and the same for 'FLAMIN' at read If the FLAM command is specified with the 'list' parameter, a list of the currently active settings of the default values is displayed; they can be modified by the system manager using the '-defaults' parameter. The FLAM command permits a separate FLAMFILE to be created from each original file (this requires input name mapping, which is differs to FLAM4). It is also possible to compress a group of original files into one FLAMFILE. The input files which are to be (de)compressed can either be specified by their fully qualified name or by patterns with wildcards. Output filenames can be explicit or generated by substitution rules. When decompressing, by default a file is to be restored with its original name and attributes. With the exception of the '-list' and '-defaults' parameters, there are equivalent FLAM parameters for all the elements of the command syntax, so that each setting can be entered either directly in the command line or in a parameter file which is referred to in the command by the parameter parfile=parameter file. Using a parameter file permits complicated keyboard inputs to be avoided, for example if settings which differ from the installed default values are required frequently. The following features are supported: * Different kinds of remote access protocols (SSH) * Different kinds of data sources (Files, Streams, Tables) * Different kinds of I/O methods (Binary, Character, Text, Record, FLAM) * Different compression modes (ADC, CX7, CX8, VR8 and NDC) * Different encryption modes (AES and FLAMENC) * Powerful character conversion based on CCSIDs If the FLAM command is not sufficient, you can use the CONV command which supports FLAMFILEs and other compression formats and provide various conversion and formatting modes. FLAM and CONV parameter are not identical. To get syntax information, please use: To get help for a parameter, please use: To read the manual page for a parameter, please use: To generate the user manual for the command, please use: Parameters can be defined via command line (directly or through a parameter file) or via properties taken from the corresponding property file. For the FLAM4 utility the command name 'flam' is default and can be omitted. The FLCL utility has no default command, in this case the command name 'FLAM' must be defined. Reads file in record format stream (usual text), compresses with default compression mode ADC, writes FLAMFILE. Reads and decompresses FLAMFILE, writes output file in record format stream. * `SWITCH: NORUN - Don't run the command only show parsed parameter` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-netinp_0940.html",
"NETINP",
"[[CLEP.COMMAND.FLAM.NETINP]] ==== NETINP indexterm:[Overlay, NETINP, FLAM.NETINP] With the overlay NET you can choose the protocol for the remote read or write access. Below, you can find the currently supported protocols and the corresponding parameters explained in a dedicated chapter. This feature requires a FLIES server. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-compress_4734.html",
"COMPRESS",
"[[CLEP.COMMAND.FLAM.COMPRESS]] ==== COMPRESS indexterm:[Parameter, COMPRESS, FLAM.COMPRESS] This parameter activates data compression. FLAM compresses the standardized data formats with a typical compression rate of 4:1. The compression rate can be as high as 95% (20:1). FLAM does not need any additional specification about data to be compressed. The compression method is independent from file, record, and field formats. As FLAM compresses a file, it will write the result into a sequential or index sequential file, the FLAMFILE. This file may have a header that will store information about the original file. FLAM is able to process all PS, PO and VSAM files. It is possible to compress a number of files into one or a number of FLAMFILEs. To adapt the compression process to the requirements of the user, it is possible to specify parameters during the program call. It is also possible to define the parameters using a parameter file or while generating the system. FLAM creates a job protocol for each execution (on screen or into a log file). During compression, FLAM processes a set of 1-4095 (logical) records within one block (Matrix). FLAM can process input and output from both disc and magnetic tape or cartridge. This is also true for the compressed file, the FLAMFILE. FLAM always compresses a set of records in one step. The size of the intermediate buffer can be specified via the parameter MAXBUFFER. FLAM will read only as many input records in one step as can be stored within the intermediate buffer. For compatibility reasons to all FLAM versions, the size of the intermediate buffer is restricted to 32 KiB. However, if the target computer (i.e., the computer on which the compressed file will be decompressed) is known and the FLAM version installed on this computer allows for it, a bigger buffer size for optimal compression can be defined. It is also possible to restrict the number of records within one set using the MAXRECORDS parameter. If you define MAXRECORDS=1, FLAM will use a serial context free compression method that is only useful with long records. The typical compression ratios are usually achieved with 16-32 records within one set. With a bigger set, a slightly better compression ratio can be achieved (which also leads to less CPU utilization!), but the intermediate buffer has to be bigger. The better the compression ratio is, the less CPU time is needed ! It is possible to generate all compressed data in EBCDIC and ASCII code. Compressed records can be created in both fixed and variable format. The compression method is always the same - based on the Frankenstein-Limes-Access-Method. Only the treatment of the matrix columns and the representation of the compressed files differs from case to case. This is controlled with the MODE parameter. Compression mode ADC is introduced as default value. That means, that when the MODE parameter is omitted, MODE=ADC is used. With MODE=CX8, FLAM will only compress repeating characters (horizontally and vertically). With MODE=VR8, the remaining data is compressed in addition using the FL-B(4) code. This process first translates the characters into a special 8-bit code and then homogenizes them using specially designed logical operations. The results are bit strings that can be compressed efficiently. In both cases, the compressed file, the FLAMFILE, is a sequence of 8-bit combinations that are written into sequential or index sequential files. Record size, record format, block size can be defined by the user. Each record of a file is protected with a checksum. Code conversions within the FLAMFILE are not allowed. During transmission, the file has to be treated as a binary file. Compression modes CX7, CX8 or VR8 are processed by zIIP processors when a free zIIP processor is found. This decreases CPU utilization and leads to cost savings. It is done automatically without any parameter. For files that contain only printable characters and shall be transmitted using a 7-bit-line, FLAM offers MODE=CX7. This mode creates a compressed file which will 'behave' during transmission in the same way as the uncompressed file. FLAM does not check, if the original file is suitable for transmission, but will create a compressed file using a very restricted character set that is neutral to the different code conversion utilities on the marketplace. Using this mode, FLAM can create compressed files that can be converted from EBCDIC to ASCII and vice versa (e.g., during a file transfer). However, it is necessary that the code conversion is reversible without any changes. Otherwise, FLAM will signal a syntax error in the compressed file due to differences in the byte numbers and will stop decompression. Such cases are possible if the original file contains printer control characters or tabulator characters, which are not converted 1:1. Apart from this, code conversion can be performed integrated with the compression step. FLAM offers the possibility of code conversion (before compression, or after decompression). Code conversion is controlled via standard code tables or user defined code tables. For special cases where a 1:1 code conversion is not possible for all characters, user exits are provided. Syntax restrictions for FLAMv4 or older: * z/OS ** `COMPRESS` ** `C` * UNIX ** `-compress` * WINDOWS ** `compress` *Values* * No values *Default* * z/OS ** `COMPRESS` * UNIX/WINOWS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-decompress_7d27.html",
"DECOMPRESS",
"[[CLEP.COMMAND.FLAM.DECOMPRESS]] ==== DECOMPRESS indexterm:[Parameter, DECOMPRESS, FLAM.DECOMPRESS] This parameter activates data decompression. FLAM decompresses lossless data from a compressed file (FLAMFILE) into a target file (FLAMOUT). A FLAMFILE can be converted during decompression into any file or record format as specified by the user on any system. FLAM reads a compressed file, decompresses the content and writes the result into an output file. During decompression the characteristic parameters of the original files are normally restored depending on the information in the file header of the FLAMFILE. To adapt the decompression process to special requirements of the user, it is possible to specify several parameters used in decompression process (e.g. passsword usage against unauthorized access, transformation of file format, code and file name conversion, etc.). FLAM automatically configures itself the output file and output data according to file header of the FLAMFILE used during compression and possibly specified decompression parameters (e.g., buffer size or record set size ). That the FLAMFILE eventually was created in a different environment (e.g. different operating system) lacks influence on the decompression operation of FLAM. Data are decompressed into equivalent file or in user defined file formats. To be even more flexible, FLAM provides user exits that allow the user to apply user defined post data processing. FLAM creates a job protocol for each execution (on screen or into a log file). Syntax restrictions for FLAMv4 or older: * z/OS ** `DECOMPRESS` ** `D` * UNIX ** `-decompres` * WINDOWS ** `decompess` *Values* * No values *Default* * z/OS ** `COMPRESS` +    Specification is required for DECOMPRESS, otherwise malfunction. * UNIX/WINOWS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-remain_45a4.html",
"REMAIN",
"[[CLEP.COMMAND.FLAM.REMAIN]] ==== REMAIN indexterm:[Parameter, REMAIN, FLAM.REMAIN] Existing files are overwritten in compression and decompression process by default.The REMAIN switch has to be defined to prevent this. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-append_1e60.html",
"APPEND",
"[[CLEP.COMMAND.FLAM.APPEND]] ==== APPEND indexterm:[Parameter, APPEND, FLAM.APPEND] The data is appended to an existing file. If the file does not exist, it will be created. This feature is not allowed for secure FLAMFILES and was only supported till FLAM3 for Windows. With FLAM5 it is only implemented for z/OS. Syntax restrictions for FLAMv4 or older: * WIN ** `append` (for output files till FLAM3) ** `add` (for FLAMFILEs till FLAM3) * z/OS ** `append` (for FLAMFILE and FLAMOUT with FLAM5) ** `add` (for FLAMFILE and FLAMOUT with FLAM5) *Values* * none *Default* * none *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-flamfile_d9ea.html",
"FLAMFILE",
"[[CLEP.COMMAND.FLAM.FLAMFILE]] ==== FLAMFILE indexterm:[Parameter, FLAMFILE, FLAM.FLAMFILE] Filename for FLAMFILE with compressed (or uncompressed) data. During <<CLEP.COMMAND.FLAM.COMPRESS,compression>>, compressed data is written into the specified FLAMFILE. During <<CLEP.COMMAND.FLAM.DECOMPRESS,decompression>>, compressed data is read from specified FLAMFILE and is stored uncompressed. The parameter `FLAMFILE` can be used together with parameter <<CLEP.COMMAND.FLAM.MEMBER,MEMBER>>. In case of compression, the input filename is renamed to the string in parameter 'MEMBER' and is stored as member name in the FLAMFILE. In case of decompression, the member in the FLAMFILE is renamed to the string in parameter 'MEMBER' and is stored with this name as output file. NOTE: Selection and conversion rules using pointed brackets '<>' in parameter `FLAMFILE` are dropped in FLAM5 and cannot be used anymore. So, the rules described in in the FLAM4 Manual are deprecated. The new rules are explained in the section <<flcl.input.output.name.mapping,Input to Output Name Mapping>> and apply to the parameter FLAMFILE. The old FLAM4 syntax must be migrated in this case.  Instead of using pointed brackets '<>' use of URL syntax is possible now and is a substitute for using the parameter FLAMFILE and <<CLEP.COMMAND.FLAM.MEMBER,MEMBER>>. Example: `FLAMFILE=flamfile.adc/?newifile.txt` In the case of compression, the input file specified as FLAMIN is written to the FLAMFILE `flamfile.adc` as `newifile.txt` (stored as member in the FLAMFILE). Syntax restrictions for FLAMv4 or older: * z/OS ** `FLAMFILE=filename` ** `FL=filename` ** `*DUMMY` * UNIX / WINDOWS ** `-flamfile=file specification` *Values* * z/OS ** Filename with max. 54 characters. ** > Filename with max. 53 characters of file containing file list. ** URL syntax, e.g. flamfile.adc/?inputfile.txt * UNIX ** file specification *** Note:With compression, file specification specifies a specific          file or a list of files separated by commas. A substitution          rule is also permitted.          With decompression, file specification specifies a specific          file, a pattern (with wildcards * or ?), or a list of such          elements separated by commas. * WINDOWS ** -file specification *Default* * no name *Valid for* * compression * decompression Specifying a filename is an alternative to assigning the file by means of a DD statement. The specification can contain a conversion rule for filenames. The name can be specified in wildcard syntax for decompression. The character `>` in front of the filename means that the flamfile contains a list of filenames to be decompressed. `DUMMY` acts like the DD-statement `//.. DD DUMMY` In principle, FLAM is able to process all filenames via JCL valid in z/OS. FLAM stores the name of the compressed file into the FLAMFILE, if required. To avoid any conflicts with national character sets or naming conventions in other systems, all filenames stored in ASCII character set are translated for message and selection in the following way: All national characters are translated to 'X', a backslash '\\' to slash '/', and whitespace ' ' to underline '_'. So it is easier to enter foreign filenames that are unsupported in the z/OS environment. The filename itself remains unchanged in the FLAMFILE.  Entering `DUMMY` as a filename causes FLAM to use this file as dummy like the JCL command `//ddname DD DUMMY`. I.e. reading an input file leads to EOF (end of file), writing to an output file has no effect. So, DD-statements are not necessary for DUMMY files. By prefixing the '>' character (greater than) to the filename or DD-NAME, the FLAM parameters `FLAMIN` and `IDDN` are able to specify a list of files for compression instead of one single file. It is also possible to specify a file list for decompression by means of the `FLAMFILE` or `FLAMDD` parameter. In this list, each filename must be contained in a separate record; leading or trailing space characters (X'40') are ignored. A comment can be inserted after the first space character following the filename. Empty records or records with an asterisk '*' in the first column are regarded as comment lines. All filenames usable in z/OS are legal. Wildcard syntax is allowed. *Example:* If the records in the file USER.DAT.LIST contain the following filenames: the specification leads to all the files specified being compressed into one FLAMFILE (group file). The file that contains the list of filenames can have any format supported by FLAM and be of any type. For 'in-stream files', i.e. input files temporarily created by JES, it is advisable to assign the filenames by means of DD names: This allows the filename list to be specified directly in the job. Filenames can be specified in FLAM by means of parameters written with wildcard syntax. Correspondingly, the entry `FLAMIN=USER.*.DATA.%BC` leads to the compression of all files with the 1st qualifier USER, any 2nd qualifier, DATA as the third part of their name, and a three-digit 4th qualifier which ends with BC and begins with any character. The asterisk '*' stands for any (even an empty) character string. The percent character '%' stands for any character. These special characters are also allowed within members of one or more PO libraries: specifies all members of the library USER.POLIB, that begin with FL; specifies all members whose 4-digit names begin with A and end with B and whose libraries have the identification USER, LIB as their final qualifier, and D as the last character of the second to the last part of their name. All input files are stored in this way in one compressed file (group file). Correspondingly, the wildcard entry in the selection rule for decompression leads to the decompression of only those items of compressed data whose original names conform to the syntax specified. (Comment: this procedure requires a FLAM file header (`HEADER=YES`) and the file information `FILEINFO=YES`) for compression). *Example:* All files with names that conforming to the FLAMIN specification are to be compressed into the file USER.DAT.CMP. If the files are catalogued, the 1st file does not conform to the wildcard syntax and is ignored during compression. If is now specified for decompression, only the files `USER.DATCB.CLIB` and `USER.DATCB.DLIB` will be decompressed. Correspondingly, it is also possible to select a number of FLAMFILEs for decompression: means all FLAMFILEs with the identification USER, CMP as their 2nd qualifier, any character string as the 3rd part of their name and VR8 as their last qualifier are to be decompressed. If the input specification contains more than one element, the following rules regarding syntax and assignment to the FLAMFILE specifications must be obeyed. The input specification may consist of a file or directory name, a pattern (with wildcards), or a list of such elements. Elements of a list are separated by commas. Filenames may contain space characters, but not as first characters. Filnames containing spaces must be enclosed in double quotes. The files specified as input files must actually exist. At least one matching file must exist for a pattern. Otherwise, the `flam` command will be aborted and an error message output. If the input specification specifies files for processing by FLAM, either the `-flamin` parameter or `-flamfile` must be specified for the compression or decompression procedure respectively. If the data is to be entered via the special stdin file, the parameter for the input specification is omitted. FLAM can thus be used as a filter. If the flam command contains several different input and output specifications, they are assigned to one another. The assignment determines where the compressed data of each original file and the decompressed data of each compressed file is saved. The input and output specifications are assigned to one another by means of their positions in the lists. The first input specification is assigned to the first output specification and the second input specification to the second output specification, etc. If there are more input specifications than output specifications, the excess input specifications are assigned to the final output specification. If there are too many output specifications, the excess ones are ignored. If the output specification is a file specification, all the outputs which result from processing the assigned input files are saved in this file. The file attributes must be compatible. If the output specification is a substitution rule, a separate FLAMFILE, which is named according to this rule, is created during the compression procedure for each of the assigned input files. During the decompression procedure, the substitution rule is applied to the names of the FLAMFILEs and not to the names of the compressed original files, i.e. each FLAMFILE results in a separate decompressed file. If a FLAMFILE which contains the compressed data of several different files is assigned an output file, all the compressed data in this FLAMFILE is decompressed into the output file. The output specification [] or [`*`] is then necessary in order to create separate files again. In this case, each compressed block is decompressed into a file with the original name. In the example below, the flam command contains a list of input specifications and a list of output specifications. The list of input specifications contains four entries, namely the output specifications, two substitution rules and a file specification. In accordance with the assignment rules, a file with the same name and a .cmp extension is created for each file which has a .dat extension, and the compressed data of all the files with a .txt extension is saved in a single FLAMFILE called text.arc. The compressed data of `func1.hlp` is saved in func1xyz on  account of the substitution rule contained in the final output specification. Since there are no further output specifications, this rule is also applied to func2.hlp, i.e. a FLAMFILE called `func2xyz` is created for its compressed data. It should be noted that text.arc can only be decompressed into separate files if `-attributes=all` is specified for the compression procedure, so that the names of all the original files are included in the FLAMFILE. Either of the output  specifications  []  or  [`*`]  can  be used for the decompression procedure, to ensure that the files are decompressed separately and given their original names again. If an output file were to be specified, a single file would result, in which all the records of the original files would be concatenated. If the output specification contains more than one file, the following rules described with regard to the syntax and the assignment to the FLAMFILE specifications must be observed. The output specification may consist of a filename, a list of filenames (separated by commas), or a substitution rule. A substitution rule has the following format: [string1=string2]. Moreover, one of the output specifications [ ], [`*`], or [filename] may be used (see description below). Output files are created if they do not exist and overwritten if they do. If a substitution rule is defined as an output specification, the name of the FLAMFILE or the decompressed file must be formed by substituting string2 for string1 in the name of the input file. The strings and the equal sign must have no separating spaces in between. The substitution rule applies only to file names and not to path names. *Example:* causes the files called helptxt1.txt and helptxt2.txt to be compressed and the compressed data to be saved in the associated FLAMFILEs called helptxt1.cmp and helptxt2.cmp. The substitution rule must be applicable to all the assigned input files, i.e. string1 must be contained in the names of every one of these files, or the flam command will be aborted for the file to which it does not apply and an error message will be output. Only one substitution takes place when the name of the output file is formed, even if string1 occurs more than once in the name of the input file. The output specifications [file name], [ ], and [`*`] have special meanings. Using [file name] as output specification causes the decompression to select one or  when file name contains wildcards-, possibly several, matching file(s) from  a FLAMFILE archive. Those are decompressed into the current directory unless -outpath=... directs otherwise. If the output specification for the decompression procedure is [*], the names of the decompressed files are derived from the FLAMFILE, provided the FLAMFILE actually contains them. If not, an error message is output. -attributes=all must be specified for the compression procedure, in order to include the names of the original files in the FLAMFILE. If the output specification is [], the effect is similar to the output specification [`*`], i.e. the names of the decompressed files are derived from the FLAMFILE(s), except that only the file name is taken into account. The path name is ignored. All the files are thus created in the current directory if no -outpath specification is given. Once again, -attributes=all must have been set for the compression procedure. The output specifications [file name], [], and [`*`] must not be part of a list of output specifications, i.e. they must stand alone. If the output specification specifies files for processing by FLAM, either the -flamfile parameter or -flamout must be specified  for the compression or decompression procedure respectively. If the data is to be output to the special file stdout, the parameter for the output specification must be omitted. FLAM can thus be used as a filter.  man_flam4_assignintooutspec.txt * `STREAM - Read from stdin or write to stdout` * `DUMMY - Read EOF or write nothing` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-member_24ca.html",
"MEMBER",
"[[CLEP.COMMAND.FLAM.MEMBER]] ==== MEMBER indexterm:[Parameter, MEMBER, FLAM.MEMBER] String, contains name or index of a member in the FLAMFILE. If a compress process receives a string in the MEMBER parameter, the selected input file is stored with the specified MEMBER name in the FLAMFILE. If a decompress process receives a string in the MEMBER parameter, the decompressed file in the FLAMFILE is stored with the specified string content from the MEMBER parameter as output filename. The parameter MEMBER is used together with parameter <<CLEP.COMMAND.FLAM.FLAMFILE,FLAMFILE>>. Syntax restrictions for FLAMv4 or older: * `MEMBER=string` * `MEM=string` *Values* * string of up to 8 bytes *Default* *  none (no string) *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-flamin_12f3.html",
"FLAMIN",
"[[CLEP.COMMAND.FLAM.FLAMIN]] ==== FLAMIN indexterm:[Parameter, FLAMIN, FLAM.FLAMIN] This parameter specifies the files to be compressed. This parameter defines the default name for the input file during the compression procedure. The input specification is a file specification. It must name a single file uniquely an may not contain patterns (wildcards). Note that when a default name is defined, stdin and pipelines can no longer be used for flamin. With `flamin=none`, the default value for this parameter is dropped. Syntax restrictions for FLAMv4 or older: * z/OS ** `FLAMIN=filename` ** `FLAMI=filename` * UNIX ** `-flamin=input specification` * WINDOWS ** `flamin='name of original files'` *Values* * z/OS ** Filename with max. 54 characters * > Filename with max. 53 characters ** `*DUMMY` * UNIX ** -input specification +     The input specification specifies a specific file, a directory,     a search pattern (with wildcards * or ?), or a list of such     elements separated by commas. +     The specified files are compressed in accordance with the     other parameters specified for the command. When a name refers     to a directory, all files in that directory and, if present,     its subdirectories are compressed. * WINDOWS ** name of original files +    With this parameter the files that are to be compressed are    specified. Usual wildcards (*?) are allowed. *Default* * z/OS ** COMPRESS * UNIX/WINOWS ** none *Valid for* * compression Specifying a filename is an alternative to assigning the file by means of a DD statement. The specification can contain a conversion rule for filenames. The name can be specified in wildcard syntax for decompression. The character `>` in front of the filename means that the flamfile contains a list of filenames to be decompressed. `DUMMY` acts like the DD-statement `//.. DD DUMMY` In principle, FLAM is able to process all filenames via JCL valid in z/OS. FLAM stores the name of the compressed file into the FLAMFILE, if required. To avoid any conflicts with national character sets or naming conventions in other systems, all filenames stored in ASCII character set are translated for message and selection in the following way: All national characters are translated to 'X', a backslash '\\' to slash '/', and whitespace ' ' to underline '_'. So it is easier to enter foreign filenames that are unsupported in the z/OS environment. The filename itself remains unchanged in the FLAMFILE.  Entering `DUMMY` as a filename causes FLAM to use this file as dummy like the JCL command `//ddname DD DUMMY`. I.e. reading an input file leads to EOF (end of file), writing to an output file has no effect. So, DD-statements are not necessary for DUMMY files. By prefixing the '>' character (greater than) to the filename or DD-NAME, the FLAM parameters `FLAMIN` and `IDDN` are able to specify a list of files for compression instead of one single file. It is also possible to specify a file list for decompression by means of the `FLAMFILE` or `FLAMDD` parameter. In this list, each filename must be contained in a separate record; leading or trailing space characters (X'40') are ignored. A comment can be inserted after the first space character following the filename. Empty records or records with an asterisk '*' in the first column are regarded as comment lines. All filenames usable in z/OS are legal. Wildcard syntax is allowed. *Example:* If the records in the file USER.DAT.LIST contain the following filenames: the specification leads to all the files specified being compressed into one FLAMFILE (group file). The file that contains the list of filenames can have any format supported by FLAM and be of any type. For 'in-stream files', i.e. input files temporarily created by JES, it is advisable to assign the filenames by means of DD names: This allows the filename list to be specified directly in the job. Filenames can be specified in FLAM by means of parameters written with wildcard syntax. Correspondingly, the entry `FLAMIN=USER.*.DATA.%BC` leads to the compression of all files with the 1st qualifier USER, any 2nd qualifier, DATA as the third part of their name, and a three-digit 4th qualifier which ends with BC and begins with any character. The asterisk '*' stands for any (even an empty) character string. The percent character '%' stands for any character. These special characters are also allowed within members of one or more PO libraries: specifies all members of the library USER.POLIB, that begin with FL; specifies all members whose 4-digit names begin with A and end with B and whose libraries have the identification USER, LIB as their final qualifier, and D as the last character of the second to the last part of their name. All input files are stored in this way in one compressed file (group file). Correspondingly, the wildcard entry in the selection rule for decompression leads to the decompression of only those items of compressed data whose original names conform to the syntax specified. (Comment: this procedure requires a FLAM file header (`HEADER=YES`) and the file information `FILEINFO=YES`) for compression). *Example:* All files with names that conforming to the FLAMIN specification are to be compressed into the file USER.DAT.CMP. If the files are catalogued, the 1st file does not conform to the wildcard syntax and is ignored during compression. If is now specified for decompression, only the files `USER.DATCB.CLIB` and `USER.DATCB.DLIB` will be decompressed. Correspondingly, it is also possible to select a number of FLAMFILEs for decompression: means all FLAMFILEs with the identification USER, CMP as their 2nd qualifier, any character string as the 3rd part of their name and VR8 as their last qualifier are to be decompressed. If the input specification contains more than one element, the following rules regarding syntax and assignment to the FLAMFILE specifications must be obeyed. The input specification may consist of a file or directory name, a pattern (with wildcards), or a list of such elements. Elements of a list are separated by commas. Filenames may contain space characters, but not as first characters. Filnames containing spaces must be enclosed in double quotes. The files specified as input files must actually exist. At least one matching file must exist for a pattern. Otherwise, the `flam` command will be aborted and an error message output. If the input specification specifies files for processing by FLAM, either the `-flamin` parameter or `-flamfile` must be specified for the compression or decompression procedure respectively. If the data is to be entered via the special stdin file, the parameter for the input specification is omitted. FLAM can thus be used as a filter. If the flam command contains several different input and output specifications, they are assigned to one another. The assignment determines where the compressed data of each original file and the decompressed data of each compressed file is saved. The input and output specifications are assigned to one another by means of their positions in the lists. The first input specification is assigned to the first output specification and the second input specification to the second output specification, etc. If there are more input specifications than output specifications, the excess input specifications are assigned to the final output specification. If there are too many output specifications, the excess ones are ignored. If the output specification is a file specification, all the outputs which result from processing the assigned input files are saved in this file. The file attributes must be compatible. If the output specification is a substitution rule, a separate FLAMFILE, which is named according to this rule, is created during the compression procedure for each of the assigned input files. During the decompression procedure, the substitution rule is applied to the names of the FLAMFILEs and not to the names of the compressed original files, i.e. each FLAMFILE results in a separate decompressed file. If a FLAMFILE which contains the compressed data of several different files is assigned an output file, all the compressed data in this FLAMFILE is decompressed into the output file. The output specification [] or [`*`] is then necessary in order to create separate files again. In this case, each compressed block is decompressed into a file with the original name. In the example below, the flam command contains a list of input specifications and a list of output specifications. The list of input specifications contains four entries, namely the output specifications, two substitution rules and a file specification. In accordance with the assignment rules, a file with the same name and a .cmp extension is created for each file which has a .dat extension, and the compressed data of all the files with a .txt extension is saved in a single FLAMFILE called text.arc. The compressed data of `func1.hlp` is saved in func1xyz on  account of the substitution rule contained in the final output specification. Since there are no further output specifications, this rule is also applied to func2.hlp, i.e. a FLAMFILE called `func2xyz` is created for its compressed data. It should be noted that text.arc can only be decompressed into separate files if `-attributes=all` is specified for the compression procedure, so that the names of all the original files are included in the FLAMFILE. Either of the output  specifications  []  or  [`*`]  can  be used for the decompression procedure, to ensure that the files are decompressed separately and given their original names again. If an output file were to be specified, a single file would result, in which all the records of the original files would be concatenated. * `STREAM - Read from stdin or write to stdout` * `DUMMY - Read EOF or write nothing` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-flamout_7ac0.html",
"FLAMOUT",
"[[CLEP.COMMAND.FLAM.FLAMOUT]] ==== FLAMOUT indexterm:[Parameter, FLAMOUT, FLAM.FLAMOUT] Filename for the output file. With this parameter the names of the decompressed files are specified. During decompression the decompressed data of the FLAMFILE are written into the specified file(s). Selection and conversion rules using pointed brackets '<>' are dropped in FLAM5 and cannot be used anymore. So, the rules described in section the old FLAM4 manuals are deprecated and a migration is required. The new rules are explained in the section <<flcl.input.output.name.mapping,Input to Output Name Mapping>> and apply to the parameter FLAMFILE. Syntax restrictions for FLAMv4 or older: * z/OS ** `FLAMOUT=filename` ** `FLAMO=filename` * UNIX ** `-flamout=output specification` * WINDOWS ** `flamout=output specification` *Values* * z/OS ** Filename with max. 54 characters ** `*DUMMY` * UNIX ** output specification *** Note: With compression, file specification specifies a specific     file or a list of files separated by commas. A substitution     rule is also permitted. +     With decompression, file specification specifies a specific     file, a pattern (with wildcards * or ?), or a list of such     elements separated by commas. * WINDOWS ** output specification *** Note: With the output specification one or more files are specified     into which the decompressed data is to be written.     The following special characters are possible, especially in     combination with outpath: **** `flamout=[]` - original file names are stored in FLAMFILE **** `flamout=[*]` - just as [], but including path, if outpath not specified **** `flamout=[#]` - Filenames are generated to FILE#nnn, e.g. File#002 = 2nd file in FLAMFILE **** `flamout=[#3]` - Only the 3rd file from a FLAMFILE archive is decompressed, using the original name **** `flamout=[#3=<name>]` - Only the 3rd file is decompressed (with <name>) *Default* * no name *Valid for* * compression Specifying a filename is an alternative to assigning the file by means of a DD statement. The specification can contain a conversion rule for filenames. The name can be specified in wildcard syntax for decompression. The character `>` in front of the filename means that the flamfile contains a list of filenames to be decompressed. `DUMMY` acts like the DD-statement `//.. DD DUMMY` In principle, FLAM is able to process all filenames via JCL valid in z/OS. FLAM stores the name of the compressed file into the FLAMFILE, if required. To avoid any conflicts with national character sets or naming conventions in other systems, all filenames stored in ASCII character set are translated for message and selection in the following way: All national characters are translated to 'X', a backslash '\\' to slash '/', and whitespace ' ' to underline '_'. So it is easier to enter foreign filenames that are unsupported in the z/OS environment. The filename itself remains unchanged in the FLAMFILE.  Entering `DUMMY` as a filename causes FLAM to use this file as dummy like the JCL command `//ddname DD DUMMY`. I.e. reading an input file leads to EOF (end of file), writing to an output file has no effect. So, DD-statements are not necessary for DUMMY files. By prefixing the '>' character (greater than) to the filename or DD-NAME, the FLAM parameters `FLAMIN` and `IDDN` are able to specify a list of files for compression instead of one single file. It is also possible to specify a file list for decompression by means of the `FLAMFILE` or `FLAMDD` parameter. In this list, each filename must be contained in a separate record; leading or trailing space characters (X'40') are ignored. A comment can be inserted after the first space character following the filename. Empty records or records with an asterisk '*' in the first column are regarded as comment lines. All filenames usable in z/OS are legal. Wildcard syntax is allowed. *Example:* If the records in the file USER.DAT.LIST contain the following filenames: the specification leads to all the files specified being compressed into one FLAMFILE (group file). The file that contains the list of filenames can have any format supported by FLAM and be of any type. For 'in-stream files', i.e. input files temporarily created by JES, it is advisable to assign the filenames by means of DD names: This allows the filename list to be specified directly in the job. Filenames can be specified in FLAM by means of parameters written with wildcard syntax. Correspondingly, the entry `FLAMIN=USER.*.DATA.%BC` leads to the compression of all files with the 1st qualifier USER, any 2nd qualifier, DATA as the third part of their name, and a three-digit 4th qualifier which ends with BC and begins with any character. The asterisk '*' stands for any (even an empty) character string. The percent character '%' stands for any character. These special characters are also allowed within members of one or more PO libraries: specifies all members of the library USER.POLIB, that begin with FL; specifies all members whose 4-digit names begin with A and end with B and whose libraries have the identification USER, LIB as their final qualifier, and D as the last character of the second to the last part of their name. All input files are stored in this way in one compressed file (group file). Correspondingly, the wildcard entry in the selection rule for decompression leads to the decompression of only those items of compressed data whose original names conform to the syntax specified. (Comment: this procedure requires a FLAM file header (`HEADER=YES`) and the file information `FILEINFO=YES`) for compression). *Example:* All files with names that conforming to the FLAMIN specification are to be compressed into the file USER.DAT.CMP. If the files are catalogued, the 1st file does not conform to the wildcard syntax and is ignored during compression. If is now specified for decompression, only the files `USER.DATCB.CLIB` and `USER.DATCB.DLIB` will be decompressed. Correspondingly, it is also possible to select a number of FLAMFILEs for decompression: means all FLAMFILEs with the identification USER, CMP as their 2nd qualifier, any character string as the 3rd part of their name and VR8 as their last qualifier are to be decompressed. If the output specification contains more than one file, the following rules described with regard to the syntax and the assignment to the FLAMFILE specifications must be observed. The output specification may consist of a filename, a list of filenames (separated by commas), or a substitution rule. A substitution rule has the following format: [string1=string2]. Moreover, one of the output specifications [ ], [`*`], or [filename] may be used (see description below). Output files are created if they do not exist and overwritten if they do. If a substitution rule is defined as an output specification, the name of the FLAMFILE or the decompressed file must be formed by substituting string2 for string1 in the name of the input file. The strings and the equal sign must have no separating spaces in between. The substitution rule applies only to file names and not to path names. *Example:* causes the files called helptxt1.txt and helptxt2.txt to be compressed and the compressed data to be saved in the associated FLAMFILEs called helptxt1.cmp and helptxt2.cmp. The substitution rule must be applicable to all the assigned input files, i.e. string1 must be contained in the names of every one of these files, or the flam command will be aborted for the file to which it does not apply and an error message will be output. Only one substitution takes place when the name of the output file is formed, even if string1 occurs more than once in the name of the input file. The output specifications [file name], [ ], and [`*`] have special meanings. Using [file name] as output specification causes the decompression to select one or  when file name contains wildcards-, possibly several, matching file(s) from  a FLAMFILE archive. Those are decompressed into the current directory unless -outpath=... directs otherwise. If the output specification for the decompression procedure is [*], the names of the decompressed files are derived from the FLAMFILE, provided the FLAMFILE actually contains them. If not, an error message is output. -attributes=all must be specified for the compression procedure, in order to include the names of the original files in the FLAMFILE. If the output specification is [], the effect is similar to the output specification [`*`], i.e. the names of the decompressed files are derived from the FLAMFILE(s), except that only the file name is taken into account. The path name is ignored. All the files are thus created in the current directory if no -outpath specification is given. Once again, -attributes=all must have been set for the compression procedure. The output specifications [file name], [], and [`*`] must not be part of a list of output specifications, i.e. they must stand alone. If the output specification specifies files for processing by FLAM, either the -flamfile parameter or -flamout must be specified  for the compression or decompression procedure respectively. If the data is to be output to the special file stdout, the parameter for the output specification must be omitted. FLAM can thus be used as a filter.  man_flam4_assignintooutspec.txt * `STREAM - Read from stdin or write to stdout` * `DUMMY - Read EOF or write nothing` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-outpath_ff9b.html",
"OUTPATH",
"[[CLEP.COMMAND.FLAM.OUTPATH]] ==== OUTPATH indexterm:[Parameter, OUTPATH, FLAM.OUTPATH] This parameter determines the directory location used by FLAM to create a decompressed file. Syntax restrictions for FLAMv4 or older: * UNIX ** `-outpath=output path` * WINDOWS ** *outpath=path` *Values* * UNIX ** An existing directory in which FLAM will create the file(s) being    decompressed. This may be an absolute or a relative path.    An explicit specification `-flamout=...` at decompression    may also include a complete directory path. This option is    not available when decompressing with `-flamout=[ ]`. In    that case, an output directory can be specified using    `outpath=...`. * WINDOWS ** The specified path becomes the target directory.    The directory structure is generated if necessary. *Default* * UNIX ** No default value can be set for -outpath. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-mode_f28b.html",
"MODE",
"[[CLEP.COMMAND.FLAM.MODE]] ==== MODE indexterm:[Parameter, MODE, FLAM.MODE] * z/OS: Compression mode only. * Unix: Compression mode and, when desired, with encryption mode. * Windows: Compression mode only. Input file(s) are compressed with the specified FLAM mode. FLAM supports four compression modes: adc, cx7, cx8, and vr8. In the adc, cx8, and vr8 modes, it creates the FLAMFILE as a binary file. Mode adc is the most efficient one. It compresses the datastream by removing the redundancy of repetitive sequences and can be used universally. The other modes mainly eliminate 'vertical redundancy', i.e. their efficiency relies on the recognition of re-occurring column contents in table-structured data. Compression mode adc can be combined with one of two encryption methods supported by FLAM. The first is AES, that has been declared standard for US government agencies by NIST (National Institute of Standards and Technology), the second flamenc is a proprietary algoriths of limes datentechnik gmbh. None of the other compression methods allows encryption. In all binary modes the compressed information is largely independent of the characteristics of the system on which the compression took place, i.e. the FLAMFILEs must not be modified, for example, if they are transmitted on a line which translates codes automatically. FLAMFILEs which are compressed in the cx7 mode, on the other hand, are insensitive to code translations, since they represent all control information by means of alphanumeric characters, the codes for which are standardized internationally in the ASCII and EBCDIC systems. Providing the original data is character-coded and suitable for exchange between systems with different character sets, the information content of the FLAMFILE remains fully intact after it has been converted to the character set of the destination system, despite the altered binary contents, thanks to the character-oriented interpretation. The compression mode is identified automatically when the file is decompressed. The user thus does not need to know the compression mode in order to decompress a file. NOTE: Compression mode CX8 and VR8 does not support `CRYPTOMODE=FLAM`.       Compression mode CX7 does not support either `CRYPTOMODE=ADC`       nor `CRYPTOMODE=FLAM`.          The compression mode is especially important for file transfer.          For local use only the 8 bit modes should be used (ADC/CX8/VR8)          for better efficiency. +          For file transfer on transparent lines also the 8 bit modes          should be used. For compressed text data (only printable          characters - no control or tab characters) shall be transferred          via non transparent lines the 7 bit mode (CX7) is appropriate.          as encryption mode. +          This parameter specifies the mode in which the original file is          compressed and, if desired, encrypted.           The input file is compressed with the specified FLAM mode.           The key word mode= may be omitted. Syntax restrictions for FLAMv4 or older: * z/OS ** `MODE=ADC/CX7/CX8/VR8/NDC` ** `MO=ADC/CX7/CX8/VR8/NDC` * UNIX ** `-mode=adc/aes/cx7/cx8/vr8/flamenc` +    (see also parameter <<CLEP.COMMAND.FLAM.NDC,NDC>>) * WINDOWS ** `mode=adc/aes/cx7/cx8/vr8/ndc` *Values* * z/OS ** `ADC` - 8 bit compression of highest efficiency ** `CX7` - transformable 7 bit compression ** `CX8` - 8 bit compression (CPU time optimised) ** `VR8` - 8 bit compression (space optimised) ** `NDC` - no compression * UNIX ** `adc` - 8 bit compression of highest efficiency. +            With `-mode=adc` the input file is compressed in adc mode and a            binary FLAMFILE is created. This is the most efficient            mode and can be used universally irrespective of the            data structure. With this mode, a password can be            specified to encrypt the FLAMFILE, see also parameters            <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>> and <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>> ** `aes` - `mode=aes` causes the input file to be compressed in the adc            mode with AES encryption. A *password must be specified* with            the `-password` parameter, see also parameters            <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>> and <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. ** `cx7` - transformable 7 bit compression. +            With `-mode=cx7`, the input file is compressed in the cx7 mode            and a character-coded FLAMFILE is created. However,            files should only be compressed in this mode if they do not            contain any non-printing characters. It is a slightly less            efficient mode, though on the other hand the FLAMFILE which            is created can be converted to other character sets, e.g.            from ASCII to EBCDIC, without losing information. ** `cx8` - 8 bit compression (CPU time optimised). +            With `-mode=cx8` the input file is compressed in the cx8 mode,            respectively, and a binary FLAMFILE is created. The purpose            of this mode is to ensure compatibility with previous versions. ** `vr8` - 8 bit compression (space optimised). +            With `-mode=vr8`, the input file is compressed in            vr8 mode, respectively, and a binary FLAMFILE is            created. The purpose of this mode is to ensure compatibility            with previous versions. ** `flamenc` - `mode=flamenc` causes the input file to be compressed in the                 adc mode with FLAM encryption (the  proprietary                 encryption method used with FLAM 3).                 A *password must be specified* with the `-password`                 parameter.                 See also parameters <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>> and                 <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. ** See also parameter <<CLEP.COMMAND.FLAM.NDC,NDC>>. * WINDOWS ** `adc` - 8 bit compression of highest efficiency. +            FLAM Version 3:  The input file is compressed            in ADC mode and a binary FLAMFILE is generated. ** `aes` - FLAM Version 4:  The input file is compressed            with the AES method. A password must be specified, see also               parameters <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>> and               <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. ** `cx7` - Transformable 7 bit compression. +            The input file is compressed in CX7 mode and a            character coded FLAMFILE is generated. However, in this mode            only those files should be compressed that solely contain            printable characters. This mode is a little less efficient,            but the generated. FLAMFILE can be converted to other            character codes without information loss, for example from            ASCII to EBCDIC using remote data transmission.e.g.            from ASCII to EBCDIC, without losing information. ** `cx8` - 8 bit compression (CPU time optimised). +            The input file is compressed in cx8 mode and a            binary FLAMFILE is generated. This mode is more efficient            and includes a stricter integrity check during decompression.            But the generated FLAMFILE cannot be transmitted via 7 bit            lines or via line sections where automatic code conversion            takes place. ** `vr8` - 8 bit compression (space optimised). +            The input file is compressed in vr8 mode and a            binary  FLAMFILE®  is generated. In contrast to CX8 and CX7            mode the VR8-compressed data is a continuous bit stream and            has no byte structure.this mode is to ensure compatibility            with previous versions. ** `ndc` - No data compression.  +            FLAM Version 3 compatible: The input file            is not compressed.  An ADC-compatible binary FLAMFILE® is            generated. This mode is used for the packaging and the            encryption of already compressed data. *Default* * z/OS ** ADC * UNIX ** none * WINDOWS ** none *Valid for* * compression * `CX7 - Compression encoding as printable characters` * `CX8 - Compression encoding as binary data` * `VR8 - Enhanced compression encoding as binary data` * `ADC - Advanced Data Compression` * `NDC - No data compression` * `AES - AES encryption` * `FLAMENC - FLAM encryption` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ndc_89a3.html",
"NDC",
"[[CLEP.COMMAND.FLAM.NDC]] ==== NDC indexterm:[Parameter, NDC, FLAM.NDC] This parameter can be used in ADC mode to suppress compression (UNIX only). For z/OS and UNIX see parameter <<CLEP.COMMAND.FLAM.MODE,MODE>>. + For data that is known to compress badly, FLAM's performance can be improved by this parameter which suppresses compression. With modes aes and flamenc, only encryption is done while with mode adc this parameter causes FLAM to simply copy the data. With other modes, -ndc has no effect. FLAMFILEs  created  with  `-ndc` are always Secure FLAMFILEs and are logged as adc-compressed files at decompression. -ndc cannot be set as default. Syntax: * `-ndc` *Values:* * none *Default:* * `-ndc` cannot be set as default. *Valid for:* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-cryptomode_ddc6.html",
"CRYPTOMODE",
"[[CLEP.COMMAND.FLAM.CRYPTOMODE]] ==== CRYPTOMODE indexterm:[Parameter, CRYPTOMODE, FLAM.CRYPTOMODE] This parameter has the effect that the FLAMFILE is encrypted. This encryption method is activated by setting the parameters `CRYPTOMODE=AES` and `CRYPTOKEY=key` and is available with compression modes ADC or NDC. With `CRYPTOMODE=AES` the compression mode defaults to ADC rather than the mode specified in the default settings. For compression with `mode=adc` or `mode=ndc` the password specification is required. Without entering a `MODE` parameter, ADC is used. Syntax restrictions for FLAMv4 or older: * z/OS ** `CRYPTOMODE=AES/FLAM` ** `CRYPTOM=AES/FLAM` +    Password specification required,    see also  parameters <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>>    and <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. * UNIX ** See parameter <<CLEP.COMMAND.FLAM.MODE,MODE>> for `-mode=aes` or `flamenc` +    This parameter specifies the mode in which the original file is    compressed and encrypted. * WINDOWS ** `cryptmode=crypt option` +    Password specification required,    see also parameter <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>>    and <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. *Values* * z/OS ** `CRYPTOMODE=FLAM` +    Internal FLAM encryption ( FLAM Version 3 ). CRYPTOMODE=FLAM and MODE CX8 or VR8 are not supported. ** `CRYPTOMODE=AES` +    Advanced Encryption Standard ( FLAM Version 4 ) +    Note: AES with `MODE=ADC` was introduced in FLAM V4.0 and is not    compatible to older versions. AES and `MODE=CX8/VR8` is introduced    in this version and requires FLAM V4.7 as minimum.    FLAM and `MODE=CX8/VR8` is not supported. * WINDOWS ** `cryptmode=none` +    no encryption ** `cryptmode=flam` +    FLAM encryption (FLAM Version 3) ** `cryptmode=aes` +    encryption with AES (FLAM Version 4) *Default* * z/OS ** `FLAM` * WINDOWS ** none *Valid for* * compression * `OFF - Disable encryption` * `AES - AES encryption` * `FLAMENC - FLAM encryption` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-cryptokey_28e0.html",
"CRYPTOKEY",
"[[CLEP.COMMAND.FLAM.CRYPTOKEY]] ==== CRYPTOKEY indexterm:[Parameter, CRYPTOKEY, FLAM.CRYPTOKEY] Key to encrypt or decrypt a FLAMFILE. This parameter activates the crytographic method, entered with parameter CRYPTOMODE. The FLAMFILE is encrypted with AES in combination with `mode=adc` or `mode=ndc`. See also parameters <<CLEP.COMMAND.FLAM.MODE,MODE>>, <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>>, <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>, <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>, <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>> or <<CLEP.COMMAND.FLAM.PAASCII,PAEBCDIC>>. NOTE: Regardless of the encryption algorithm, a key should consist of at       least 6 - 8 characters and it should at least contain 1 character       from the following sets: * Lower case letters * Upper case letters * Numbers 0 - 9 * Punctuation characters Syntax restrictions for FLAMv4 or older: * z/OS ** `CRYPTOKEY=password` ** `CRYPTOK=password` * UNIX ** See parameter <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. * WINDOWS ** `cryptkey=password` +    Alternative specification: `cryptmode=aes password=password` +    See also parameters <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>> and    <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>. *Values* * z/OS ** 1 - 64 characters starting with A'...', C'...', X'...' or a string. +    Using A'...' all characters are translated to ASCII using the    internal translation table A/E (ch. A). * WINDOWS ** Regardless of the encryption algorithm a key should consist of at   least 6 - 8 characters and it should contain at least 1 character   from each of the following sets: *** Lower case letters *** Capital letters *** Numbers 0 - 9 *** Punctuation characters *Default* * No default value can be set for password. *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-password_7bb1.html",
"PASSWORD",
"[[CLEP.COMMAND.FLAM.PASSWORD]] ==== PASSWORD indexterm:[Parameter, PASSWORD, FLAM.PASSWORD] Password used for en-/decryption. During compression the FLAMFILE is encrypted with the specified password and can only be decompressed with the same password. FLAM uses the specified password during compression with mode ADC to encrypt the compressed data and during decompression to decrypt the encrypted compressed data. The passwords used at compression and decompression must be identical or else the decompression command is rejected with an appropriate error message. With modes other than adc, aes, or flamenc this parameter causes an error. When used with mode adc, the flamenc method is used for encryption. A password entered as a character string is equivalent to a hexadecimal sequence consisting of its character codes and vice versa. Note that a given character string entered on an ASCII system is not equivalent to the same string entered on a system using EBCDIC code. Therefore, for data exchange among systems with different character codes the hexadecimal format must be used if the codes of the password characters are not available on the keyboard. This parameter cannot be set by default. This parameter and `-kmexit` are mutually exclusive. See also parameters <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>> , <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY/cryptkey>>, <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>, <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>> or <<CLEP.COMMAND.FLAM.PAASCII,PAEBCDIC>>. NOTE: Regardless of the encryption algorithm, a key should consist of at least 6 - 8 characters and it should at least contain 1 character from the following sets: * Lower case letters * Upper case letters * Numbers 0 - 9 * Punctuation characters Syntax restrictions for FLAMv4 or older: * z/OS ** `PASSWORD=password` ** `PASSW=password` +    Password used for en-/decryption (same as CRYPTOK, see also parameter <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY>>). * UNIX ** `-password=password` * WINDOWS ** `password=password` *Values* * z/OS ** any input up to 64 characters (512 bit). *** Note: Please take care of the different code tables or           national character sets used on the different           platforms.           E.g. using the password C'FLAM ' both on Windows           systems (ASCII) and on MVS (EBCDIC) leads to a           password error. You have to pass X'464C414D20' (this           is 'FLAM' in ASCII) on MVS instead.           We recommend to use the hex input for a heterogeneous           environment. * UNIX ** The value for password can be entered in two formats: *** As a simple character string: In this format, the password is entered     immediately following the equal sign as a string of up to 64     characters. Valid characters are all capital and small Latin letters,     decimal digits, the minus sign (-) and underscore (_). Using any     other characters may yield unpredictable results. Note that     passwords are case sensitive. +     Example: `-password=Alligator` *** As a sequence of hexadecimal digits: In this format the password may     consist of an even number of up to 128 hexadecimal digits (0-9, a-f,     A-F). In this context small and capital letters are interchangeable.     The sequence is enclosed in single quotes (\\') and preceded by the     letter 'X'. Any such combination is permitted. +     Example: `-password=X\\'416c6c696761746f72\\'` * WINDOWS ** String with a length of 1 to 64 characters. *** Note: On the command line not all characters are allowed, e.g. commas           and subsequent blanks. If required a hex-encoded password can           be entered with paxword, see also parameter <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>. *Default* * No default value can be set for password. *Valid for:* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-paascii_49c2.html",
"PAASCII",
"[[CLEP.COMMAND.FLAM.PAASCII]] ==== PAASCII indexterm:[Parameter, PAASCII, FLAM.PAASCII] Password in ASCII (used in WINDOWS only). Is equal to parameter password. See also  parameters <<CLEP.COMMAND.FLAM.MODE,MODE>>, <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>>, <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>, <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>> or <<CLEP.COMMAND.FLAM.PAEBCDIC,PAEBCDIC>>. NOTE: Regardless of the encryption algorithm, a key should consist of at least 6 - 8 characters and it should at least contain 1 character from the following sets: * Lower case letters * Upper case letters * Numbers 0 - 9 * Punctuation characters Syntax restrictions for FLAMv4 or older: * `paascii=password` * `paa=password` *Values* * String with a length of 1 to 64 characters.   The password is converted to ASCII before it is used. *Default* * No default value can be set for PASSWORD. *Valid for:* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-paebcdic_5323.html",
"PAEBCDIC",
"[[CLEP.COMMAND.FLAM.PAEBCDIC]] ==== PAEBCDIC indexterm:[Parameter, PAEBCDIC, FLAM.PAEBCDIC] Password in EBCDIC used with `mode=adc`, `aes` or `ndc` (in WINDOWS only). During compression the FLAMFILE is encrypted with the specified password and can only be decompressed with the same password. Before usage the password is converted to EBCDIC. This is helpful when communicating with a main frame. Only those characters that can be clearly classified as either ASCII or EBCDIC should be used. This applies to all letters and numbers plus many punctuation marks (usually  !'#$%&*+,./:;=?@  ). German umlauts must be avoided. In critical cases hex input with parameter <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>) is helpful. See also parameters <<CLEP.COMMAND.FLAM.MODE,MODE>>, <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>>, <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>, <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>> or <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>>. NOTE: Regardless of the encryption algorithm, a key should consist of at       least 6 - 8 characters and it should at least contain one character       from the following sets: * Lower case letters * Upper case letters * Numbers 0 - 9 * Punctuation characters Syntax restrictions for FLAMv4 or older: * `paebcdic=password` * `pae=password` *Values* * String with a length of 1 to 64 characters.   Before usage the password is converted to EBCDIC. *Default* * No default value can be set for PASSWORD. *Valid for:* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-paxword_e7c9.html",
"PAXWORD",
"[[CLEP.COMMAND.FLAM.PAXWORD]] ==== PAXWORD indexterm:[Parameter, PAXWORD, FLAM.PAXWORD] Password as hexadecimal character string used for en-/decryption (in WINDOWS only). During compression the FLAMFILE is encrypted with the specified password and can only be decompressed with the same password. FLAM uses the specified password during compression with mode adc to encrypt the compressed data and during decompression to decrypt the encrypted compressed data. The passwords used at compression and decompression must be identical or else the decompression command is rejected with an appropriate error message. With modes other than adc or aes this parameter causes an error. A password entered as a character string is equivalent to a hexadecimal sequence consisting of its character codes and vice versa. Note that a given character string entered on an ASCII system is not equivalent to the same string entered on a system using EBCDIC code. Therefore, for data exchange among systems with different character codes the hexadecimal format must be used if the codes of the password characters are not available on the keyboard. E.g. the word SECRET is encoded in ASCII as 534543524554 and in EBCDIC as E2C5C3E1C5E3. For EBCDIC the entry for SECRET as password is as follows: pax= E2C5C3E1C5E3 or pae= SECRET. This parameter cannot be set by default. See also parameters <<CLEP.COMMAND.FLAM.MODE,MODE>>, <<CLEP.COMMAND.FLAM.CRYPTOMODE,CRYPTOMODE>>, <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>, <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>> or <<CLEP.COMMAND.FLAM.PAEBCDIC,PAEBCDIC>>. NOTE: Regardless of the encryption algorithm, a key should consist of at least 6 - 8 characters and it should at least contain 1 character from the following set: * Lower case letters * Upper case letters * Numbers 0 - 9 * Punctuation characters Syntax restrictions for FLAMv4 or older: * `paxword=password` * `pax=password` *Values* * Hexadecimal character string with a length of 2 to 128 characters *Default* * No default value can be set for `PAXWORD`. `Valid for:` * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-parfile_60a5.html",
"PARFILE",
"[[CLEP.COMMAND.FLAM.PARFILE]] ==== PARFILE indexterm:[Parameter, PARFILE, FLAM.PARFILE] This parameter specifies a file name containing FLAM parameters. Specifying a parameter file permits default values to be overridden without the need for complex inputs in the command line. This specified file can be created interactively using a text editor. Syntax restrictions for FLAMv4 or older: * z/OS ** `PARFILE=parameter filename` ** `PARF=parameter filename` *** Note: Specifying the file name is an alternative to           assigning the file by means of a DD statement. This file           is needed only if additional parameters are to be read           from a catalogued file. * UNIX ** `-parfile=parameter filename` * WINDOWS ** `parfile=parameter filename` *Values* * z/OS ** Filename with max. 54 characters. * UNIX ** Path to a file containing FLAM parameters. Specifying a parameter file    permits default values to be overridden without the need for complex    inputs in the command line.    One parameter file cannot refer to another, i.e. it may not contain a    `parfile` specification. Furthermore, it may not change the `-show`    parameter whose setting is determined when the command line is    analyzed. * WINDOWS ** Path to a file that contains FLAM parameters. *** Note: One parameter per line.           The entries on the command line have a higher priority.           At the end of line comments may be attached with '!'. Lines           that begin with ; or ! are ignored. *Default* * no name *Valid for* * compression * decompression Settings such as the type of operation (compress or decompress), the input/output files, etc., can be entered either directly in the flam command or explicitly in a parameter file. Implicit settings are also possible simply by omitting certain information, for example the compression mode for the compression procedure. The settings which apply automatically if any specifications are missing or redundant are determined by evaluating certain information in a fixed sequence; this results in an order of priorities, which is based both on the category and on the origin of the information. Since parameter files may refer to other parameter files, it is possible for several such files, possibly containing contradictory information, to be concatenated. The first of these parameter files has priority over all the others. If the same parameter is specified more than once within a parameter file, however, only the final specification is valid. The information which is used to determine the FLAM settings is evaluated in the following order: * The command itself * The parameter files * The installed default values If the command itself contains any contradictory or incompatible information, it is rejected and an error message is output. The following priority rules apply in all other situations: * If a FLAM operation is specified in the command (compress/decompress),   it has priority over all the other specifications. If the command does   not contain such a specification, a search is made for it in the   parameter file if one is named by `-parfile=...` or by default.   If the operation is not specified as a FLAM parameter either, the   installed default value, i.e. the default operation, is taken instead. * Any specifications which are incompatible with the FLAM operation are   rejected. * All specifications missing in the command are set according to the   parameter file, if one is specified either in the command itself or   as an installation-specific default value. * All settings which cannot be established either at all or in part   after rules 1 to 3 have been applied are determined on the basis of   the installation-specific default values. * If the input or output specification is missing, the special `stdin`   and `stdout` files are used. In the case of FLAM parameters,   specifications with a lower priority are always completely overridden   by the higher priority, i.e. it is not possible to define a list of   input specifications partly in the command itself and partly in the   parameter file or in the form of default values. The list in the   command cancels out the list at the lower specification level. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-parddn_440f.html",
"PARDDN",
"[[CLEP.COMMAND.FLAM.PARDDN]] ==== PARDDN indexterm:[Parameter, PARDDN, FLAM.PARDDN] Symbolic Job Control file name for parameter file (z/OS only). This parameter allows to change standard DD-NAME FLAMPAR to another one. If no symbolic file name is specified for the parameter file (`PARDDN=(NONE)`), FLAM will not try to read from the parameter file. If the parameter file is not existent or empty, no error is recorded. Syntax restrictions for FLAMv4 or older: * z/OS ** `PARDDN=DD-NAME` *Values* * z/OS ** DD-NAME with max. 8 characters. *Default* * z/OS ** `PARDDN=FLAMPAR` +     result: `FLAMPAR DD=DSN=......` *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-recdelim_174d.html",
"RECDELIM",
"[[CLEP.COMMAND.FLAM.RECDELIM]] ==== RECDELIM indexterm:[Parameter, RECDELIM, FLAM.RECDELIM] Record delimiter for FLAMFILE. See also parameters <<CLEP.COMMAND.FLAM.INRECDELIM,INRECDELIM>> and <<CLEP.COMMAND.FLAM.OUTRECDELIM,OUTRECDELIM>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `RECDEL=String` ** `RECD=String` *** Note: Not evaluated by FLAM under z/OS * UNIX ** `-recdelim=record delimiter` * WINDOWS ** `recdelim=record delimiter` *Values* * z/OS ** String with max. 4 characters. * UNIX ** Hexadecimal characters between 01 and ff, with a length of either 1 or 2 bytes. *** Note: This parameter permits a record delimiter to be specified           for the stream record format.           If a record delimiter is not specified for the stream record           format, 0x0a is used as a default delimiter.           If `-recdelim=0D0A` is specified, for example, the data can           be used for MS-DOS format.           This parameter can only be specified for the compression           procedure. * WINDOWS ** Hexadecimal characters between 01 and FF. Length: 1 or 2 bytes (2 or 4 hex characters) *** Note: Regarding Record format text: With this parameter the record delimiter           of the FLAMFILE can be specified in connection with `recform=text` in `mode=cx7`.           If no record delimiter is specified for record format text, 0D0A (CRLF) is used.           For example, with `recdelim=0a` the output of data is possible in UNIX format.           This parameter can only be specified for the compression procedure. *Default* * no record delimiter *Valid for* * z/OS ** compression, decompression * UNIX ** compression * WINDOWS ** compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-recformat_a075.html",
"RECFORMAT",
"[[CLEP.COMMAND.FLAM.RECFORMAT]] ==== RECFORMAT indexterm:[Parameter, RECFORMAT, FLAM.RECFORMAT] Record format for FLAMFILE (compressed file). Syntax restrictions for FLAMv4 or older: * z/OS ** `RECFM=F/V/U/FB/VB/VBS/FBS` ** `RECFORM=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` ** `RECF=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` *** Note: Not evaluated by FLAM under z/OS * UNIX ** `-recformat=fix/var/stream` *** Note: The FLAMFILE always contains records of identical size.           In the cx8 and vr8 modes, the records can be written either           with (variable) or without (fixed) a record size field. +           The stream record format is used in the cx7 mode. If           `recdelim` is not specified, 0x0a is used as the default           record delimiter. +           `-recformat` needs only to be specified for the compression           procedure. * WINDOWS ** `recformat=**f**ix / **v**ar / **t**ext` *Values* * z/OS ** `F/FIX` - Fixed record length ** `V/VAR` - Variable record length ** `U/UNDEF` - Undefined record length ** `FB/FIXBLK` - Fix blocked ** `VB/VARBLK` - Variable blocked ** `VBS/VARSPAN` - Variable spanned ** `FBS/FIXS` - Fix standard * UNIX ** `fix` - Fixed-size records, size as set by the -recsize parameter. ** `var` - Variable-size records; the record size field is 2 bytes long. ** `stream` - Variable-size records with a record delimiter. * WINDOWS ** `**f**ix` - records with a fixed record length (default for all FLAMFILES). ** `**v**ar` - Variable-size records; the record size field is 2 bytes long. ** `**t**ext` - Variable-size records with a record delimiter. *Default* * z/OS ** FB/FIXBLK * UNIX ** none * WINDOWS ** f/fix *Valid for* * z/OS ** compression, decompression * UNIX ** compression * WINDOWS ** compression * `FIX - Records with a fixed record length (default for all FLAMFILES)` * `F - Records with a fixed record length (default for all FLAMFILES)` * `VAR - Records with a variable record length. The additional (!) record length field is 2 bytes long` * `V - Records with a variable record length. The additional (!) record length field is 2 bytes long` * `TEXT - Records with a variable record length and end-of-record characters (CX7 only)` * `STREAM - Variable-size records with a record delimiter` * `UNDEFINED - Records with undefined record length (Host only)` * `UNDEF - Records with undefined record length (Host only)` * `U - Records with undefined record length (Host only)` * `FIXBLK - Fix blocked (Host only)` * `FB - Fix blocked (Host only)` * `FIXS - Fix standard (Host only)` * `FBS - Fix standard (Host only)` * `VARBLK - Variable blocked (Host only)` * `VB - Variable blocked (Host only)` * `VARSPAN - Variable spanned (Host only)` * `VBS - Variable spanned (Host only)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-recsize_65e7.html",
"RECSIZE",
"[[CLEP.COMMAND.FLAM.RECSIZE]] ==== RECSIZE indexterm:[Parameter, RECSIZE, FLAM.RECSIZE] This parameter specifies the maximum record length of the FLAMFILE (without record length fields). See also parameters <<CLEP.COMMAND.FLAM.RECFORMAT,RECFORMAT>>, <<CLEP.COMMAND.FLAM.INRECSIZE,INRECSIZE>> and <<CLEP.COMMAND.FLAM.OUTRECSIZE,OUTRECSIZE>>. The compressed data are written as records of the same length regardless of the record format. There is no relation between compressed data blocks and the records in the compressed file (FLAMFILE). A record can contain data from one or more compressed data blocks. A compressed data block can be included in one or more records. The record length of the compressed file is independent from the record length of the original file. This parameter should be chosen according only to the aspect of efficiency and functionality. To avoid padding in blocks, for fixed record length the block length should be a multiple of the record length. File transfer may require other record length (e.g.: 80 bytes fix for RJE (IBM) or 2036 bytes fix for transfer between SINIX and BS2000 with FT-BS2000). This parameter is used for compression only. Syntax restrictions for FLAMv4 or older: * ZOS ** `MAXSIZE=n` ** `MAXS=n` * UNIX ** `-recsize=n` * WINDOWS ** `recsize=nnn` ** `recs=nnn` *Values* * ZOS ** 80 - 32760 * UNIX ** Integer number between 80 and 32760 for all modes except cx7. ** Integer number between 80 and 4095 for the cx7 mode. *** Note: The compressed data is always written in records of the same           size, irrespective of the record format. There is no           relationship between the compressed blocks and the records in           the compressed file. A record may contain data pertaining to           one or more compressed blocks. A compressed block may be           contained in one or more records.           There is no relationship between the records in the compressed           and non-compressed files. This parameter need only be           specified for the compression procedure. * WINDOWS ** Integer decimal number between 80 and 32760 for modes CX8, VR8, ADC, NDC, AES ** Integer number between 80 and 4095 in CX7 mode. *Default* * 512 Bytes *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-inrecdelim_97ca.html",
"INRECDELIM",
"[[CLEP.COMMAND.FLAM.INRECDELIM]] ==== INRECDELIM indexterm:[Parameter, INRECDELIM, FLAM.INRECDELIM] Record delimiter for original input file. See also parameters <<CLEP.COMMAND.FLAM.RECDELIM,RECDELIM>> and <<CLEP.COMMAND.FLAM.OUTRECDELIM,OUTRECDELIM>>. Syntax restrictions for FLAMv4 or older: * Z/OS ** `IRECDEL=String` ** `IRECD=String` *** Note: Not evaluated by FLAM under z/OS. * UNIX ** `-inrecdelim=record delimiter` * WINDOWS ** `inrecdelim=record delimiter` ** `inrecd=record delimiter` *Values* * Z/OS ** String of up to 4 characters * UNIX ** Hexadecimal characters between 01 and ff, with a length of either 1 or 2 bytes. *** Note: This parameter specifies the record delimiter for an           original file with a stream record format. If a stream record           format is specified without a record delimiter, 0x0a and           0x0d0a are interpreted as the end of a record. +           If only 0x0a should be interpreted as the end of a record,           `inrecdelim=0a` must be specified, in order to ensure that           occurrences of 0x0d which precede 0x0a are interpreted           as part of the data and not as part of a record delimiter. If           only 0x0d0a should be interpreted as a record delimiter in           a particular file, `inrecdelim=0d0a` must be specified, to           ensure that any 0x0a strings which occur alone are           identified as belonging to the data. +           Any other character combinations can be used as record           delimiters, in addition to 0x0a and 0x0d0a. * WINDOWS ** Hexadecimal characters between 01 and FF, length: 1 or 2 bytes (2 or 4 hex characters). *** NOTE: With this parameter the input record delimiter of an original file is           specified with <<CLEP.COMMAND.FLAM.RECFORMAT,record format>> text.           When using record format text without specification of input record delimiter,           0d0a (CRLF) is interpreted as the end of record.           If only '0a' is intended as the end of record, then `inrecdelim=0a`           has to be specified in order to interpret a '0d' before a '0a' not as           part of the input record delimiters but as part of the data. If a file           is meant to contain the input record delimiter characters 0d0a only,           `inrecdelim=0d0a` has to be specified in order to recognize isolated           characters '0a' as part of the data.           Not only 0a and 0d0a are allowed as input record delimiters, but           also any other character combinations. *Default* * no input record delimiter *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-inrecformat_7a40.html",
"INRECFORMAT",
"[[CLEP.COMMAND.FLAM.INRECFORMAT]] ==== INRECFORMAT indexterm:[Parameter, INRECFORMAT, FLAM.INRECFORMAT] This parameter specifies the record format of the original input file. The data is read from the input file in the form of logical records with the specified format in order to save them compressed or uncompressed in the FLAMFILE. Syntax: * z/OS ** `IRECFM=F/V/U/FB/VB/VBS/FBS` ** `IRECFORM=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` ** `IRECF=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` *** Note: This parameter is not necessary for catalogued files in z/OS. * UNIX ** `-inrecformat=eaf/fix/stream/undefined/variable/var_2B/var2b_data/var_4b/var_ascii/var_ebcdic` * WINDOWS ** inrecformat=**f**ix / **dtext** / **t**ext / **v**ariable / **var_2**b / **var_4**b / **var_a**scii / **var_e**bcdic / **u**ndefined ** inrecf=**f**ix / **dtext** / **t**ext / **v**ariable / **var_2**b / **var_4**b / **var_a**scii / **var_e**bcdic / **u**ndefined *Values* * z/OS ** `F/FIX` - Fixed record length ** `V/VAR` - Variable record length ** `U/UNDEF` - Undefined record length ** `FB/FIXBLK` - Fix blocked ** `VB/VARBLK` - Variable blocked ** `VBS/VARSPAN` - Variable spanned ** `FBS/FIXS` - Fix standard * UNIX ** `*eaf*` - EAF data, variable record size with a 4-byte size field in              ASCII or EBCDIC code. The record size only specifies the              length of the data excluding the size field. The size field              is part of the data. ** `*fix*` - Fixed record size as set by -inrecsize. ** `*stream*` - Variable record size (max. 2048 characters) with record                 delimiter. Typically text data. ** `undefined` - Records with no defined structure; records of an identical                  size are read (with the possible exception of the last one). ** `*variable*` - Variable record size with 2-byte binary record size                   (including length field). ** `*var_2b*` - Variable record size with 2-byte binary record size                 (including length field). ** `*var2b_data*` - Variable record size with 2-byte binary record size                     (not including length field). ** `*var_4b*` - Variable record size with 4-byte binary record size                 (including length field) (host). ** `*var_ascii*` - Variable record size with 4-byte size field in ASCII                    code (including length field). ** `*var_ebcdic*` - Variable record size with 4-byte size field in EBCDIC                     code (including length field). * WINDOWS ** `**f**ix` - fixed record length  *inrecsize* ** `**dtext**` - variable record length with input record delimiter,                  last record without delimiter. ** `**t**ext` - variable record length with input record delimiter ** `**v**ariable` - variable record length with a binary record length of 2 bytes. ** `**var_2**b` - variable record length with a binary record length of 2 bytes. ** `**var_4**b` - variable record length with a binary record length of 4 bytes                   (host: length of 2 bytes, padding is ignored). ** `**var_a**scii` - variable record length with a length field of 4 bytes in ASCII code. ** `**var_e**bcdic` - variable record length with a length field of 4 bytes in EBCDIC code. ** `**u**ndefined` - records without structure; records with the length  inrecsize are                      read, last record may be shorter. *Default* * z/OS ** `FB/FIXBLK` * UNIX ** none * WINDOWS ** none *Valid for* * compression * `EAF - EAF data, variable record size with a 4-byte size field in ASCII or EBCDIC code. The record size only specifies the length of the data excluding the size field. The size field is part of the data` * `FIX - Fixed record length (in/out)recsize` * `DTEXT - Variable record length with end-of-record characters,  last record without delimiter` * `TEXT - Variable record length with end-of-record characters` * `STREAM - Variable record size (max. 2048 characters) with record delimiter. Typically text data` * `VARIABLE - Variable record size with 2-byte binary record size (including length field)` * `UNDEFINED - Records without structure; records with the length  inrecsize are read, last record may be shorter` * `U - Undefined (Host only)` * `F - Fix (Host only)` * `FIXBLK - Fix blocked (Host only)` * `FB - Fix blocked (Host only)` * `V - Variable (Host only)` * `VARBLK - Variable blocked (Host only)` * `VB - Variable blocked (Host only)` * `FIXS - Fix standard (Host only)` * `FBS - Fix standard (Host only)` * `VARSPAN - Variable spanned (Host only)` * `VBS - Variable spanned (Host only)` * `VAR_2B - Variable record size with 2-byte binary record size (including length field)` * `VAR2B_DATA - Variable record size with 2-byte binary record size (not including length field)` * `VAR_4B - Variable record size with 4-byte binary record size (including length field) (host)` * `VAR_ASCII - Variable record size with 4-byte size field in ASCII code (including length field)` * `VAR_EBCDIC - Variable record size with 4-byte size field in EBCDIC code (including length field)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-inrecsize_bd6e.html",
"INRECSIZE",
"[[CLEP.COMMAND.FLAM.INRECSIZE]] ==== INRECSIZE indexterm:[Parameter, INRECSIZE, FLAM.INRECSIZE] This parameter specifies the record size of the original input file. See also parameter <<CLEP.COMMAND.FLAM.INRECFORMAT,INRECFORMAT>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `IRECSIZE=n` ** `IRECS=n` *** Note: Record length of input file (true length, without record length field.)           This parameter is not necessary for catalogued files in z/OS. * UNIX ** `-inrecsize=n` *** Note: This parameter specifies the record size of original input files           with a fixed or undefined record format. * WINDOWS ** `inrecsize=nnn` ** `inrecs=nnn` *** Note: This parameter specifies the record length of original input     files with record format `fix` or `undefined` resp. the maximum     record length. *Values* * z/OS ** 0-32760 * UNIX ** 1-32760 * WINDOWS ** 1-32760 *Default* * z/OS ** 32752 * UNIX ** none * WINDOWS ** 512 *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-outrecdelim_b539.html",
"OUTRECDELIM",
"[[CLEP.COMMAND.FLAM.OUTRECDELIM]] ==== OUTRECDELIM indexterm:[Parameter, OUTRECDELIM, FLAM.OUTRECDELIM] Record delimiter for original output file. See also parameters <<CLEP.COMMAND.FLAM.RECDELIM,RECDELIM>> and <<CLEP.COMMAND.FLAM.OUTRECDELIM,OUTRECDELIM>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `ORECDEL=String` ** `ORECD=String` *** Note: Not evaluated by FLAM under z/OS. * UNIX ** `-outrecdelim=record delimiter` * WINDOWS ** `outrecdelim=record delimiter` ** `outrecd=record delimiter` *Values* * z/OS ** String of up to 4 characters. * UNIX ** Hexadecimal characters between 01 and FF, with a length of either 1 or 2 bytes. *** Note: This parameter specifies the record delimiter for a           decompressed file with the stream record format.           If a record delimiter is not specified for the stream record format, 0x0A is used as a           default delimiter. If outrecdelim=0D0A is specified, the decompressed file can be           generated in MSDOS format. Any other character combinations are also allowed as           record delimiters. * WINDOWS ** Hexadecimal characters between 01 and FF, length: 1 or 2 bytes (2 or 4 hex characters). *** NOTE: With this parameter the end-of-record character of the decompressed file is           specified with record format text (see also parameter <<CLEP.COMMAND.FLAM.RECFORMAT,RECFORMAT>>).           When using record format text without specifying the end-of-record character,           0D0A (CRLF) is written as the end-of-record character. With the specification           `outrecdelim=0A` it is possible to generate the decompressed file in UNIX format.           Beyond that every other combination of characters is allowed as           end-of-record characters. *Default* * no input record delimiter *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-outrecformat_1b79.html",
"OUTRECFORMAT",
"[[CLEP.COMMAND.FLAM.OUTRECFORMAT]] ==== OUTRECFORMAT indexterm:[Parameter, OUTRECFORMAT, FLAM.OUTRECFORMAT] This parameter specifies the record format of original output files (decompressed files). The data are read from the FLAMFILE and are written in form of logical records with the specified format in order to save them uncompressed. Syntax restrictions for FLAMv4 or older: * z/OS ** `ORECFM=F/V/U/FB/VB/VBS/FBS` ** `ORECFORM=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` ** `ORECF=FIX/VAR/UNDEF/FIXBLK/VARBLK/VARSPAN/FIXS` *** Note: This value must only be specified if the record format           differs from the original file. * UNIX ** `-outrecformat=eaf/fix/stream/undefined/variable/var_2B/var2b_data/var_4b/var_ascii/var_ebcdic` * WINDOWS ** `outrecformat=**f**ix / **dtext** / **t**ext / **v**ariable / **var_2**b / **var_4**b / **var_a**scii / **var_e**bcdic / **u**ndefined` ** `outrecf=**f**ix / **dtext** / **t**ext / **v**ariable / **var_2**b / **var_4**b / **var_a**scii / **var_e**bcdic / **u**ndefined` *Values* * z/OS ** `F/FIX` - Fixed record length ** `V/VAR` - Variable record length ** `U/UNDEF` - Undefined record length ** `FB/FIXBLK` - Fix blocked ** `VB/VARBLK` - Variable blocked ** `VBS/VARSPAN` - Variable spanned ** `FBS/FIXS` - Fix standard * UNIX ** `*eaf*` - EAF data, variable record size with a 4-byte size field in              ASCII or EBCDIC code. The record size only specifies the              length of the data excluding the size field. The size field              is part of the data. ** `*fix*` - Fixed record size as set by `-inrecsize`. ** `*stream*` - Variable record size (max. 2048 characters) with record                 delimiter. Typically text data. ** `*undefined*` - Records with no defined structure; records of an identical                    size are read (with the possible exception of the last one). ** `*variable*` - Variable record size with 2-byte binary record size (including length field). ** `*var_2b*` - Variable record size with 2-byte binary record size (including length field). ** `*var2b_data*` - Variable record size with 2-byte binary record size (not including length field). ** `*var_4b*` - Variable record size with 4-byte binary record size (including length field) (host). ** `*var_ascii*` - Variable record size with 4-byte size field in ASCII code (including length field). ** `*var_ebcdic*` - Variable record size with 4-byte size field in EBCDIC code (including length field). * WINDOWS ** `**f**ix` - fixed record length ** `**dtext**` - variable record length with output record delimiter, last record                  without delimiter ** `**t**ext` - variable record length with output record delimiter ** `**v**ariable` - variable record length with a binary record length of 2 bytes ** `**var_2**b` - variable record length with a binary record length of 2 bytes ** `**var_4**b` - variable record length with a binary record length of 4 bytes (host:                   length of 2 bytes, padding is ignored) ** `**var_a**scii` - variable record length with a length field of 4 bytes in ASCII code ** `**var_e**bcdic` - variable record length with a length field of 4 bytes in EBCDIC code ** `**u**ndefined` - Records without structure. The records are written with length outrecsize *Default* * z/OS ** `VARBLK` or value from the file header. * UNIX ** none * WINDOWS ** none *Valid for* * decompression * `EAF - EAF data, variable record size with a 4-byte size field in ASCII or EBCDIC code. The record size only specifies the length of the data excluding the size field. The size field is part of the data` * `FIX - Fixed record length (in/out)recsize` * `DTEXT - Variable record length with end-of-record characters,  last record without delimiter` * `TEXT - Variable record length with end-of-record characters` * `STREAM - Variable record size (max. 2048 characters) with record delimiter. Typically text data` * `VARIABLE - Variable record size with 2-byte binary record size (including length field)` * `UNDEFINED - Records without structure; records with the length  inrecsize are read, last record may be shorter` * `U - Undefined (Host only)` * `F - Fix (Host only)` * `FIXBLK - Fix blocked (Host only)` * `FB - Fix blocked (Host only)` * `V - Variable (Host only)` * `VARBLK - Variable blocked (Host only)` * `VB - Variable blocked (Host only)` * `FIXS - Fix standard (Host only)` * `FBS - Fix standard (Host only)` * `VARSPAN - Variable spanned (Host only)` * `VBS - Variable spanned (Host only)` * `VAR_2B - Variable record size with 2-byte binary record size (including length field)` * `VAR2B_DATA - Variable record size with 2-byte binary record size (not including length field)` * `VAR_4B - Variable record size with 4-byte binary record size (including length field) (host)` * `VAR_ASCII - Variable record size with 4-byte size field in ASCII code (including length field)` * `VAR_EBCDIC - Variable record size with 4-byte size field in EBCDIC code (including length field)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-outrecsize_df03.html",
"OUTRECSIZE",
"[[CLEP.COMMAND.FLAM.OUTRECSIZE]] ==== OUTRECSIZE indexterm:[Parameter, OUTRECSIZE, FLAM.OUTRECSIZE] This parameter specifies the record size of the decompressed file. See also parameter <<CLEP.COMMAND.FLAM.OUTRECFORMAT,OUTRECFORMAT>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `ORECSIZE=n` ** `ORECS=n` *** Note: True length without record length field. This value must only     be specified if the record length differs from the original file. * UNIX ** `-outrecsize=n` *** Note: This parameter specifies the record size of the decompressed           files with a fixed or undefined record format. For other           record formats, this indicates the buffer size. * WINDOWS ** `outrecsize=nnn` ** *outrecs=nnn` *** Note: This parameter specifies the record length of the decompressed           files with record format 'fix' or 'undefined' resp. the maximum           record length. *Values* * z/OS ** 0-32760 * UNIX ** 1-32760 * WINDOWS ** 1-32760 *Default* * z/OS ** 32752 bytes or value from the file header * UNIX ** none * WINDOWS ** 512 *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-blksize_cdee.html",
"BLKSIZE",
"[[CLEP.COMMAND.FLAM.BLKSIZE]] ==== BLKSIZE indexterm:[Parameter, BLKSIZE, FLAM.BLKSIZE] Logical block length for compressed file/FLAMFILE (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `BLKSIZE=n` ** `BLKS=n` *** Note: This parameter is not necessary for catalogued files in z/OS.           A value of zero leads to a system determined blocksize. *Values* * z/OS ** 0-32760 *Default* * z/OS ** 0 bytes (leads to a system determined blocksize) *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-iblksize_17db.html",
"IBLKSIZE",
"[[CLEP.COMMAND.FLAM.IBLKSIZE]] ==== IBLKSIZE indexterm:[Parameter, IBLKSIZE, FLAM.IBLKSIZE] Logical block length for input files (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `IBLKSIZE=n` ** `IBLK=n` *** Note: This parameter is not necessary for catalogued files in z/OS. *Values* * z/OS ** 0-32760 *Default* * z/OS ** 32760 bytes *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-oblksize_41e1.html",
"OBLKSIZE",
"[[CLEP.COMMAND.FLAM.OBLKSIZE]] ==== OBLKSIZE indexterm:[Parameter, OBLKSIZE, FLAM.OBLKSIZE] Block length of the output file (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `OBLKSIZE=n` ** `OBLK=n` *** Note: A value of zero leads to a system determined blocksize for           the output data set. *Values* * z/OS ** 0-32760 *Default* * z/OS ** 0 +    A value of zero leads to a system determined blocksize for the output data set. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-attributes_3711.html",
"ATTRIBUTES",
"[[CLEP.COMMAND.FLAM.ATTRIBUTES]] ==== ATTRIBUTES indexterm:[Parameter, ATTRIBUTES, FLAM.ATTRIBUTES] This parameter has the effect that compression information are written into the FLAMFILE (UNIX and WINDOWS only). See also parameter <<CLEP.COMMAND.FLAM.HEADER,HEADER>> for z/OS. The insertion of compression information into the FLAMFILE allows a subsequent extraction of this information, without the necessity to totally decompress the FLAMFILE. In doing so, the file organization, the record format and the record length can be logged during compression. This is also true for the attribute under which operating system the compression has taken place (attributes=common). As result the decompressed file can be generated with the same characteristics during decompression, if necessary. The file specification of the original file may optionally be entered in addition (attributes=all). This option makes it possible to specify the output specification [ ] or [*] for decompression, with the result that FLAM will use the entered file specification and the related characteristics automatically. With attributes=none no information about the original file is written into the FLAMFILE at all. Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.HEADER,HEADER>> for z/OS. * UNIX ** `-attributes=attribute option` * WINDOWS ** `-attributes=attribute option` *Values* * UNIX / WINDOWS ** `none` - No file information. Corresponds z/OS: FILEINFO=NO and HEADER=NO. ** `common` -  Common file information. Corresponds z/OS: FILEINFO=NO and HEADER=YES. ** `all` - Common file information and system specific information            about the original file. Corresponds to z/OS: FILEINFO=YES and HEADER=YES. *Default* * none *Valid for* * compression * `NONE - No compression information` * `COMMON - Common compression information` * `ALL - General compression information and system specific information about the original file` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-option_6811.html",
"OPTION",
"[[CLEP.COMMAND.FLAM.OPTION]] ==== OPTION indexterm:[Parameter, OPTION, FLAM.OPTION] This parameter controls FLAM's behaviour when decompressed records are output (UNIX only). See also similar parameters for z/OS and WINDOWS: * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS and Windows * <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>> for notruncate in z/OS and Windows * <<CLEP.COMMAND.FLAM.SUPPRESS,SUPPRESS>> for suppress and trimchar in WINDOWS * <<CLEP.COMMAND.FLAM.NOSUPPRESS,NOSUPPRESS>> in WINDOWS * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for padchar in z/OS During the decompression, the record format and size of the decompressed file can either be specified explicitly or adopted from predecessor versions, so that the maximum record size is less than in the original file. If CUT option is specified, the decompression continues and any records which is too long is truncated to the maximum size. If `NOCUT` is specified, decompression is aborted and an error message is put out. If the decompressed file is written with the stream record format during the decompression procedure, whitespace at the end of a record can be suppressed by specifying suppress. Nosuppress causes the whitespace to be written. Syntax restrictions for FLAMv4 or older: * UNIX ** `-option=FLAM option` *Values* * UNIX ** `cut` - Records with a length greater than the maximum record size            are truncated. ** `nocut` - Records with a length greater than the maximum record size              are not truncated. ** `suppess` -  Blank space at the end of a record is suppressed. ** `nosuppess` -  Blank space at the end of a record is not suppressed. *Default* * none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-option-cut_9c76.html",
"CUT",
"[[CLEP.COMMAND.FLAM.OPTION.CUT]] ===== CUT indexterm:[Constant, CUT, FLAM.OPTION.CUT] Truncate output record (z/OS and WINDOWS only). Records with a record length longer than the maximum record length may be shortened. Syntax restrictions for FLAMv4 or older: * z/OS ** `TRUNCATE=NO/YES` ** `TRU=NO/YES` * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> * WINDOWS ** `cut` ** `truncate` (synonym for cut) ** `tru` +    Records with a record length longer than the maximum record    length may be shortened. +    See also parameter <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>>. *Values* * z/OS ** `NO` - No truncation. If records longer than specified occur,    decompression is aborted. ** `YES` - If a decompressed record is longer than specified for the    output file, the record is truncated. * WINDOWS ** none/no values *Default* * z/OS ** `TRUNCATE=NO` * WINDOWS ** none/no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-option-nocut_1bab.html",
"NOCUT",
"[[CLEP.COMMAND.FLAM.OPTION.NOCUT]] ===== NOCUT indexterm:[Constant, NOCUT, FLAM.OPTION.NOCUT] Records with a record length larger than the maximum record length are not cut/truncated (Windows only). Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for `TRUNCATE=NO` * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION, OPTION>> for `Option=nocut` * WINDOWS ** `nocut` ** `notruncate` (synonym for cut) ** `notr` (whitespace at the end of records are not suppressed) *Values* * WINDOWS ** none/no values *Default* * WINDOWS ** none/no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-option-suppress_e2f1.html",
"SUPPRESS",
"[[CLEP.COMMAND.FLAM.OPTION.SUPPRESS]] ===== SUPPRESS indexterm:[Constant, SUPPRESS, FLAM.OPTION.SUPPRESS] Blanks or other signs at the end of any record are be suppressed (Windows only). The character that is to be suppressed can also be specified with `<<CLEP.COMMAND.FLAM.TRIMCHAR,trimchar=characters>>`. If trimchar is not specified in addition to suppress, then the setting is `trimchar=20` (ASCII) or `trimchar=40` (EBCDIC), depending on the character set of the original data. With the specification <<CLEP.COMMAND.FLAM.TRIMCHAR, `trimchar=characters`>>, parameter `suppress` is  set automatically. Parameters in the same context: * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS * <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress and nosuppress on UNIX * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for PADCHAR in z/OS * <<CLEP.COMMAND.FLAM.TRIMCHAR,TRIMCHAR>> for trimchar in WINDOWS * <<CLEP.COMMAND.FLAM.NOSUPPRESS,NOSUPPRESS>> for nosuppress in WINDOWS Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress * WINDOWS ** `suppress` ** `su` +    See also parameter <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>>. *Values* * WINDOWS ** for suppress and su: none/no values. *Default* * WINDOWS ** for `suppress` and `su`:    `trimchar=20` (ASCII) or `trimchar=40` (EBCDIC),    depending on the character set of the original data. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-option-nosuppress_ea2e.html",
"NOSUPPRESS",
"[[CLEP.COMMAND.FLAM.OPTION.NOSUPPRESS]] ===== NOSUPPRESS indexterm:[Constant, NOSUPPRESS, FLAM.OPTION.NOSUPPRESS] Whitespace at the end of a record is not suppressed (Windows only). See also parameter <<CLEP.COMMAND.FLAM.SUPPRESS,SUPPRESS>>. NOTE: Specification of Parameter trimchar implicitly sets `suppress`,       see also parameter <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>>. Parameters in the same Context: * <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress and nosuppress on UNIX. * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS. * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for trimchar in WINDOWS and PADCHAR in z/OS. Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for `TRUNCATE` or `cut`. * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for `nosuppress`. * WINDOWS ** `nosuppress` ** `nos` +     Whitespace at the end of records is not suppressed.     See also parameters <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>> and <<CLEP.COMMAND.FLAM.CUT,CUT>>. *Values* * WINDOWS ** none/no values *Default* * WINDOWS ** none/no default *** Note: Specification of Parameter trimchar implicitly sets `suppress`.     See also parameter <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>>. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-cut_1658.html",
"CUT",
"[[CLEP.COMMAND.FLAM.CUT]] ==== CUT indexterm:[Parameter, CUT, FLAM.CUT] Truncate output record (z/OS and WINDOWS only). Records with a record length longer than the maximum record length may be shortened. Syntax restrictions for FLAMv4 or older: * z/OS ** `TRUNCATE=NO/YES` ** `TRU=NO/YES` * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> * WINDOWS ** `cut` ** `truncate` (synonym for cut) ** `tru` +    Records with a record length longer than the maximum record    length may be shortened. +    See also parameter <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>>. *Values* * z/OS ** `NO` - No truncation. If records longer than specified occur,    decompression is aborted. ** `YES` - If a decompressed record is longer than specified for the    output file, the record is truncated. * WINDOWS ** none/no values *Default* * z/OS ** `TRUNCATE=NO` * WINDOWS ** none/no default *Valid for* * decompression * `YES - Yes, do it` * `NO - No, don't do it` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-nocut_48ed.html",
"NOCUT",
"[[CLEP.COMMAND.FLAM.NOCUT]] ==== NOCUT indexterm:[Parameter, NOCUT, FLAM.NOCUT] Records with a record length larger than the maximum record length are not cut/truncated (Windows only). Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for `TRUNCATE=NO` * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION, OPTION>> for `Option=nocut` * WINDOWS ** `nocut` ** `notruncate` (synonym for cut) ** `notr` (whitespace at the end of records are not suppressed) *Values* * WINDOWS ** none/no values *Default* * WINDOWS ** none/no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-suppress_eb8b.html",
"SUPPRESS",
"[[CLEP.COMMAND.FLAM.SUPPRESS]] ==== SUPPRESS indexterm:[Parameter, SUPPRESS, FLAM.SUPPRESS] Blanks or other signs at the end of any record are be suppressed (Windows only). The character that is to be suppressed can also be specified with `<<CLEP.COMMAND.FLAM.TRIMCHAR,trimchar=characters>>`. If trimchar is not specified in addition to suppress, then the setting is `trimchar=20` (ASCII) or `trimchar=40` (EBCDIC), depending on the character set of the original data. With the specification <<CLEP.COMMAND.FLAM.TRIMCHAR, `trimchar=characters`>>, parameter `suppress` is  set automatically. Parameters in the same context: * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS * <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress and nosuppress on UNIX * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for PADCHAR in z/OS * <<CLEP.COMMAND.FLAM.TRIMCHAR,TRIMCHAR>> for trimchar in WINDOWS * <<CLEP.COMMAND.FLAM.NOSUPPRESS,NOSUPPRESS>> for nosuppress in WINDOWS Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress * WINDOWS ** `suppress` ** `su` +    See also parameter <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>>. *Values* * WINDOWS ** for suppress and su: none/no values. *Default* * WINDOWS ** for `suppress` and `su`:    `trimchar=20` (ASCII) or `trimchar=40` (EBCDIC),    depending on the character set of the original data. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-nosuppress_8eb0.html",
"NOSUPPRESS",
"[[CLEP.COMMAND.FLAM.NOSUPPRESS]] ==== NOSUPPRESS indexterm:[Parameter, NOSUPPRESS, FLAM.NOSUPPRESS] Whitespace at the end of a record is not suppressed (Windows only). See also parameter <<CLEP.COMMAND.FLAM.SUPPRESS,SUPPRESS>>. NOTE: Specification of Parameter trimchar implicitly sets `suppress`,       see also parameter <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>>. Parameters in the same Context: * <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress and nosuppress on UNIX. * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS. * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for trimchar in WINDOWS and PADCHAR in z/OS. Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for `TRUNCATE` or `cut`. * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for `nosuppress`. * WINDOWS ** `nosuppress` ** `nos` +     Whitespace at the end of records is not suppressed.     See also parameters <<CLEP.COMMAND.FLAM.NOCUT,NOCUT>> and <<CLEP.COMMAND.FLAM.CUT,CUT>>. *Values* * WINDOWS ** none/no values *Default* * WINDOWS ** none/no default *** Note: Specification of Parameter trimchar implicitly sets `suppress`.     See also parameter <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>>. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-padchar_4375.html",
"PADCHAR",
"[[CLEP.COMMAND.FLAM.PADCHAR]] ==== PADCHAR indexterm:[Parameter, PADCHAR, FLAM.PADCHAR] During the decompression procedure, the record format and size of the decompressed file can be specified explicitly, so that the record size is greater than in the original file. In this case, the records are padded to the specified length. Parameter `PADCHAR` is used in order to pad characters at the end of an output record. Syntax restrictions for FLAMv4 or older: * z/OS ** `PADCHAR=value` *** Note: This parameter is only used when an output record has           to be filled up during decompression (e.g. the original           variable record has to be converted to a fix output format). * UNIX ** `-pad_char=hexcode` * WINDOWS ** `padchar=pad character` ** `pad=pad character` *** Note: With `padchar=xx` the character is specified with which           - if necessary - the original record is padded. +           `padchar` is also used for padding the variable length           field of 4 bytes when using `outrecformat=var_4b`, see           parameter <<CLEP.COMMAND.FLAM.OUTRECFORMAT,OUTRECFORMAT>>. Values* * z/OS ** X'..' a hex value X'00' - X'FF' ** C'.' any character * UNIX ** Hexadecimal characters between 00 and ff. * WINDOWS ** Hexadecimal characters between 00 and FF. *Default* * z/OS ** X'40' * UNIX ** none/no default * WINDOWS ** none/no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-trimchar_4f40.html",
"TRIMCHAR",
"[[CLEP.COMMAND.FLAM.TRIMCHAR]] ==== TRIMCHAR indexterm:[Parameter, TRIMCHAR, FLAM.TRIMCHAR] Characters are suppressed at the end of record in case of decompression and text record formats (WINDOWS only). `trimchar` refers to the character in the original character set. With the specification `trimchar=characters`, `suppress` is set automatically. Parameters in the same context: * <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate in z/OS * <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress and nosuppress on UNIX * <<CLEP.COMMAND.FLAM.PADCHAR,PADCHAR>> for PADCHAR on z/OS * <<CLEP.COMMAND.FLAM.SUPPRESS,SUPPRESS>> for suppress on WINDOWS * <<CLEP.COMMAND.FLAM.NOSUPPRESS,NOSUPPRESS>> for nosuppress on WINDOWS Syntax restrictions for FLAMv4 or older: * z/OS ** see parameter <<CLEP.COMMAND.FLAM.CUT,CUT>> for truncate * UNIX ** see parameter <<CLEP.COMMAND.FLAM.OPTION,OPTION>> for suppress * WINDOWS ** `trimchar=characters` ** `tri=characters` *** Note: trimchar refers to the characters in the original character           set of the input file(s) which should be suppressed at the end           of every record. *Values* * WINDOWS ** for trimchar and tri: hex value 00 to FF. *Default* * WINDOWS ** for `trimchar` and `tri`: +    If the original data is in ASCII, then the setting is    `trimchar=20` (ASCII space). +    If the original data is in EBCDIC, then the setting is    `trimchar=40` (EBCDIC space). +    If <<CLEP.COMMAND.FLAM.TRANSLATE,translate>>=e/a is specified for    decompression and the translation table for space is 40:20,    then the setting is trimchar=40. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-maxbuffer_dba0.html",
"MAXBUFFER",
"[[CLEP.COMMAND.FLAM.MAXBUFFER]] ==== MAXBUFFER indexterm:[Parameter, MAXBUFFER, FLAM.MAXBUFFER] During compression with modes cx7, cx8, and vr8 FLAM reserves the matrix buffer for the temporary storage of the records from the original file. Please note that a matrix buffer of the same size has to be available during decompression, too. This is also the case when the decompression is done on other systems. Parameter MAXBUFFER specifies the maximum size of used matrix buffer. The information about `MAXBUFFER` is stored in the FLAMFILE, so it is well known during decompression. During compression FLAM reserves the matrix buffer for the temporary storage of the records from the original file. Please note that a matrix buffer of the same size has to be available during decompression, too. This is also the case when the decompression is done on other systems. Syntax restrictions for FLAMv4 or older: * z/OS ** `MAXBUFFER=n` ** `MAXB=n` *** Note: Used for CX7, CX8 and VR8 only. +     Regarding ADC, NDC and AES this parameter is not used. In     this case selection is always a buffer of 64KB. * UNIX ** -maxbuffer=n *** Note: Used for modes CX7, CX8 and VR8 only. +     With mode adc, this parameter has no effect. * WINDOWS ** maxbuffer=n *** Note: Used for modes CX7, CX8 and VR8 only. +     Regarding ADC, NDC and AES this parameter is not used.     In this case selection is always a buffer of 64KB. *Values* * z/OS ** There are three groups of values with differing meaning *** Values between 0 and 7 map to these fixed sizes: **** 0 = 32 KiB **** 1 = 16 KiB **** 2 = 32 KiB **** 3 = 64 KiB **** 4 = 128 KiB **** 5 = 256 KiB **** 6 = 512 KiB **** 7 = 1024 KiB *** Values between 8 and 2047 are in KiB and are rounded upwards     to a value of the following list: **** 2, 4, 6, 8, 10, 12, 14, 16, 32, 48, 64, 80, 96 **** 112, 128, 144, 176, 224, 256, 288,  320, 352 **** 384, 416, 512, 640, 768, 896, 1024, 1536, 2048 *** Values from 2048 are in bytes. +     This value is rounded upwards by KiB according to     the following list or is rounded downwards to 2560 KiB: **** 8, 10, 12, 14, 16, 32, 48, 64, 80, 96 **** 112, 128, 144, 176, 224, 256, 288,  320, 352 **** 384, 416, 512, 640, 768, 896, 1024, 1536, 2048 * UNIX / WINDOWS ** Integer number between 1 and 2,621,440. +   Values n, where 0<n<2,560 are interpreted as a number of   KiB (1 KiB = 1,024 bytes), while higher values are   interpreted as a number of bytes. FLAM chooses the nearest   equal or value value (in KiB) from the list below: *** 2, 4, 6, 8, 10, 12, 14, 16, 32, 48, 64, 80, 96 *** 112, 128, 144, 176, 224, 256, 288,  320, 352, 384 *** 416, 512, 640, 768, 896, 1024, 1536, 2048, 2560 *Default* * z/OS ** 64 kByte * UNIX ** none * WINDOWS ** for CX7, CX8 and VR8: none ** for ADC, NDC and AES: Parameter is not used. Selection is always a buffer of 64KB. *Valid for* * compression, mode=cx7,cx8,vr8 NOTE: ADC/NDC use 64 kb, unchangeable. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-maxrecords_c960.html",
"MAXRECORDS",
"[[CLEP.COMMAND.FLAM.MAXRECORDS]] ==== MAXRECORDS indexterm:[Parameter, MAXRECORDS, FLAM.MAXRECORDS] Maximum number of records for compression in one matrix. FLAM buffers records in the matrix buffer up to the specified number and compresses them. This specified number may occasionally not be reached if the matrix buffer is too small for the full number of records. The compression efficiency generally increases with the number of records. If -maxrecords=1, the compression is sequential and record-oriented. Syntax restrictions for FLAMv4 or older: * z/OS ** `MAXRECORDS=n` ** `MAXR=n` * UNIX ** `-maxrecords=n` * WINDOWS ** `maxrecords=n` *Values* * 1 - 255  for mode CX7/CX8/VR8, see parameter <<CLEP.COMMAND.FLAM.MODE,MODE>> * 1 - 4095 for mode ADC, see parameter <<CLEP.COMMAND.FLAM.MODE,MODE>> ** Note: With modes cx7, cx8, and vr8, up to 255 records are     stored in one matrix. If a higher value is specified it takes     effect only with mode adc. *Default* * z/OS **  255 for mode CX7/CX8/VR8 ** 4095 for mode ADC * UNIX ** none * WINDOWS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-flamcode_a5d9.html",
"FLAMCODE",
"[[CLEP.COMMAND.FLAM.FLAMCODE]] ==== FLAMCODE indexterm:[Parameter, FLAMCODE, FLAM.FLAMCODE] This parameter specifies the character set which is to be used to represent charactercoded information in the FLAMFILE during the compression procedure, such as the filename and control characters. In adc, cx8, and vr8 modes, this only concerns the information contained in the FLAM file header, such as the original filename and a few control characters, since the compressed file is represented in binary form. In cx7 mode, all FLAM control characters in the compressed file (FLAMFILE) are also coded in this character set. The characters extracted from the original data, however, remain unaffected in all modes. Their translation can be achieved by the translate parameter, see parameter <<CLEP.COMMAND.FLAM.MODE,MODE>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `FLAMCODE=EBCDIC/ASCII` ** `FLAMC=EBCDIC/ASCII` *** Note: If the original data is in ASCII character code, a           better compression ratio is obtained using `FLAMCODE=ASCII`. * UNIX ** `-flamcode=character set` * WINDOWS ** `-flamcode=character set` *Values* * z/OS ** `EBCDIC` for FLAM syntax in EBCDIC code. ** `ASCII` for FLAM syntax in ASCII code. * UNIX / WINDOWS ** `ebcdic` for FLAM syntax in EBCDIC code. ** `ascii`  for FLAM syntax in ASCII code. *Default* * z/OS ** `EBCDIC` * UNIX ** none * WINDOWS ** none *Valid for* * compression * `SYSTEM - System specific encoding` * `ASCII - String encoding in ASCII` * `EBCDIC - String encoding in EBCDIC` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-kmdll_2b90.html",
"KMDLL",
"[[CLEP.COMMAND.FLAM.KMDLL]] ==== KMDLL indexterm:[Parameter, KMDLL, FLAM.KMDLL] With the parameter kmdll the name of a dynamically loadable library is specified (Windows only). Availability FLAM Version 4.1: This library establishes the communication to a key management system,  e.g. FKMS FLAM KEYMANAGEMENT SYSTEM. The extension .dll may be omitted. If the DLL is not located in the search path of the operating system, the filename must be specified in a fully qualified manner. Parameters in the same context: <<CLEP.COMMAND.FLAM.KMEXIT,KMEXIT>> and <<CLEP.COMMAND.FLAM.KMPARAMETER,KMPARAMETER>> Syntax restrictions for FLAMv4 or older: * WINDOWS ** `kmdll=nameOfKmDll` *Values* * WINDOWS ** character set = ebcdic for FLAM syntax in EBCDIC code. ** character set = ascii  for FLAM syntax in ASCII code. *Default* * WINDOWS ** `kmdll=flamkme.dll` *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-kmexit_2dbc.html",
"KMEXIT",
"[[CLEP.COMMAND.FLAM.KMEXIT]] ==== KMEXIT indexterm:[Parameter, KMEXIT, FLAM.KMEXIT] Activates the key management exit. This user exit is an interface to a special (e.g. user written) key management system. On encryption, parameters (KMPARM=...) are passed to the module. It returns a key for encryption of the FLAMFILE and a string up to 512 byte. These data are stored in the FLAMFILE as an user header (see parameter `COMMENT` or function `FLMPUH`). On decryption, parameters (`KMPARM=...`) and the data stored in the user header are passed to the exit. The module returns the same key as on encryption. + It is up to the module, how to create a key and what kind of information are to be stored into the  user header of the FLAMFILE. These data will help the module to find the correct key on decryption. The exit is activated via the parameter KMEXIT=<name>. The user exit module must be contained in the library that has been assigned with the STEPLIB command (z/OS only). This parameter `-kmexit=[(]func[([lib])[exparm]][)]` specifies a user exit routine for automatic key management. With this parameter, FLAM is told the name of a function it has to invoke in order to receive a password needed for encryption or decryption of a file. This function must reside in a shared library (file type .so) the name of which may be specified after the function name. After the library name, an alphanumeric string may be appended that will be passed as a parameter string to the invoked function. With the parameter kmexit the name of the procedure that is to be used from the library is specified for automatic key management. Parameters in the same context: <<CLEP.COMMAND.FLAM.KMPARAMETER,KMPARAMETER>> and <<CLEP.COMMAND.FLAM.KMDLL,KMDLL>> *Value* * z/OS ** `KMEXIT=name` or `KME=name` of the module +    Max. 8 characters for name of the module, free choice. +    The module is loaded dynamically.. * Unix, FLAM command ** `-kmexit=exit specification` *** exit specification has the general form: [(]func[([lib])[exparm]][)] *** With this parameter, FLAM is told the name of a function     it has to invoke in order to receive a password needed for     encryption or decryption of a file. This function must     reside in a shared library (file type .so) the name of which     may be specified after the function name. After the library     name, an alphanumeric string may be appended that will be     passed as a parameter string to the invoked function.           supplies  the  password  (key)  needed  for           en/decryption.           containing func. When lib is omitted, FLAM loads the function           from `libflamkm.so` which it expects to find in directory           $FLAM_PATH/../lib when that environment variable is defined,           or otherwise in /usr/lib. +            *Note:*  When entered in a shell command, each            parenthesis must be preceded by an escape character            (\\) to avoid it being interpreted by the shell.            Escape characters are not required in parameter Files.             to the password function func. It must not contain             space characters or parentheses. If it contains             commas, the entire  Exit specification must be             enclosed in parentheses. exparm must always be             preceded by a pair of parentheses which may be             empty when lib is omitted. * Unix, Programming Key Exit ** -kmfunc +    The user exits for automatic key management can be    activated via the subprogram interface flamup and - in    contrast to the access exits - through the flam command, but    not through the record interface flamrec.    This user exit can be used at encryption or decryption    to provide a password automatically. It is activated by    the parameter -kmexit=exit specification in the flam    command or in the  parameter_string  argument of the    subprogram call flamup. The actual name used instead of    kmfunc may be any valid function name.    It sends a return code when it returns control to FLAM. *** Syntax restrictions for FLAMv4 or older +               `void kmfunc(signed long *functioncode,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}signed long *returncode,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}const unsigned long *parmlen,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}const unsigned char *param,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned long *datalen,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned char *data,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned long *ckylen,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned char *cryptokey,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned long *msglen,` +               `{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}{nbsp}unsigned char *message);` + *** Arguments **** `functioncode` +      This argument transfers a function code to the user exit.      The valid values are as follows: ***** -1 call for version identification ***** 0 call for decryption ***** 1 call for encryption **** `returncode` +      The user exit sends a return code to FLAM with this      argument; 0 = Success, otherwise Error. **** `parmlen` +      When functioncode is 0 or 1, this argument contains the      byte length of the data in the param argument. That may      be an integer value between 0 and 256. **** `param` +      When parmlen > 0, this argument contains the exparm-      part of the exit specification in the -kmexit parameter. **** `datalen` +      When functioncode is 0 or 1, this argument contains the      byte length of the data in the data argument. That may be      an  integer  value  between  0  and  512. For calls for      encryption, it is set by the exit routine. For calls for      decryption, it is set by FLAM. **** `data` +      When datalen > 0 with calls for encryption (functioncode 1),      the exit routine returns here the data required for retrieving      the  password needed  for  decryption. FLAM stores these data      in a user-specific FLAM file header. With calls for decryption      (functioncode 0), FLAM returns here these data to the exit routine. **** `ckylen` +      After a successful call to the exit routine with      functioncode 0 or 1, this argument contains the byte      length of the password returned to FLAM in the cryptokey      argument.      Maximum key length is 64 bytes. **** `cryptokey` +      In this argument, FLAM  receives after exit calls with      functioncode 0  or  1  the  password  for  encryption      or decryption with the length specified in ckylen. **** `msglen` +      Upon return to FLAM, this argument indicates the byte      length of the string in the message argument. Maximum is      128 bytes. **** `message` +      The exit routine may put here a message text which will      be output to the log file by FLAM * Windows ** `kmeexit=nameOfKmProcedure` +    With the parameter kmexit the name of the procedure    that is to be used from the library is specified. *Default* * No default value can be set for -kme user exit. *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-kmparameter_c9b3.html",
"KMPARAMETER",
"[[CLEP.COMMAND.FLAM.KMPARAMETER]] ==== KMPARAMETER indexterm:[Parameter, KMPARAMETER, FLAM.KMPARAMETER] Parameter used for the KMEXIT (z/OS and WINOWS only). The string that is specified with KMPARM is passed to the key management procedure used in context with Parameter KMEXIT. NOTE: This parameter overwrites parameter <<CLEP.COMMAND.FLAM.COMMENT,COMMENT>>       in z/OS, if present. Parameters in the same context: <<CLEP.COMMAND.FLAM.KMEXIT,KMEXIT>> and <<CLEP.COMMAND.FLAM.KMDLL,KMDLL>> Syntax restrictions for FLAMv4 or older: * z/OS ** `KMPARM=any input` up to 256 characters in form of    A'...', C'...', X'...', or as a string. ** `KMP=any input` up to 256 characters in form of    A'...', C'...', X'...', or as a string. * UNIX ** see parameter <<CLEP.COMMAND.FLAM.KMEXIT,KMEXIT>> * WINDOWS ** `kmparam=parameter string` *Values* * z/OS ** Any input up to 256 characters in form of    A'...', C'...', X'...', or as a string. * WINDOWS ** string *Default* * none, no parameter *Valid for* * en-/decryption ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-header_ca1d.html",
"HEADER",
"[[CLEP.COMMAND.FLAM.HEADER]] ==== HEADER indexterm:[Parameter, HEADER, FLAM.HEADER] Controls file header entries in the FLAM file (z/OS only). See also parameter <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>> for UNIX and WINDOWS. NOTE: The header consists of three parts. The *first part* is independent from the operating system and contains file attributes that are compatible. The second part depends on the operating system and contains file attributes specific to the according operating system. The third part is optional and contains the filename when specified with the parameter FILEINFO. FLAM and FLAMUP evaluate the file header in order to create a file with the most similar characteristics. The simplest case is when the file is reconstructed in the original system environment. In this case, the second (operating system specific) part of the file header can be used. In all other cases only the first part can be used and the system neutral attributes are mapped on system specific attributes of the target environment. Syntax restrictions for FLAMv4 or older: * z/OS ** `HEADER=YES/NO` ** `HE=YES/NO` * UNIX / Windows ** See parameter <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>>    for `-attribute=attribute` option.    This parameter causes original file information to be entered    in the FLAMFILE header. *Values* * z/OS ** `YES` - Create file header ** `NO` - Don't create file header * UNIX / Windows ** `-none` - No information about the original file is entered in the             FLAMFILE. +             Corresponds z/OS: `FILEINFO=NO` and `HEADER=NO`. ** `common` - The organization, the record format and the record size of               the original file can be saved during the compression               procedure, together with a flag which identifies the               operating system in which the compression took place. +               Corresponds z/OS: `FILEINFO=NO` and `HEADER=YES`. ** `all` - Common file information and system-specific information            about the original file. +            Corresponds z/OS: `FILEINFO=YES` and `HEADER=YES`. *Default* * z/OS ** `YES` * UNIX ** should be set to `-attributes=all` * WINDOWS ** should be set to `attributes=all` *Valid for* * compression * `YES - Yes, do it` * `NO - No, don't do it` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-comment_cb6d.html",
"COMMENT",
"[[CLEP.COMMAND.FLAM.COMMENT]] ==== COMMENT indexterm:[Parameter, COMMENT, FLAM.COMMENT] With the parameter comment/label comments can be made and will be stored in the user header of the FLAMFILE during compression. These data are protocolled during decompression (z/OS and WINDOWS only). NOTE: Comments in ASCII in the FLAMFILE are translated to       EBCDIC for the output message with the internal A/E       translation table during decompression. Entering a       <<CLEP.COMMAND.FLAM.TRANSLATE,TRANSLATE>> parameter causes FLAM to use       this table. Nondisplaying characters are visualized by dots '.'. +       The FKMS uses the USER header itself. If key management is       called by parameter <<CLEP.COMMAND.FLAM.KMEXIT,KMEXIT>>,       additional data is stored as comment in the FLAMFILE during       encryption, sent to the exit for decryption (please, don't use       the parameters `COMMENT` and `KMEXIT` at the same time!). Syntax restrictions for FLAMv4 or older: * z/OS ** `COMMENT=string` ** `COMM=string` * WINDOWS ** `label=string` ** `la=string` *Values* * z/OS ** 1 - 256 characters starting with A'...', C'...', X'...' or a string.    Using A'..' all characters are translated to ASCII with the internal    translation table A/E (ch. A). * WINDOWS ** string *Default* * No comment *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-msgfile_ad4f.html",
"MSGFILE",
"[[CLEP.COMMAND.FLAM.MSGFILE]] ==== MSGFILE indexterm:[Parameter, MSGFILE, FLAM.MSGFILE] This parameter can be used to redirect FLAM message output to a file. FLAM messages are output to stderr which is generally the user's screen when working interactively. With this parameter output can be sent to a file to act as a permanent copy for documenting the compression procedure. This is important for batch processing, for example. However, logging in the message file does not begin until after the syntax and compatibility of the FLAM settings specified in the command have been checked. Error messages concerning syntax errors, missing files or invalid settings are not logged. In such cases, FLAM stops processing without creating a message file Syntax restrictions for FLAMv4 or older: * z/OS ** `MSGFILE=file name` ** `MSGF=file name` * UNIX ** `-msgfile=message file name` * WINDOWS ** `msgfile=message file name` ** `ms=message file name` ** `logfile=message file name` ** `log=message file name` *Values* * z/OS ** File name with max. 54 characters. * UNIX ** This specifies a file to which the FLAM messages must be written. * WINDOWS ** Name of the file to which the FLAM messages are to be written. *** Note: Generally the log file is opened with 'append'. +     It is possible to have the log file created on the command line by     the operating system: +     `flam4 param1 param2 param3  2>LOGFILE`. +     The  redirection of STDERR instead of the specification     msgfile=<name> has the advantage that all messages are written     to the redirected file immediately. Otherwise the messages are not     written to the specified file until the parameter msgfile is     interpreted. *Default* * z/OS ** no name * UNIX ** none * WINDOWS ** none *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-secureinfo_a7c9.html",
"SECUREINFO",
"[[CLEP.COMMAND.FLAM.SECUREINFO]] ==== SECUREINFO indexterm:[Parameter, SECUREINFO, FLAM.SECUREINFO] Additional information stored in the FLAMFILE. Increasing the security of data. Changing the FLAMFILE (in any way) leads to a decompression error. NOTE: Concatenation of 'secure' FLAMFILEs lead to secure violations! +       `SECUREINFO=YES` needs `MODE=ADC` or `NDC`. Syntax restrictions for FLAMv4 or older: * z/OS ** `SECUREINFO=secure option` ** `SEC=secure option` * UNIX ** -FLAMFILE is secure automatically, if encrypted with AES * WINDOWS ** `secureinfo=secure option` ** `sec=secure option` *** Note: Only in modes ADC, NDC, AES. +     AES-encrypted data is always generated with secure information. *Values* * z/OS ** `YES` - create these information (default on encryption) on compression ** `NO` - do not store any additional data ** `IGNORE` - ignore any security violations on decompression ** `MEMBER` - only member-specific security information are verified on               decompression, not the entire FLAMFILE *** Note: Concatenation of 'secure' FLAMFILEs lead to secure violations! +           `SECUREINFO=YES` needs `MODE=ADC` or `NDC`. * WINDOWS ** `**y**es` - generate resp. check secure information (default) ** `**n**o` - do not generate secure information   resp. ignore secure information *Default* * z/OS **  `NO` **  `YES` (in case of `MODE=ADC`) * WINDOWS ** YES, default on encryption *** Note: AES-encrypted data are always generated with secure information. *Valid for* * compression * decompression * `YES - Create secure information at compression` * `NO - Do not store any additional secure information` * `IGNORE - Ignore any security violations on decompression` * `MEMBER - Only member-specific security information is verified` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-msgdisp_b6a1.html",
"MSGDISP",
"[[CLEP.COMMAND.FLAM.MSGDISP]] ==== MSGDISP indexterm:[Parameter, MSGDISP, FLAM.MSGDISP] With parameter MSGDISP it is possible to control the output medium for messages (z/OS only). The FLAM protocol is principally stored into a file if no other instructions are given by parameter MSGDISP. All messages are written by default into a message file: or NOTE: If no file is specified despite the fact that the parameter       `MSGDISP=MSGFILE` is set, a message is written to the console via       `WTO, ROUTCDE=11` and the  program is terminated with a       condition code (`WTO=Write-To-Operator`). +       Parameters in the same context:       <<CLEP.COMMAND.FLAM.MSGFILE,MSGFILE>> and <<CLEP.COMMAND.FLAM.MSGDDN,MSGDDN>> Syntax restrictions for FLAMv4 or older: * z/OS ** `MSGDISP=TERMINAL/MSGFILE/SYSTEM` ** `MSGD=TERMINAL/MSGFILE/SYSTEM` *Values* * z/OS ** `MSGDISP=TERMINAL` +    Currently not supported. ** `MSGDISP=MSGFILE` +    The messages are written into a catalogued file. The DD-NAME of this    file is `FLPRINT` by default and can be modified using parameter `MSGDDN=<name>`. ** `MSGDISP=SYSTEM` +    Output on console with WTO, ROUTCDE=11. *Default* * z/OS **  `MSGDISP=MSGFILE` *Valid for* * compression * decompression * `TERMINAL - Log to a stream` * `MSGFILE - Log to a flat file` * `SYSTEM - Use system logging facility` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-show_6311.html",
"SHOW",
"[[CLEP.COMMAND.FLAM.SHOW]] ==== SHOW indexterm:[Parameter, SHOW, FLAM.SHOW] This parameter specifies which information should be shown in the FLAM control protocol. This parameter corresponds to parameter <<CLEP.COMMAND.FLAM.INFO,INFO>>. This parameter controls the information output by FLAM. You can choose between detailed information (all), error messages and warnings either with or without statistics (error or statistics) and no information (none). During the decompression procedure, you can decide just to show the information about the original file, without creating a decompressed file. Use `show=attributes` to do so. If the FLAMFILE contains compressed versions of several files, the information about each of the original files is shown one file at a time. However, this information is only shown, if this was specified when the files were compressed into the FLAMFILE (see parameter <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>>). If `-show=attributes` is specified, parameter <<CLEP.COMMAND.FLAM.FLAMOUT,FLAMOUT>>  is ignored. Syntax restrictions for FLAMv4 or older: * z/OS ** `SHOW=ALL/NONE/ATTRIBUT/ERROR/DIR` ** `SH=ALL/NONE/ATTRIBUT/ERROR/DIR` * UNIX ** `-show=none/all/attributes/error/statistics` * WINDOWS ** `show=none/all/attributes/error/statistics` ** `sh=none/all/attributes/error/statistics` *Values* * z/OS ** `ALL` - All messages and statistics - generate and display. ** `NONE` - Don't display messages. ** `ATTRIBUT` - Display the parameters for compression or decompression                 but do not execute processing. ** `ERROR` - Display error messages and end-of-program message only. ** `DIR` - The names of all files (and their attributes) that are to be            processed are listed. * UNIX ** `none` - No information is shown. ** `all` - All the available information is shown. This depends on the            invoked operation (compress or decompress), but not on whether            FLAM was invoked directly or using the parameter file. *** The following information is shown during the compression procedure: **** FLAM version **** FLAM settings ***** Operation (compress) ***** Code table ***** Compression mode ***** Matrix buffer size ***** Maximum number of records/matrix buffer ***** Character set (ASCII or EBCDIC) ***** attributes setting **** Name of the original file **** Formatting information for the original file **** Name of the compressed file (FLAMFILE) **** Formatting information for the compressed file **** Statistical information (see show=statistics) **** Error messages and warnings *** The following information is shown during the decompression procedure: **** FLAM version **** FLAM settings: ***** Operation (decompress) ***** Code table (only if the FLAM call includes the necessary specifications) **** Name of the compressed file (FLAMFILE) **** Name of the decompressed file **** Formatting information for the decompressed file **** Saved compression information (see `show=attributes`) **** Statistical information (see `show=statistics`) **** Error messages and warnings ** `attributes` - (Decompression only) +    This suppresses creation of the decompressed file. +    Only the saved compression information is shown: *** Name of the original file (only if  `-attributes=all` was     specified when it was compressed). *** Formatting information for the original file. *** Compression mode. *** Character set (ASCII or EBCDIC). *** System which created the FLAMFILE. ** `error` - Only error messages and warnings are shown. ** `statistics` - Error messages, warnings and the following statistics are     shown: *** Number of compressed records *** Number of compressed bytes *** Number of non-compressed records *** Number of non-compressed bytes *** Compression efficiency as compared with the original file (compression only) +     This efficiency is the ratio of the number of bytes     actually read to the number of bytes output and is     specified as a percentage. Record size fields, record     delimiters and characters for padding compressed records     are not taken into account ** Note: Message outputs can be redirected to a file by specifying          `2>>filename`. If `-msgfile=filename` is specified, on the other          hand, the FLAM messages are written into a file, but          system messages continue to be displayed on the screen. * WINDOWS ** `none` - no display. ** `all` - Shows all of the information available. The information    depends on the invoked operation, compression or decompression,    but not on the circumstance if FLAM was called directly or with a    parameter file. ** `attributes` - decompression only +    suppresses the creation of the decompressed file. +    only shows the saved compression information: *** name of the original file (only if compressed with `attributes=all`) *** format specifications of the original file *** compression mode *** character set ASCII or EBCDIC **** system which generated the FLAMFILE ** `error` - only shows error and warning messages. ** `statistics` - shows error and warning messages plus the    number of compressed records. *Default* * z/OS ** ALL * UNIX ** none (No information is shown/no display) * WINDOWS ** none (No information is shown/no display) *Valid for* * compression * decompression * `ALL - Print messages and statistics (default)` * `DIR - Printouts of file names but no processing` * `ATTRIBUTE - Printouts but no processing` * `ERROR - Only errors and error trace are logged` * `NONE - No logging` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-info_e964.html",
"INFO",
"[[CLEP.COMMAND.FLAM.INFO]] ==== INFO indexterm:[Parameter, INFO, FLAM.INFO] This parameter specifies which information should be shown in the FLAM control protocol (z/OS only). INFO has been replaced by the more powerful parameter <<CLEP.COMMAND.FLAM.SHOW,SHOW>>. Note: The INFO parameter should be contained in the first input line.       Otherwise it has no effect on displaying the parameter inputs.       The statistics inform about elapsed time and CPU time needed.       Also the number of bytes and records for both input and output is       computed. If relative files are decompressed the number of       records after the removal of gaps is computed in addition. For       conversion into fixed record format the resulting number of       bytes is displayed. Syntax restrictions for FLAMv4 or older: * z/OS ** `INFO=YES/NO/HOLD` ** `I=YES/NO/HOLD` *Values* * z/OS ** `YES` - Messages and statistics - generate and display. ** `NO` - Don't display messages. ** `HOLD` - Display the parameters for compression or decompression             but do not execute compression or decompression. *Default* * z/OS ** `YES` *Valid for* * compression * decompression * `YES - Print messages and statistics (default)` * `NO - No printouts but processing` * `HOLD - Printouts but no processing` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-checkall_3d33.html",
"CHECKALL",
"[[CLEP.COMMAND.FLAM.CHECKALL]] ==== CHECKALL indexterm:[Parameter, CHECKALL, FLAM.CHECKALL] The parameter CHECKALL supports complete testing of a FLAMFILE _including_ decompression and possibly decryption, but without file output (z/OS only). CHECKALL is a short form for <<CLEP.COMMAND.FLAM.DECOMPRESS,DECOMPRESS>>, <<CLEP.COMMAND.FLAM.FLAMOUT,FLAMOUT>>=*DUMMY, <<CLEP.COMMAND.FLAM.SHOW,SHOW>>=ALL. NOTE: If the FLAMFILE has been encrypted, the key must be specified for       decryption. See also parameters <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>,       <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY/cryptkey>>,       <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>, <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>> or       <<CLEP.COMMAND.FLAM.PAASCII,PAEBCDIC>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `CHECKALL` ** `CHECKA` *Values* * z/OS ** No values *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-checkfast_35ee.html",
"CHECKFAST",
"[[CLEP.COMMAND.FLAM.CHECKFAST]] ==== CHECKFAST indexterm:[Parameter, CHECKFAST, FLAM.CHECKFAST] The parameter is checking a FLAMFILE for integrity and completeness _without_ decompression but possibly with decryption (z/OS only). CHECKFAST is a short form for <<CLEP.COMMAND.FLAM.DECOMPRESS,DECOMPRESS>>, <<CLEP.COMMAND.FLAM.SHOW,SHOW>>=DIR. NOTE: If the FLAMFILE has been encrypted, the key must be specified for decryption.       See also parameters <<CLEP.COMMAND.FLAM.PASSWORD,PASSWORD>>,       <<CLEP.COMMAND.FLAM.CRYPTOKEY,CRYPTOKEY or cryptkey>>,       <<CLEP.COMMAND.FLAM.PAXWORD,PAXWORD>>,       <<CLEP.COMMAND.FLAM.PAASCII,PAASCII>> or       <<CLEP.COMMAND.FLAM.PAASCII,PAEBCDIC>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `CHECKFAST` ** `CHECKF` *Values* * z/OS ** No values *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-help_588b.html",
"HELP",
"[[CLEP.COMMAND.FLAM.HELP]] ==== HELP indexterm:[Parameter, HELP, FLAM.HELP] * z/OS ** If the HELP function is requested in the first input line, the generated     FLAM parameters and their values are displayed and the program is terminated     without doing compression, decompression or encrypting. * UNIX ** The parameter `-list` permits a list of the installation-specific    default values to be output. * WINDOWS ** It is possible to display the installation specific standard settings    on screen with the parameter 'list'. Syntax restrictions for FLAMv4 or older: * z/OS ** `HELP` *** Note: If the Help function is requested in the first input           line, the generated FLAM parameters and their values           are output and the program is terminated. * UNIX ** `-list[=list specification]` *** Note: With the list parameter the installation-specific           default values can be displayed. +           When a list specification is supplied, the current           setting of default value for the respective parameter is           displayed. +           When list specification is omitted, a list of all           current values is displayed except the code tables for           ASCII-EBCDIC and EBCDIC-ASCII translations. Also, the           FLAM version and its creation date are displayed. * WINDOWS ** `list` *** Note:  Output of default values to a file is possible with command:            `flam4 list 2>FILE` *Values* * z/OS ** No values * UNIX ** list specification =  Any flam parameter for which a default value can be set. * WINDOWS ** No values *Default* * none *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-fileinfo_c50e.html",
"FILEINFO",
"[[CLEP.COMMAND.FLAM.FILEINFO]] ==== FILEINFO indexterm:[Parameter, FILEINFO, FLAM.FILEINFO] Transfers filename of original file into file header (z/OS only). Parameters in the same context: <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>> for UNIX and WINDOWS, <<CLEP.COMMAND.FLAM.HEADER,HEADER>>  for z/OS. Syntax restrictions for FLAMv4 or older: * z/OS ** `FILEINFO=YES/NO` ** `FI=YES/NO` * UNIX / WINDOWS ** See parameter <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>> for    `-attribute=attribute` option. This parameter causes original file    information to be written to the FLAMFILE header. *Values* * z/OS ** `YES`  -Transfer file name of original file into/out of FLAM file header. ** `NO` - Don't transfers filename (when compressing).           On decompression, a filename is generated (FILE0001-FILE9999)           which can be used for conversion rules. * UNIX / WINDOWS ** `none` - No information about the original file is written to the FLAMFILE.             Corresponds z/OS: `FILEINFO=NO` and `HEADER=NO`. ** `common`  - The organization, the record format and the record size of                the original file can be saved during the compression                procedure, together with a flag which identifies the                operating system in which the compression took place. +                Corresponds z/OS: `FILEINFO=NO` and `HEADER=YES`. ** `all`  - Common file information and systemspecific information             about the original file. +             Corresponds z/OS: `FILEINFO=YES` and `HEADER=YES`. *Default* * z/OS ** `YES` * UNIX / WINDOWS ** should be set to `-attributes=all` *Valid for* * compression * decompression * `YES - Yes, do it` * `NO - No, don't do it` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-codetable_dbd7.html",
"CODETABLE",
"[[CLEP.COMMAND.FLAM.CODETABLE]] ==== CODETABLE indexterm:[Parameter, CODETABLE, FLAM.CODETABLE] If code translation has been activated, the specified code table is used (WINDOWS only). The first 256 characters refer to the function translate=e/a. The characters 257 - 512 refer to the function translate=a/e. If the file has only 256 characters, these characters will be used for e/a and a/e as well. In this way, a table can serve as conversion tool for lowercase to uppercase letters or for the adjustment of umlauts, e.g. OEM<>ANSI. Parameters in the same context: <<CLEP.COMMAND.FLAM.TRANSLATE,TRANSLATE>> for UNIX, WINDOWS and z/OS. Syntax restrictions for FLAMv4 or older: * z/OS ** see <<CLEP.COMMAND.FLAM.TRANSLATE,TRANSLATE>> for `translate=translation` option.    This parameter induces a code conversion of the data of the original    file before compression * UNIX ** see <<CLEP.COMMAND.FLAM.TRANSLATE,TRANSLATE>> `-translate=code` table.    This specifies a file containing the code table. * WINDOWS ** `codetable=<name of code table>` ** `cod=<name of code table>` *Values* * WINDOWS ** name of code table *Default* * none *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-translate_405e.html",
"TRANSLATE",
"[[CLEP.COMMAND.FLAM.TRANSLATE]] ==== TRANSLATE indexterm:[Parameter, TRANSLATE, FLAM.TRANSLATE] This parameter causes the codes for data in the original file to be translated prior to the compression procedure or those for the data in the decompressed file to be translated after the decompression procedure. If parameter `translate` is specified for the compression procedure, every record in the original file is translated according to the specified code table before it is buffered in the matrix buffer. During the decompression procedure, this specification causes every decompressed record to be translated according to the code table before it is inserted in the decompressed file. For UNIX only: + When FLAM is installed, code tables for converting from ASCII to EBCDIC and from EBCDIC to ASCII are made available as standard. If one of the code tables in the default value file is to be used, the following specifications are necessary: * a/e  to convert from ASCII to EBCDIC * e/a  to convert from EBCDIC to ASCII For WINDOWS only: + If a specific table is used for translation, it must be specified with `codetable=table` (see also parameter <<CLEP.COMMAND.FLAM.CODETABLE, CODETABLE>>). Otherwise, the default table is used (see also parameter <<CLEP.COMMAND.FLAM.HELP,HELP>> for a list). Syntax restrictions for FLAMv4 or older: * z/OS ** `TRANSLATE=<translation option>` ** `TRA=<translation option>` * UNIX ** `-translate=code table` * WINDOWS ** `translate=translation option` ** `tra=translation option` *Values* * z/OS ** `E/A` - Converts EBCDIC to ASCII. ** `A/E` - Converts ASCII to EBCDIC. ** `TRE2A00` - Converts IMB273 to ISO 8859-1. ** `TRA2E00` - Converts ISO 8859-1 to IBM273. ** `name` - Name of a data module (1-8 characters) that contains  a 256             byte table for code conversion. *** Note: The specified table is loaded dynamically. +           Code conversion may be necessary for file transfer between           heterogeneous systems. It can be performed on any system, but           it is recommended to do it on the target system, since FLAM           already contains the necessary conversion tables for that system.           Many translation tables will be found on our home page:           https://www.flam.de/en/download/addons/Flam4-TranslationTables/zSeries/zos/[Flam4-Translation Tables] * UNIX ** `a/e` - conversion from ASCII to EBCDIC ** `e/a` - conversion from EBCDIC to ASCII * WINDOWS ** `**n**one` - no conversion. ** `*a/e*` - conversion from ASCII to EBCDIC. ** `*e/a*` - conversion from EBCDIC to ASCII. *** Note: If a specific table is used for translation, it must be           specified with `codetable=table`           (see parameter <<CLEP.COMMAND.FLAM.CODETABLE,CODETABLE>>)           otherwise the default table is used           (see parameter <<CLEP.COMMAND.FLAM.HELP,HELP>> for a list). *Default* * no code conversion *Valid for* * compression * decompression * `E/A - conversion from EBCDIC to ASCII` * `A/E - conversion from ASCII to EBCDIC` * `NONE - no conversion` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-nopath_efe0.html",
"NOPATH",
"[[CLEP.COMMAND.FLAM.NOPATH]] ==== NOPATH indexterm:[Parameter, NOPATH, FLAM.NOPATH] This specification has the effect that the file name of the original file is saved without path to the FLAMFILE (UNIX and WINDOWS only). When compressing with <<CLEP.COMMAND.FLAM.ATTRIBUTES,ATTRIBUTES>>=all, FLAM stores the entire absolute path name of the original file in the compressed file's file header. Trying to create a file with the original path at decompression may cause problems on systems with a different directory structure or file naming syntax. With the `nopath` parameter, only the filename is stored properly while the directory path is discarded. Syntax restrictions for FLAMv4 or older: * UNIX ** `-nopath` * WINDOWS ** `nopath` *Values* * none *Default* * none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-climit_4680.html",
"CLIMIT",
"[[CLEP.COMMAND.FLAM.CLIMIT]] ==== CLIMIT indexterm:[Parameter, CLIMIT, FLAM.CLIMIT] This parameter sets minimal compression in per cent, which FLAM would be accepted (z/os ONLY). If the compression result is worse than the predefined limit, FLAM will generate a message and will set condition code 80. The compression is finished properly anyway. This parameter is only evaluated for <<CLEP.COMMAND.FLAM.INFO,INFO>>=YES (default value for PARAMETER INFO). Syntax restrictions for FLAMv4 or older: * Z/OS ** `CLIMIT=nn` ** `CLI=nn` *Values* * Z/OS ** 0 - 90 *Default* * Z/OS ** `CLIMIT=0` *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-iprcntrl_24aa.html",
"IPRCNTRL",
"[[CLEP.COMMAND.FLAM.IPRCNTRL]] ==== IPRCNTRL indexterm:[Parameter, IPRCNTRL, FLAM.IPRCNTRL] Print control characters handling is a special feature for record- oriented files of mainframe systems. For print control, the ASA or machine control characters are often coded in the first byte of the record. For read operations, you can choose whether this byte will be part of the data (RETAIN), handled as separate attribute (DETACH) or ignored (ERASE). With DETACH, you can later (on write) decide how to handle the control character. With RETAIN, the character will be part of the data and with ERASE the control character is lost. If block I/O is used DETACH works like ERASE because the print control character cannot be stored as attribute for the records of a block. This is only possible with record I/O, where the print control character, slot numbers and other attributes are be manageable per record. If you want to read a block of data often, such print control characters are not useful and to transfer such files to an non-mainframe system can result in some strange behavior if there are ASA or MCC control characters in the data. On the other side, sometimes you may want to read a file with ASA and must write records with MCC control characters. In such cases, it is useful to still know the value. In most cases, DETACH is the best choice and is the default for print control handling. At read an additional replacement of print control character by certain empty records to produce a print like output (REPLACE) is supported. In this case a default line per page of 60 is used. This default can change over the parameter replace form feed (RPLFFD). If RPLFFD is 0 then 60 is assumed, if it 1 then form feeds are ignored and in each other case the missing records to fill up one page are added. * `DETACH - Manage print control character as record attribute` * `RETAIN - Leave print control character as part of the data record` * `ERASE - Erase the print control character from the record` * `REPLACE - Replace print control characters by additional records like printed` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-irplffd_5019.html",
"IRPLFFD",
"[[CLEP.COMMAND.FLAM.IRPLFFD]] ==== IRPLFFD indexterm:[Parameter, IRPLFFD, FLAM.IRPLFFD] Replacement of form feeds in case of compression. If a compression process receives a file and the parameter IRPLFFD is set, the received form feed of this uncompressed file is replaced by inserting empty records (row padding) initiated by IRPLFFD=line number before including into the FLAMFILE. Line number expresses the number of lines which will exist in every page of every file in the FLAMFILE initiated by IRPLFFD=line number. The original form feeds of input files are completely replaced by this row padding. Padded rows are empty. If the input file does not use form feed, parameter IRPLFFD is ignored. See also <<CLEP.COMMAND.FLAM.ORPLFFD,ORPLFFD>>. Syntax restrictions for FLAMv4 or older: * `IRPLFFD=line number` * `IRP=line number` *Values* * line number = between 1 - 99, which expresses the line volume per page. *Default* *  none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-oprcntrl_7670.html",
"OPRCNTRL",
"[[CLEP.COMMAND.FLAM.OPRCNTRL]] ==== OPRCNTRL indexterm:[Parameter, OPRCNTRL, FLAM.OPRCNTRL] Print control character handling is a special feature for record oriented files of mainframe system. For print control, the ASA or machine control characters are encoded in the first byte of the record. If an attribute with such a control character is known on write operation, you can decide whether it will be part of the output (RETAIN), written to the output if required (DETACH) or never written (ERASE). At record I/O an additional replacement by certain empty records to produce a print like output (REPLACE) is supported. The replacement is only done if the target record format don't support ASA or MCC. In this case a default line per page of 60 is used. This default can change over the parameter replace form feed (RPLFFD). If RPLFFD is 0 then 60 is assumed, if it 1 then form feeds are ignored and in each other case the missing records to fill up one page are added. * `DETACH - Manage print control character as record attribute` * `RETAIN - Leave print control character as part of the data record` * `ERASE - Erase the print control character from the record` * `REPLACE - Replace print control characters by additional records like printed` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-orplffd_fd2f.html",
"ORPLFFD",
"[[CLEP.COMMAND.FLAM.ORPLFFD]] ==== ORPLFFD indexterm:[Parameter, ORPLFFD, FLAM.ORPLFFD] Replacement of form feeds in case of decompression. If a decompression process receives the parameter `ORPLFFD`, the form feeds of the contained files in the FLAMFILE are replaced by inserting empty records (row padding) during decompression initiated by `IRPLFFD=line number`. Line number expresses the number of lines which will exist in every page of every output file initiated by `ORPLFFD=line number`. The original form feed of every file contained in FLAMFILE is completely replaced by this row padding. Padded rows are empty. If the output file in FLAMFILE does not use form feed, parameter `ORPLFFD` is ignored. See also parameter <<CLEP.COMMAND.FLAM.IRPLFFD,IRPLFFD>>. Syntax restrictions for FLAMv4 or older: * `ORPLFFD=line number` * `ORP=line number` *Values* * line number = between 1 - 99, which expresses the line volume per page. *Default* *  none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-nomkdir_043e.html",
"NOMKDIR",
"[[CLEP.COMMAND.FLAM.NOMKDIR]] ==== NOMKDIR indexterm:[Parameter, NOMKDIR, FLAM.NOMKDIR] If directories don't exists at compression and decompression they are created by default.The NOMKDIR switch has to be defined to prevent this. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-exk10_0ceb.html",
"EXK10",
"[[CLEP.COMMAND.FLAM.EXK10]] ==== EXK10 indexterm:[Parameter, EXK10, FLAM.EXK10] The parameter EXK10 activates user exit for processing original data (z/OS only). NOTE: The module is loaded dynamically.See also parameters       <<CLEP.COMMAND.FLAM.EXK20,EXK20>>, <<CLEP.COMMAND.FLAM.EXD10,EXD10>>       or <<CLEP.COMMAND.FLAM.EXD20,EXD20>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `EXK10` ** `EXK1` *Values* * z/OS ** name of the module (max. 8 characters) *Default* * z/OS ** no user exit *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-exk20_34d0.html",
"EXK20",
"[[CLEP.COMMAND.FLAM.EXK20]] ==== EXK20 indexterm:[Parameter, EXK20, FLAM.EXK20] The parameter EXK20 activates user exit for processing compressed data (z/OS only). NOTE: The module is loaded dynamically. See also parameters       <<CLEP.COMMAND.FLAM.EXD10,EXD10>>, <<CLEP.COMMAND.FLAM.EXD20,EXD20>>       or <<CLEP.COMMAND.FLAM.EXK10,EXK10>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `EXK20` ** `EXK2` *Values* * z/OS ** name of the module (max. 8 characters) *Default* * z/OS ** no user exit *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-exd10_b17a.html",
"EXD10",
"[[CLEP.COMMAND.FLAM.EXD10]] ==== EXD10 indexterm:[Parameter, EXD10, FLAM.EXD10] The parameter EXD10 activates user exit for processing decompressed data (z/OS only). NOTE: The module is loaded dynamically. See also parameters       <<CLEP.COMMAND.FLAM.EXD20,EXD20>>, <<CLEP.COMMAND.FLAM.EXK10,EXK10>>       or <<CLEP.COMMAND.FLAM.EXK20,EXK20>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `EXD10` ** `EXD1` *Values* * z/OS ** name of the module (max. 8 characters) *Default* * z/OS ** no user exit *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-exd20_6971.html",
"EXD20",
"[[CLEP.COMMAND.FLAM.EXD20]] ==== EXD20 indexterm:[Parameter, EXD20, FLAM.EXD20] The parameter EXD20 activates user exit for processing compressed data (z/OS only). NOTE: The module is loaded dynamically. See also parameters       <<CLEP.COMMAND.FLAM.EXD10,EXD10>>, <<CLEP.COMMAND.FLAM.EXK10,EXK10>>       or <<CLEP.COMMAND.FLAM.EXK20,EXK20>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `EXD20` ** `EXD2` *Values* * z/OS ** name of the module (max. 8 characters) *Default* * z/OS ** no user exit *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-space1_793d.html",
"SPACE1",
"[[CLEP.COMMAND.FLAM.SPACE1]] ==== SPACE1 indexterm:[Parameter, SPACE1, FLAM.SPACE1] Primary space request/allocation for FLAMFILE in Megabytes (z/OS only). Original files up to 8 MiB will be handled with the old FLAM4 defaults (2/40) Files larger than 8 MiB will allocate 1/4 of the file size as primary and the file size (4 times more) as secondary space by default. Syntax restrictions for FLAMv4 or older: * z/OS ** `SPACE1=nn` *Values* * z/OS ** 1 - 4095 *Default* * z/OS ** `SPACE1=2` *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-space2_7484.html",
"SPACE2",
"[[CLEP.COMMAND.FLAM.SPACE2]] ==== SPACE2 indexterm:[Parameter, SPACE2, FLAM.SPACE2] Secondary space request/allocation for FLAMFILE in Megabytes (z/OS only). Original files up to 8 MiB will be handled with the old FLAM4 defaults (2/40) Files larger than 8 MiB will allocate 1/4 of the file size as primary and the file size (4 times more) as secondary space by default. Syntax restrictions for FLAMv4 or older: * z/OS ** `SPACE2=nn` *Values* * z/OS ** 1 - 4095 *Default* * z/OS ** `SPACE1=40` *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ospace1_c72c.html",
"OSPACE1",
"[[CLEP.COMMAND.FLAM.OSPACE1]] ==== OSPACE1 indexterm:[Parameter, OSPACE1, FLAM.OSPACE1] Primary space request/allocation for output file in Megabytes (z/OS only). NOTE: This value must only be specified if the FLAMFILE is non       z/OS compressed or you need a special value. A z/OS       FLAMFILE has stored the total space amount in the file       header and uses this value for allocation on decompression. Syntax restrictions for FLAMv4 or older: * z/OS ** `OPACE1=nn` *Values* * z/OS ** 1 - 4095 *Default* * z/OS ** `SPACE1=4` *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ospace2_cbe5.html",
"OSPACE2",
"[[CLEP.COMMAND.FLAM.OSPACE2]] ==== OSPACE2 indexterm:[Parameter, OSPACE2, FLAM.OSPACE2] Secondary space request/allocation for output file in Megabytes (z/OS only). NOTE: This value must only be specified if the FLAMFILE is non       z/OS compressed or you need a special value. A z/OS       FLAMFILE has stored the total space amount in the file       header and uses this value for allocation on decompression. Syntax restrictions for FLAMv4 or older: * z/OS ** `OPACE2=nn` *Values* * z/OS ** 1 - 4095 *Default* * z/OS ** `SPACE2=50` *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-unit_5966.html",
"UNIT",
"[[CLEP.COMMAND.FLAM.UNIT]] ==== UNIT indexterm:[Parameter, UNIT, FLAM.UNIT] Unit for FLAMFILE allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `UNIT=unit name` *Values* * z/OS ** e.g. SYSDA, 3390 *Default* * z/OS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ounit_c697.html",
"OUNIT",
"[[CLEP.COMMAND.FLAM.OUNIT]] ==== OUNIT indexterm:[Parameter, OUNIT, FLAM.OUNIT] Unit for output file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `OUNIT=output file name` *Values* * z/OS ** e.g. SYSDA, 3390 *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-storclass_dbe6.html",
"STORCLASS",
"[[CLEP.COMMAND.FLAM.STORCLASS]] ==== STORCLASS indexterm:[Parameter, STORCLASS, FLAM.STORCLASS] Storage class for FLAMFILE file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `STORCLAS=name` ** `STORC=name` *Values* * z/OS ** name of the SMS storage class *Default* * z/OS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ostorclass_8591.html",
"OSTORCLASS",
"[[CLEP.COMMAND.FLAM.OSTORCLASS]] ==== OSTORCLASS indexterm:[Parameter, OSTORCLASS, FLAM.OSTORCLASS] Storage class for output file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `OSTORCLAS=name` ** `OSTORC=name` *Values* * z/OS ** name of the SMS storage class *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-volume_157a.html",
"VOLUME",
"[[CLEP.COMMAND.FLAM.VOLUME]] ==== VOLUME indexterm:[Parameter, VOLUME, FLAM.VOLUME] Volume for FLAMFILE allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `VOLUME=name` ** `VOL=name` *Values* * z/OS ** name of the volume (e.g. SYSWK1) *Default* * z/OS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ovolume_5edf.html",
"OVOLUME",
"[[CLEP.COMMAND.FLAM.OVOLUME]] ==== OVOLUME indexterm:[Parameter, OVOLUME, FLAM.OVOLUME] Volume for output file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `VOLUME=name of volume` ** `VOL=name of volume` *Values* * z/OS ** name of the volume (e.g. SYSWK1) *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-dataclass_9018.html",
"DATACLASS",
"[[CLEP.COMMAND.FLAM.DATACLASS]] ==== DATACLASS indexterm:[Parameter, DATACLASS, FLAM.DATACLASS] Data storage class for FLAMFILE allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * Z/OS ** `DATACLAS=name of the SMS data storage class` ** `DATAC=name of the SMS data storage class` *Values* * Z/OS ** name of the SMS data storage class *Default* * Z/OS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odataclass_3c8f.html",
"ODATACLASS",
"[[CLEP.COMMAND.FLAM.ODATACLASS]] ==== ODATACLASS indexterm:[Parameter, ODATACLASS, FLAM.ODATACLASS] Data storage class for output file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `ODATACLAS=name` ** `ODATAC=name` *Values* * z/OS ** name of the SMS data storage class *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-mgmtclass_066b.html",
"MGMTCLASS",
"[[CLEP.COMMAND.FLAM.MGMTCLASS]] ==== MGMTCLASS indexterm:[Parameter, MGMTCLASS, FLAM.MGMTCLASS] Management class for FLAMFILE allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `MGMTCLAS=classname` ** `MGMTC=classname` *Values* * z/OS ** name of the SMS management class *Default* * z/OS ** none *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-omgmtclass_ed14.html",
"OMGMTCLASS",
"[[CLEP.COMMAND.FLAM.OMGMTCLASS]] ==== OMGMTCLASS indexterm:[Parameter, OMGMTCLASS, FLAM.OMGMTCLASS] Management class for output file allocation (z/OS only). Syntax restrictions for FLAMv4 or older: * z/OS ** `OMGMTCLAS =name` ** `OMGMTC=name` *Value* * z/OS ** name of the SMS management class *Default* * z/OS ** none *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-dsorg_6619.html",
"DSORG",
"[[CLEP.COMMAND.FLAM.DSORG]] ==== DSORG indexterm:[Parameter, DSORG, FLAM.DSORG] File organization for compressed file (z/OS only). See also parameter <<CLEP.COMMAND.FLAM.RECFORMAT,RECFORMAT>>. NOTE: If the compressed file shall be generated as index sequential       file, a VSAM-KSDS-file must be created. Syntax restrictions for FLAMv4 or older: * z/OS ** `DSORG=PS/ESDS/KSDS/LDS/RRDS`   (FCBTYPE=file control block type) ** `DS=PS/ESDS/KSDS/LDS/RRDS` *Values* * z/OS ** `PS` - sequential ** `ESDS` - VSAM-ESDS ** `KSDS - VSAM-KSDS ** `LDS` - VDSAM-LDS ** `RRDS` - VSAM-RRDS *Default* * z/OS ** `PS` *Valid for* * compression * `SEQ - Sequential access [DEFAULT]` * `PS - Sequential access [DEFAULT]` * `EDS - Entry data set (VSAM-ESDS)` * `ESDS - Entry data set (VSAM-ESDS)` * `KDS - Keyed data set (VSAM-KSDS)` * `KSDS - Keyed data set (VSAM-KSDS)` * `RDS - Relative data set (VSAM-RRDS)` * `RRDS - Relative data set (VSAM-RRDS)` * `LDS - Linear data set (VSAM-LDS)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-idsorg_f928.html",
"IDSORG",
"[[CLEP.COMMAND.FLAM.IDSORG]] ==== IDSORG indexterm:[Parameter, IDSORG, FLAM.IDSORG] File organization for input file (z/OS only). See also parameter <<CLEP.COMMAND.FLAM.INRECFORMAT,INRECFORMAT>>. NOTE: This parameter is not necessary for catalogued files in z/OS. Syntax restrictions for FLAMv4 or older: * z/OS ** `IDSORG=PS/ESDS/KSDS/LDS/RRDS`   (FCBTYPE=file control block type) *Values* * z/OS ** `PS` - sequential ** `ESDS` - VSAM-ESDS ** `KSDS` - VSAM-KSDS ** `LDS` - VDSAM-LDS ** `RRDS` - VSAM-RRDS *Default* * z/OS ** `PS` *Valid for* * compression * `SEQ - Sequential data set [DEFAULT]` * `PS - Sequential data set [DEFAULT]` * `LIB - Library (ZOS-PDSE)` * `PDS - Partitioned data set (ZOS-PDS)` * `USS - UNIX files (path based)` * `EDS - Entry data set (VSAM-ESDS)` * `ESDS - Entry data set (VSAM-ESDS)` * `KDS - Keyed data set (VSAM-KSDS)` * `KSDS - Keyed data set (VSAM-KSDS)` * `RDS - Relative data set (VSAM-RRDS)` * `RRDS - Relative data set (VSAM-RRDS)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odsorg_2dde.html",
"ODSORG",
"[[CLEP.COMMAND.FLAM.ODSORG]] ==== ODSORG indexterm:[Parameter, ODSORG, FLAM.ODSORG] File organization for output file (z/OS only). + See also parameter <<CLEP.COMMAND.FLAM.OUTRECFORMAT,OUTRECFORMAT>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `ODSORG=PS/ESDS/KSDS/LDS/RRDS`   (FCBTYPE=file control block type) *Values* * z/OS ** `PS` - sequential ** `ESDS` - VSAM-ESDS ** `KSDS` - VSAM-KSDS ** `LDS` - VDSAM-LDS ** `RRDS` - VSAM-RRDS *Default* * z/OS ** `PS` *Valid for* * compression * `SEQ - Sequential data set [DEFAULT]` * `PS - Sequential data set [DEFAULT]` * `LIB - Library (ZOS-PDSE)` * `PDS - Partitioned data set (ZOS-PDS)` * `USS - UNIX files (path based)` * `EDS - Entry data set (VSAM-ESDS)` * `ESDS - Entry data set (VSAM-ESDS)` * `KDS - Keyed data set (VSAM-KSDS)` * `KSDS - Keyed data set (VSAM-KSDS)` * `RDS - Relative data set (VSAM-RRDS)` * `RRDS - Relative data set (VSAM-RRDS)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-iclosdisp_886e.html",
"ICLOSDISP",
"[[CLEP.COMMAND.FLAM.ICLOSDISP]] ==== ICLOSDISP indexterm:[Parameter, ICLOSDISP, FLAM.ICLOSDISP] Final processing for tape input file. NOTE: Currently ignored. Control of final processing may be done       via JCL (DD card). Syntax restrictions for FLAMv4 or older: * z/OS ** `ICLOSDISP=REWIND/UNLOAD/LEAVE` ** `ICLO=REWIND/UNLOAD/LEAVE` *Values* * z/OS * `REWIND` - Rewind of tape to tape start * `UNLOAD` - Rewind of tape and unload * `LEAVE` -No rewind *Default* * z/OS ** `REWIND` *Valid for* * compression * `REWIND - Rewind the tape to the beginning` * `UNLOAD - Rewind the tape and unload it` * `LEAVE - Do not rewind` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-closdisp_1049.html",
"CLOSDISP",
"[[CLEP.COMMAND.FLAM.CLOSDISP]] ==== CLOSDISP indexterm:[Parameter, CLOSDISP, FLAM.CLOSDISP] Final processing for compressed file on tape (z/OS only). NOTE: Currently ignored. Control of final processing may be done via JCL       (DD card). Syntax restrictions for FLAMv4 or older: * z/OS ** `CLOSDISP=REWIND/UNLOAD/LEAVE` ** `CLO=REWIND/UNLOAD/LEAVE` *Values* * z/OS ** `REWIND` - Rewind of tape to tape start ** `UNLOAD` - Rewind of tape and unload ** `LEAVE` - No rewind *Default* * z/OS ** `REWIND` *Valid for* * compression * decompression * `REWIND - Rewind the tape to the beginning` * `UNLOAD - Rewind the tape and unload it` * `LEAVE - Do not rewind` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-oclosdisp_5b68.html",
"OCLOSDISP",
"[[CLEP.COMMAND.FLAM.OCLOSDISP]] ==== OCLOSDISP indexterm:[Parameter, OCLOSDISP, FLAM.OCLOSDISP] Final processing of tape output file. NOTE: Currently not supported. Please use JCL (DD statement)       to control final processing. Syntax restrictions for FLAMv4 or older: * z/OS ** `CLOSDISP=REWIND/UNLOAD/LEAVE` ** `CLO=REWIND/UNLOAD/LEAVE` *Values* * z/OS ** `REWIND` - Rewind of tape to tape start ** `UNLOAD` - Rewind of tape and unload ** `LEAVE` - No rewind *Default* * z/OS ** REWIND *Valid for* * decompression * `REWIND - Rewind the tape to the beginning` * `UNLOAD - Rewind the tape and unload it` * `LEAVE - Do not rewind` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-disps_dab5.html",
"DISPS",
"[[CLEP.COMMAND.FLAM.DISPS]] ==== DISPS indexterm:[Parameter, DISPS, FLAM.DISPS] DISP-Status of the FLAMFILE (z/OS only). The DISP parameter is part of the DD card in JCL. NOTE: For more information see z/OS JCL manual under DD statement.       This parameter is ignored when the FLAMFILE is allocated via       JCL. FLAM recognizes itself if a file is new or cataloged (old). JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.DISPN,DISPN>> and <<CLEP.COMMAND.FLAM.DISPA,DISPA>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `DISPS=SHR/OLD/MOD/NEW` *Values* * z/OS ** `SHR` - shareable ** `OLD` - exclusiv ** `MOD` - extend ** `NEW` - new file *Default* * z/OS ** `SHR` for input, `OLD` or `NEW` on output *Valid for* * decompression * `NEW - Disposition status NEW (brand new file)` * `SHR - Disposition status SHR (read exiting  file)` * `MOD - Disposition status MOD (append/modify file)` * `OLD - Disposition status OLD (overwrite existing file)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-dispn_c63e.html",
"DISPN",
"[[CLEP.COMMAND.FLAM.DISPN]] ==== DISPN indexterm:[Parameter, DISPN, FLAM.DISPN] Normal disposition of the FLAMFILE (z/OS only). This parameter is ignored when the file is allocated via JCL. The DISP parameter is part of the DD card in JCL. JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.DISPS,DISPS>> and <<CLEP.COMMAND.FLAM.DISPA,DISPA>>. NOTE: This parameter is ignored when the FLAMFILE is allocated via JCL. * z/OS ** `DISPN=CATLG/DELETE/KEEP/UNCATLG` *Values* * z/OS ** `CATLG` - catalog ** `DELETE` - delete ** `KEEP` - keep ** `UNCATLG` - uncatalog *Default* * z/OS ** none *Valid for* * decompression * `CATALOG - Close disposition catalog` * `CATLG - Close disposition catalog` * `DELETE - Close disposition delete` * `KEEP - Close disposition keep` * `UNCATALOG - Close disposition uncatalog` * `UNCATLG - Close disposition uncatalog` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-dispa_be5f.html",
"DISPA",
"[[CLEP.COMMAND.FLAM.DISPA]] ==== DISPA indexterm:[Parameter, DISPA, FLAM.DISPA] Abnormal termination disposition (JCL) of FLAMFILE (z/OS only). The DISP parameter is part of the DD card in JCL. JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.DISPS,DISPS>> and <<CLEP.COMMAND.FLAM.DISPN,DISPN>>. NOTE: This parameter is ignored when the FLAMFILE is allocated via JCL. * z/OS ** `DISPA=CATLG/DELETE/KEEP/UNCATLG` *Values* * z/OS ** `CATLG` - catalog ** `DELETE` - delete ** `KEEP` - keep ** `UNCATLG` - uncatalog *Default* * z/OS ** none *Valid for* * compression * decompression * `CATALOG - Close disposition catalog` * `CATLG - Close disposition catalog` * `DELETE - Close disposition delete` * `KEEP - Close disposition keep` * `UNCATALOG - Close disposition uncatalog` * `UNCATLG - Close disposition uncatalog` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odisps_92a2.html",
"ODISPS",
"[[CLEP.COMMAND.FLAM.ODISPS]] ==== ODISPS indexterm:[Parameter, ODISPS, FLAM.ODISPS] Disposition-Status (JCL) of FLAMOUT file (z/OS only). The DISP parameter is part of the DD card in JCL. NOTE: For more information see z/OS JCL manual under DD statement.       This parameter is ignored when the file is allocated via JCL.       FLAM recognizes itself if a file is new or cataloged (old). JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.ODISPN,ODISPN>> and <<CLEP.COMMAND.FLAM.ODISPA,ODISPA>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `ODISPS=SHR/OLD/MOD/NEW` *Values* * z/OS ** `SHR` - shareable ** `OLD` - exclusiv ** `MOD` - extend ** `NEW` - new file *Default* * z/OS ** `SHR` for input, `OLD` or `NEW` on output. *Valid for* * decompression * `NEW - Disposition status NEW (brand new file)` * `SHR - Disposition status SHR (read exiting  file)` * `MOD - Disposition status MOD (append/modify file)` * `OLD - Disposition status OLD (overwrite existing file)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odispn_8151.html",
"ODISPN",
"[[CLEP.COMMAND.FLAM.ODISPN]] ==== ODISPN indexterm:[Parameter, ODISPN, FLAM.ODISPN] Normal disposition of the FLAMOUT file (z/OS only). The DISP parameter is part of the DD card in JCL. NOTE: This parameter is ignored when the file is allocated via JCL. JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.ODISPS,ODISPS>> and <<CLEP.COMMAND.FLAM.ODISPA,ODISPA>>. * z/OS ** `ODISPN=CATLG/DELETE/KEEP/UNCATLG` *Values* * z/OS ** `CATLG` - catalog ** `DELETE` - delete ** `KEEP` - keep ** `UNCATLG` - uncatalog *Default* * z/OS ** none *Valid for* * decompression * `CATALOG - Close disposition catalog` * `CATLG - Close disposition catalog` * `DELETE - Close disposition delete` * `KEEP - Close disposition keep` * `UNCATALOG - Close disposition uncatalog` * `UNCATLG - Close disposition uncatalog` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odispa_764c.html",
"ODISPA",
"[[CLEP.COMMAND.FLAM.ODISPA]] ==== ODISPA indexterm:[Parameter, ODISPA, FLAM.ODISPA] Abnormal termination disposition (JCL) of FLAMOUT file (z/OS only). The DISP parameter is part of the DD card in JCL. JCL-Syntax restrictions for FLAMv4 or older: See also parameters <<CLEP.COMMAND.FLAM.ODISPS,ODISPS>> and <<CLEP.COMMAND.FLAM.ODISPN,ODISPN>>. NOTE: This parameter is ignored when the FLAMFILE is allocated via JCL. * z/OS ** `ODISPA=CATLG/DELETE/KEEP/UNCATLG` *Values* * z/OS ** `CATLG` - catalog ** `DELETE` - delete ** `KEEP` - keep ** `UNCATLG` - uncatalog *Default* * z/OS ** none *Valid for* * decompression * `CATALOG - Close disposition catalog` * `CATLG - Close disposition catalog` * `DELETE - Close disposition delete` * `KEEP - Close disposition keep` * `UNCATALOG - Close disposition uncatalog` * `UNCATLG - Close disposition uncatalog` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-keydisp_984b.html",
"KEYDISP",
"[[CLEP.COMMAND.FLAM.KEYDISP]] ==== KEYDISP indexterm:[Parameter, KEYDISP, FLAM.KEYDISP] Key processing during decompression (z/OS only). NOTE: This parameter allows or simplifies the automatic conversion       of sequential files into index sequential files and vice versa. See also parameter <<CLEP.COMMAND.FLAM.KEYLENGTH,KEYLENGTH>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `KEYDISP=OLD/DEL/NEW` ** `KEYD=OLD/DEL/NEW` *Values* * z/OS ** `OLD` - The records of the original file are reconstructed as they            were read in (key + data). ** `DEL` - If the original file has a key length unequal 0, the key is            removed. ** `NEW` - If the output file has a key length unequal 0, a key is            generated at the key position in the specified key length.            The key is generated from a record sequence number (16            characters max.). *Default* * z/OS ** `OLD` *Valid for* * decompression * `OLD - Key disposition OLD (keep the existing key)` * `NEW - Key disposition NEW (insert record number as key)` * `DEL - Key disposition DEL (delete key from record)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-keylength_48e7.html",
"KEYLENGTH",
"[[CLEP.COMMAND.FLAM.KEYLENGTH]] ==== KEYLENGTH indexterm:[Parameter, KEYLENGTH, FLAM.KEYLENGTH] Key length of an index sequential compressed file (z/OS only). NOTE: In an index sequential compressed file the key must be       positioned at the beginning of the record. The key length       should be equal to the sum of the length of all partial       keys of the original file + 1. However, it is allowed to       violate this rule. If sequential data is compressed into an       index sequential compressed file, a key length of 5 bytes       is sufficient. See also parameter <<CLEP.COMMAND.FLAM.KEYDISP,KEYDISP>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `KEYLEN=n` ** `KEYL=n` *Values* * z/OS ** 0, 1 - 255 *Default* * z/OS ** 0 (no key) *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-okeyposition_c33f.html",
"OKEYPOSITION",
"[[CLEP.COMMAND.FLAM.OKEYPOSITION]] ==== OKEYPOSITION indexterm:[Parameter, OKEYPOSITION, FLAM.OKEYPOSITION] Key position of output file (z/OS only). NOTE: This value must only be specified if the key length differs       from the original file. The position of the record key is       defined independently from the properties of a particular       operating system as the relative position within the data       part of the record. The first byte has position 1. See also parameter <<CLEP.COMMAND.FLAM.OKEYLENGTH,OKEYLENGTH>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `OKEYPOS=n` ** `OKEYP=n` *Values* * z/OS ** 0, 1 - (record length - key length + 1) *Default* * z/OS ** 1 or the value from the file header. *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-okeylength_4b30.html",
"OKEYLENGTH",
"[[CLEP.COMMAND.FLAM.OKEYLENGTH]] ==== OKEYLENGTH indexterm:[Parameter, OKEYLENGTH, FLAM.OKEYLENGTH] Key length of output original file (z/OS only). NOTE: This value must only be specified if the key length differs       from the original file. See also parameter <<CLEP.COMMAND.FLAM.OKEYPOSITION,OKEYPOSITION>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `OKEYLEN=n` ** `OKEYL=n` *Values* * z/OS ** 0, 1-255 *Default* * z/OS ** 8 or the value from the file header *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-orgkeypos_58e1.html",
"ORGKEYPOS",
"[[CLEP.COMMAND.FLAM.ORGKEYPOS]] ==== ORGKEYPOS indexterm:[Parameter, ORGKEYPOS, FLAM.ORGKEYPOS] Specification of key position for key sequential datasets (KSDS); z/OS only. If a *decompression process* contains the parameter `ORGKEYPOS` in order to create a key sequential dataset (KSDS), the specification is used to find the place, where the index field starts in order to create the necessary VSAM-KSDS key. This parameter is used together with parameter <<CLEP.COMMAND.FLAM.ORGKEYLEN,ORGKEYLEN>>. Syntax restrictions for FLAMv4 or older: * `ORGKEYPOS=position` * `ORGKEYPO=position` * `ORGKEYP=position` *Values* * between 1 and  max. record length *Default* * no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-orgkeylen_d634.html",
"ORGKEYLEN",
"[[CLEP.COMMAND.FLAM.ORGKEYLEN]] ==== ORGKEYLEN indexterm:[Parameter, ORGKEYLEN, FLAM.ORGKEYLEN] Specification of key length for key sequential datasets (KSDS); z/OS only. If a *decompression process* contains the parameter `ORGKEYLEN` in order to create a key sequential dataset (KSDS), the specification is used to define the length of the used index field. This parameter is used together with parameter <<CLEP.COMMAND.FLAM.ORGKEYPOS,ORGKEYPOS>>. Syntax restrictions for FLAMv4 or older: * `ORGKEYLEN=length` * `ORGKEYL=length` *Values* * length in bytes, > 0 and < record length *Default* * no default *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ikeyposition_a9a5.html",
"IKEYPOSITION",
"[[CLEP.COMMAND.FLAM.IKEYPOSITION]] ==== IKEYPOSITION indexterm:[Parameter, IKEYPOSITION, FLAM.IKEYPOSITION] Key position of input file (z/OS only). NOTE: This parameter is not necessary for catalogued files in MVS.       The key position specified in the catalogue is used. See also parameter <<CLEP.COMMAND.FLAM.IKEYLENGTH,IKEYLENGTH>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `IKEYPOS=n` ** `IKEYP=n` *Values* * z/OS ** 0, 1 - (record length - key length). *Default* * z/OS ** 1 if key exists, 0 otherwise *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-ikeylength_12be.html",
"IKEYLENGTH",
"[[CLEP.COMMAND.FLAM.IKEYLENGTH]] ==== IKEYLENGTH indexterm:[Parameter, IKEYLENGTH, FLAM.IKEYLENGTH] Key length of input file (z/OS only). NOTE: This parameter is not necessary for catalogued files in MVS.       The key length specified in the catalogue is used. See also parameter <<CLEP.COMMAND.FLAM.IKEYPOSITION,IKEYPOSITION>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `IKEYLEN=n` ** `IKEYL=n` *Values* * z/OS ** 0, 1-255 *Default* * z/OS ** No key *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-device_1ff2.html",
"DEVICE",
"[[CLEP.COMMAND.FLAM.DEVICE]] ==== DEVICE indexterm:[Parameter, DEVICE, FLAM.DEVICE] Device assignment for compressed file (z/OS only). NOTE: This parameter is not needed for catalogued files under z/OS. The device type is automatically assigned by the operating system. If the user exit for I/O shall be activated, `DEVICE=USER` must be specified. Syntax restrictions for FLAMv4 or older: * z/OS ** `DEVICE=DISK/TAPE/FLOPPY/STREAMER/USER` ** `DEV=DISK/TAPE/FLOPPY/STREAMER/USER` *Values* * z/OS ** `DISK` - disc unit ** `TAPE` - tape unit ** `FLOPPY` - floppy disc drive ** `STREAMER` - tape streamer ** `USER` - User specific I/O interface *Default* * z/OS ** `DISK` *Valid for* * compression * decompression * `FILE - Write to a file (equal to disk)` * `DISK - Write to a disk (equal to file)` * `TAPE - Write to a tape` * `FLOPPY - Write to a floppy` * `STREAMER - Write to a streamer tape` * `USER - Use user IO` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-idevice_8d29.html",
"IDEVICE",
"[[CLEP.COMMAND.FLAM.IDEVICE]] ==== IDEVICE indexterm:[Parameter, IDEVICE, FLAM.IDEVICE] Device assignment for input file (z/OS only). NOTE: This parameter is not needed for catalogued files under z/OS.       The device type is automatically assigned by the operating system.       If the user exit for I/O shall be activated, `IDEVICE=USER`       must be specified. Syntax restrictions for FLAMv4 or older: * z/OS ** `IDEVICE=DISK/TAPE/FLOPPY/STREAMER/USER` ** `IDEV=DISK/TAPE/FLOPPY/STREAMER/USER` *Values* * z/OS ** `DISK` - disc unit ** `TAPE` - tape unit ** `FLOPPY` - floppy disc drive ** `STREAMER` - tape streamer ** `USER` - User specific I/O interface *Default* * z/OS ** `DISK` *Valid for* * compression * `FILE - Write to a file (equal to disk)` * `DISK - Write to a disk (equal to file)` * `TAPE - Write to a tape` * `FLOPPY - Write to a floppy` * `STREAMER - Write to a streamer tape` * `USER - Use user IO` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-odevice_3ea3.html",
"ODEVICE",
"[[CLEP.COMMAND.FLAM.ODEVICE]] ==== ODEVICE indexterm:[Parameter, ODEVICE, FLAM.ODEVICE] Device assignment for output file (z/OS only). NOTE: This parameter is not needed for catalogued files under z/OS.       The device type is automatically assigned by the operating system.       If the user interface for I/O shall be activated, ODEVICE= USER       must be specified Syntax restrictions for FLAMv4 or older: * z/OS ** `ODEVICE=DISK/TAPE/FLOPPY/STREAMER/USER` ** `ODEV=DISK/TAPE/FLOPPY/STREAMER/USER` *Values* * z/OS ** `DISK` - disc unit ** `TAPE` - tape unit ** `FLOPPY` - floppy disc drive ** `STREAMER` - tape streamer ** `USER` - User specific I/O interface *Default* * z/OS ** DISK *Valid for* * decompression * `FILE - Write to a file (equal to disk)` * `DISK - Write to a disk (equal to file)` * `TAPE - Write to a tape` * `FLOPPY - Write to a floppy` * `STREAMER - Write to a streamer tape` * `USER - Use user IO` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-splitmode_6dfb.html",
"SPLITMODE",
"[[CLEP.COMMAND.FLAM.SPLITMODE]] ==== SPLITMODE indexterm:[Parameter, SPLITMODE, FLAM.SPLITMODE] Mode for splitting a FLAMFILE (z/OS only). NOTE: Splitting of FLAMFILEs has been introduced in FLAM V4.0 and       is not compatible to older versions. +       The split information is stored in the FLAMFILE. So it is       not necessary to use any parameter on decompression. See also parameters <<CLEP.COMMAND.FLAM.SPLITNUMBER,SPLITNUMBER>> and <<CLEP.COMMAND.FLAM.SPLITSIZE,SPLITSIZE>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `SPLITMODE=NONE/SERIAL/PARALLEL` ** `SPLITM=NONE/SERIAL/PARALLEL` *Values* * z/OS ** `NONE` - no split ** `SERIAL` - serial split ** `PARALELL` - parallel split *Default* * z/OS ** `NONE` *Valid for* * compression * `NONE - No splitting (default)` * `SERIAL - Serial splitting (after 1-4096 Megabyte)` * `PARALLEL - Parallel splitting (in 2, 3 or 4 files)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-splitnumber_1b99.html",
"SPLITNUMBER",
"[[CLEP.COMMAND.FLAM.SPLITNUMBER]] ==== SPLITNUMBER indexterm:[Parameter, SPLITNUMBER, FLAM.SPLITNUMBER] Number of fragments on parallel split (z/OS only). NOTE: The information is stored in the FLAMFILE. So it is not necessary       to use any parameter on decompression. All fragments have to be       catalogued and ready to read.       It is not possible, to decompress one fragment alone.       Using this parameter requires SPLITMODE=PARALLEL. See also parameters <<CLEP.COMMAND.FLAM.SPLITMODE,SPLITMODE>> and <<CLEP.COMMAND.FLAM.SPLITSIZE,SPLITSIZE>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `SPLITNUMBER=2-4` ** `SPLITN=2-4` *Values* * z/OS ** 2 - 4 number of simultaneously written files *Default* * z/OS ** 4 *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-splitsize_af39.html",
"SPLITSIZE",
"[[CLEP.COMMAND.FLAM.SPLITSIZE]] ==== SPLITSIZE indexterm:[Parameter, SPLITSIZE, FLAM.SPLITSIZE] Amount in MB of a fragment on serial split (z/OS only). NOTE: The number of created files depends on the amount of compressed       data. The information is stored in the FLAMFILE.       Using this parameter requires SPLITMODE=SERIAL. See also parameters <<CLEP.COMMAND.FLAM.SPLITMODE,SPLITMODE>> and <<CLEP.COMMAND.FLAM.SPLITNUMBER,SPLITNUMBER>>. Syntax restrictions for FLAMv4 or older: * z/OS ** `SPLITSIZE=n` ** `SPLITS=n` *Values* * z/OS ** 1 - 4095 *Default* * z/OS ** 100 *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-flamddn_2c7e.html",
"FLAMDDN",
"[[CLEP.COMMAND.FLAM.FLAMDDN]] ==== FLAMDDN indexterm:[Parameter, FLAMDDN, FLAM.FLAMDDN] With this parameter the DD-NAME for the compressed FLAMFILE in the DD JCL-command can be changed. It is the symbolic DD filename for the normally used compressed FLAMFILE (z/OS only). The *DD-NAME* of this compressed file is `FLAMFILE` by default and can be modified using parameter `FLAMDDN=<name>`. All output is written to a FLAM compressed file by default: or Syntax restrictions for FLAMv4 or older: * z/OS ** `FLAMDDN=filename` ** `FLAMD=filename` ** Note: This parameter allows to change the DD name of the DD          command. For decompression, `>` before the DD name means          that the file contains a list of FLAMFILE names. *Values* * z/OS ** DD-NAME with max. 8 characters. ** > DD-NAME with max. 7 characters (decompression) *Default* * z/OS ** FLAMFILE DD ...... *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-iddn_ac07.html",
"IDDN",
"[[CLEP.COMMAND.FLAM.IDDN]] ==== IDDN indexterm:[Parameter, IDDN, FLAM.IDDN] With this parameter the DD-NAME for the FLAM input file in the DD JCL-command can be changed. It is the symbolic DD file name for the normaly used FLAM input file (z/OS only). The DD-NAME of this FLAM input file is `FLAMIN` by default and can be modified using parameter `IDDN=<name>`. All input is read by default from FLAM input file: or Syntax restrictions for FLAMv4 or older: * z/OS ** `IDDN=filename` *** Note: This parameter allows to change the DD-NAME of the DD command.           A '>' before the filename means the file contains a list           of files to be compressed. *Values* * z/OS ** DD-NAME with max. 8 characters. ** > DD-NAME with max. 7 characters *Default* * z/OS **  FLAMIN DD ...... *Valid for* * compression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-oddn_2291.html",
"ODDN",
"[[CLEP.COMMAND.FLAM.ODDN]] ==== ODDN indexterm:[Parameter, ODDN, FLAM.ODDN] With this parameter the DD-NAME for the FLAM output file in the DD JCL-command can be changed. It is the symbolic DD file name for the normaly used FLAM output file (z/OS only). The DD-NAME of this FLAM output file is `FLAMOUT` by default and can be modified using parameter `ODDN=<name>`. All output is written by default to FLAM output file: or Syntax restrictions for FLAMv4 or older: * z/OS ** `ODDN=file name` *** Note: With this parameter the DD-NAME in the DD command can be changed. *Values* * z/OS ** DD-NAME with max. 8 characters *Default* * z/OS ** FLAMOUT DD ...... *Valid for* * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-msgddn_f5c5.html",
"MSGDDN",
"[[CLEP.COMMAND.FLAM.MSGDDN]] ==== MSGDDN indexterm:[Parameter, MSGDDN, FLAM.MSGDDN] With this parameter the DD-NAME for the FLAM message file in the DD JCL-command can be changed. It is the symbolic DD file name for the normaly used message file (z/OS only). FLAM messages are written into a catalogued file. The DD-NAME of this file is `FLPRINT` by default and can be modified using parameter `MSGDDN=<name>`. All messages are written by default into message file: or Parameters in the same context: <<CLEP.COMMAND.FLAM.MSGFILE,MSGFILE>> and <<CLEP.COMMAND.FLAM.MSGDISP,MSGDISP>> Syntax restrictions for FLAMv4 or older: * z/OS ** `MSGDDN=file name` ** `MSGDD=file name` *** Note: With this parameter the `DD-NAME FLPRINT` in the DD command           can be changed. *Values* * z/OS ** DD-NAME with max. 8 characters. *Default* * z/OS **  FLPRINT DD ...... *Valid for* * compression * decompression ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-remove_1de0.html",
"REMOVE",
"[[CLEP.COMMAND.FLAM.REMOVE]] ==== REMOVE indexterm:[Parameter, REMOVE, FLAM.REMOVE] At compression, the switch causes the original file(s) (specified with flamin) to be deleted after having been successfully compressed. If any errors occur while a file is being compressed, the file is not deleted. The compression procedure can be repeated. At decompression, this parameter causes a FLAMFILE to be deleted after having been successfully decompressed. If any errors occur while the FLAMFILE is being decompressed, the file remains stored. This enables the errors to be analyzed and the original data to be restored as far as possible. If you don't extract all members from the FLAMFILE, then the FLAMFILE will still remain. Single members are not removed from the archive. The switch should not be used if the target is an archive file and wildcards are used. The original files are deleted as soon as they are written to the archive. If consecutive writes to the archive file (further input files or the archive trailer) fail, the archive may end up corrupted with original files deleted. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-from_1028.html",
"FROM",
"[[CLEP.COMMAND.FLAM.FROM]] ==== FROM indexterm:[Parameter, FROM, FLAM.FROM] The FROM code defines the encoding string or CCSID (Coded Character Set Identifier) for the input text stream. If no CCSID is provided, the records are handle binary. In other words, the FROM code activate text record handling. The character conversion module will be setup with EBCDIC new line to line feed handling and the combined character support is deactivated. If you need more functionality (user specific conversion, subset support, special casing, normalization, ...) please use another command. When reading and the DEFAULT key word is assigned, the input data's charset is auto-detected. The charsets below can currently be detected: * ASCII (the finally used code page depends on the language code) * EBCDIC (the finally used code page depends on the language code) * UTF-8    == US-ASCII * UTF-16LE == UCS-2LE (little-endian) * UTF-16BE == UCS-2BE (big-endian) * UTF-32LE == UCS-4LE (little-endian) * UTF-32BE == UCS-4BE (big-endian) If the data is encoded in ASCII or EBCDIC, the corresponding CCSID will be derived from the appropriate environment variable LANG. On non-ASCII systems, the ASCII-CCSID is derived from the language identifier (e.g. en, de, ...). The same holds true for non-EBCDIC systems if EBCDIC is detected. When ASCII is detected on an ASCII system, the CCSID from the LANG environment variable is used (e.g. de_DE.UTF-8 => UTF-8), if present. If the LANG variable contains no CCSID, then the language identifier is used (e.g. de_DE => ISO-8859-1). The same holds true for EBCDIC systems if EBCDIC is detected. On modern platforms, the CCSID for a resource may be saved in the file system and can also be given by the FIO module. In general, however, it is recommended to set this parameter to its correct value. For default handling, the keywords DEFAULT, ASCII and EBCDIC as well as (for multibyte characters) the BOM keywords stated below can be used to help finding the correct CCSID on read operations. The SYSTEM keyword selects the system specific CCSID (on EBCDIC systems the default EBCDIC and on ASCII the default ASCII CCSID). The keyword LOCAL works like DEFAULT but it prefers the real local character set if the same kind of character set (ASCII or EBCDIC) is detected. Character conversions at decompression operation are also possible, but in this case, the BOM keywords are not supported. When writing, the FROM CCSID is usually known and does not need to be specified. In order to use the BOM keywords, a BOM sign must be part of the input data. All unique BOM characters are supported in principle, but for UTF-16/USC-2 and UTF-32/UCS-4 the same BOM sign is used. You can define by yourself which family is used. To get a list of supported encoding strings, please use the command below: Depending on the platform, this function lists all known encoding strings. Some encodings may not be supported. To determine the supported CCSIDs and corresponding encoding strings and charsets please use: To define the CCSID, you can use one of the encoding strings or the decimal number for a CCSID displayed by the command above. Example: A numeric CCSID must start with a decimal digit. * `DEFAULT - Use default CCSID (auto-detect)` * `ASCII - Use default ASCII CCSID (environment)` * `EBCDIC - Use default EBCDIC CCSID (environment)` * `BOMUTF - Determine the correct UTF CCSID from byte order mark (BOM) only when reading` * `BOMUCS - Determine the correct UCS CCSID from byte order mark (BOM)only when reading` * `SYSTEM - Use system character set (environment/logical)` * `LOCAL - Use local character set (auto-detect + system/physical)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode_c404.html",
"CHRMODE",
"[[CLEP.COMMAND.FLAM.CHRMODE]] ==== CHRMODE indexterm:[Parameter, CHRMODE, FLAM.CHRMODE] With the CHRMODE selection you can define how an invalid or incomplete character is handled inside of a unit by this component. All possible modes are listed at the end of this chapter. This CHRMODE is valid for the content of each unit (block or record). At the end of a unit there can be an incomplete character. Such a rest will be remove from the current and add at the beginning of the next record (if another method (not KEEP) required please use another conversion commend of FLCL). The rest of the last unit of a data field will be concatenated to the first unit of the next data field. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode-stop_75ed.html",
"STOP",
"[[CLEP.COMMAND.FLAM.CHRMODE.STOP]] ===== STOP indexterm:[Constant, STOP, FLAM.CHRMODE.STOP] Stops conversion at the first incomplete or invalid character which cannot be converted. An error message is given with the position of abortion and the value in the input stream. An entry will be (STP()) written to the report file to log this event. To be compatible with other conversion tools, this is the default case, but we recommend to use IGNORE or SUBSTITUTE to prevent any abortion. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode-ignore_0e4b.html",
"IGNORE",
"[[CLEP.COMMAND.FLAM.CHRMODE.IGNORE]] ===== IGNORE indexterm:[Constant, IGNORE, FLAM.CHRMODE.IGNORE] Ignores incomplete or invalid characters and writes a report entry for each character. IGNORE is a substitution by no corresponding character that means no substitution table is required. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode-substitute_75b9.html",
"SUBSTITUTE",
"[[CLEP.COMMAND.FLAM.CHRMODE.SUBSTITUTE]] ===== SUBSTITUTE indexterm:[Constant, SUBSTITUTE, FLAM.CHRMODE.SUBSTITUTE] Substitutes incomplete or invalid character and writes a report entry for each character. For SUBSTITUTE you can define a substitution character list (SUBCHR). If no SUBCHR is provided then this option substitutes invalid or incomplete characters with code point 0x00001A. If a SUBCHR is defined all invalid or incomplete characters will be substituted by the defined list of code points that can be up to 8. If you specify a SUBCHR the substitution mode will be enabled. If no reporting requested and the substitution character is only one code point this mode will significant improve performance of character conversion. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode-identity_2433.html",
"IDENTITY",
"[[CLEP.COMMAND.FLAM.CHRMODE.IDENTITY]] ===== IDENTITY indexterm:[Constant, IDENTITY, FLAM.CHRMODE.IDENTITY] Copies invalid characters from input to output and writes a report entry for each character. Resulting output could be not printable. This kind of error handling can only be used for single byte to single byte character conversion (ASCII<->EBCDIC). If no reporting requested this mode will significant improve performance of character conversion. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-chrmode-translit_e6a2.html",
"TRANSLIT",
"[[CLEP.COMMAND.FLAM.CHRMODE.TRANSLIT]] ===== TRANSLIT indexterm:[Constant, TRANSLIT, FLAM.CHRMODE.TRANSLIT] Activates ICONV transliteration for non-convertible character, ignores incomplete or invalid character and writes a report entry for each manipulated character. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-to_a811.html",
"TO",
"[[CLEP.COMMAND.FLAM.TO]] ==== TO indexterm:[Parameter, TO, FLAM.TO] The TO code defines the encoding string or CCSID for the output text stream. The default value of this CCSID at compression is UTF-8. For decompression, the default value is derived from the environment variable LANG. If LANG is not set, the default ASCII or EBCDIC system-codepage is used, depending on the platform. To get a list of supported encoding strings, please use the command below: Depending on the platform, this function lists all known encoding strings. Some encodings may not be supported. To determine the supported CCSIDs please use: To define the CCSID, you can use one of the encoding strings or the decimal number for a CCSID displayed by the command above. Example: A numeric CCSID must start with a decimal digit. Optionally, you can use one of the keywords below to use the system-specific default ASCII or EBCDIC CCSID. * `DEFAULT - Use default CCSID (UTF-8)` * `ASCII - Use default ASCII CCSID (environment)` * `EBCDIC - Use default EBCDIC CCSID (environment)` * `SYSTEM - Use system character set (environment/logical)` * `LOCAL - Use local character set (system/physical)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-larger_a2cf.html",
"LARGER",
"[[CLEP.COMMAND.FLAM.LARGER]] ==== LARGER indexterm:[Parameter, LARGER, FLAM.LARGER] The LARGER switch will activate the block/record conversion with the B4X method. see: <<flcl.handling.spanned.records,Handling of Spanned Records>> To write large records to the old FLAMFILE, they must be converted. The FLAM4 components will handle this as an undefined byte stream. When reading, the inverse conversion must be requested to restore the original records. NOTE: Automatic record length detection will not work with large records (>=32768). This requires to set the record formatting method when reading such a FLAMFILE. ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-dir_6d8f.html",
"DIR",
"[[CLEP.COMMAND.FLAM.DIR]] ==== DIR indexterm:[Object, DIR, FLAM.DIR] This object defines multiple switches that control how input files are found. This is especially important when using wildcards in input filenames. There are switches to enable recursion into subdirectories, following symbolic links, finding hidden files, recursion into archive files, include files on tapes, resolving aliases and enforcing to not leave the filesystem. If the recursive flag is set, the filename portion of the input file string is searched for recursively. If a directory path containing wildcards is present, the filename portion is searched for recursively in all paths that match the directory path pattern, e.g. '/path/.txt' matches my/path/hugo.txt, another/path/hugo.txt as well as my/path/subdir/hugo.txt. Without the recursive flag, the last file would not be found. If the archive switch is enabled, FLAMFILES, TARBALLS, ZIP files and other kinds of supported archives are searched. All the matching members are extracted. In other words, archives are interpreted like subdirectories if the flag is enabled. If the tape switch is enabled, then datasets stored on tapes or if migrated (if VOLSER = 'MIGRAT' or 'ARCIVE' on z/OS) files are searched. If the name of such a file matches the pattern, then it might occur that console input and a manual intervention is required to retrieve the respective dataset(s). A special behavior was implemented for z/OS for files on DASD, where a SVC27(OBTAIN) is issued for nonVSAM data sets (normal PS/PO). To collect also files if the SVC27 failed the obtain switch must be set. Normally this will result in a warning and completion code 4. If the obtain switch is not defined, files without a corresponding control blocks are skipped. If the link switch is enabled, symbolic links are followed (otherwise they are ignored). Links are mainly supported on modern file systems. For dataset aliases on mainframe systems, see the alias flag. With the alias switch enabled, datasets names which are aliases of the real dataset are resolved to their actual names (otherwise they are ignored). Dataset aliases only exist on mainframe systems. This flag has no effect on other platforms. If a transparent read method (e.g. read.auto()) is used, then the archive flag is enabled by default and cannot be disabled. * `SWITCH: LINK - Include symbolic links` * `SWITCH: ALIAS - Resolve data set aliases` * `SWITCH: HIDDEN - Include hidden files` * `SWITCH: RECURSIVE - Include sub directories` * `SWITCH: ARCHIVE - Include archives (FLAMFILEs, ZIP, ...)` * `SWITCH: ONEFILESYSTEM - Don't cross file system boundaries` * `SWITCH: TAPE - Include files deposited on tapes (or if migrated or archived)` * `SWITCH: OBTAIN - Obtain control blocks if DSAD (z/OS only, warning if SVC27 failed)` ",
"",
""
],
[
"flam4_manual-flam4_commands-flam-log_f32a.html",
"LOG",
"[[CLEP.COMMAND.FLAM.LOG]] ==== LOG indexterm:[Object, LOG, FLAM.LOG] The LOG parameter allows flexible adjustment for the logging of messages. It is possible to specify the destination as well as which kind of message will be written. ",
"",
""
],
[
"flam4_manual-flam_subsystem_for_z_os_43bb.html",
"FLAM Subsystem for z/OS",
"== FLAM Subsystem for z/OS This appendix describes the handling of the FLAM subsystem in IBM z/OS (OS/390, MVS) environment. FLAM-sub is an interface to FLAM (z/OS), the compression and encryption utility, and may only be used in conjunction with a license for FLAM-utility. FLAM as a subprogram offers the same functionality as if used as a standalone application. The difference is, that FLAM is called from a custom application or a driver program. It is possible to specify parameters with the call. === FLAM as a subsystem FLAM-sub supports the subsystem interface of the command language (JCL) in z/OS. Files can thus be processed in compressed an encrypted form without having to modify the associated programs. The additional compression and decompression steps which were necessary in the past can now be dispensed with. The calling program is not aware of any differences as compared with the conventional mode of file processing. It receives a record for a read call in the same way as before, while for a write call the data management system (DMS) receives the record as usual. The subsystem decompresses before reading and compresses before writing. The compression results are similar to those of the FLAM utility (approx. 70-90%). The FLAM subsystem even enables programs to be supported with file formats for which they were not originally written, in other words the program and the data formats can be separated from one another. The FLAM subsystem is loaded almost entirely in the high address space (above 16 MB); only a small tuning module for 24-bit addressing works in the low address space. Since 24-bit addressing is used for the DMS accesses to PS files, a memory area corresponding to the length of one data record is created in the low address space. FLAM creates all work areas above the 16 MB limit, so that the usual memory area is still made available to the applications. No changes are normally necessary in the calling programs. The compressed files created by the subsystem (FLAMFILEs) can be decompressed by the FLAM utility at any time, and all FLAMFILEs created by the FLAM utility are accepted and processed logically by the FLAM subsystem. The same applies likewise to FLAMFILEs that are created/read via the record interface of FLAM (see sections <<flam4.main.overview,'FLAM overview'>> and <<flam4.main.mode.of.operation,'FLAM operation mode'>>. === Subststem call This call designates the cataloged file filename for processing with the FLAM subsystem. FLAM parameters can be specified in addition, in the same way as with the FLAM utility. Invalid parameters are rejected by FLAM as JCL errors and the job they refer to is not even started. The DD command is still verified by JES. The catalog entry for the file is not modified by FLAM. All entries such as the file name, the record and block lengths, the volume, etc. remain unchanged. The files that must be processed with the FLAM subsystem are thus still verified by the check mechanisms, such as SMS and RACF. There is no FLAM restriction on the number of files that can be processed 'simultaneously' by the subsystem. The only restrictions are those imposed by the system itself, such as the maximum amount of available memory or the maximum possible number of DD statements. If files for which the SUBSYS specification in the DD statement is not supported must be processed (for example, JES files), the problem can be overcome by specifying a FLAM parameter and a second DD statement: Specifying a DD name ddname1 as a FLAM parameter causes the subsystem to process the file assigned by means of this name (in this case by writing in it). This file must be specified in the JCL. Similarly, ddname1 could be used as a decompression input. The calling program, on the other hand, uses the file assigned with ddname! This method permits reading or writing in any file (JES, RJE, other subsystems, magnetic tapes, temporary files, etc.) which cannot otherwise be processed with the usual method (see <<flam4.flamsub.examples,Examples>>). If DCB attributes are specified for ddname, FLAM interprets them as values for the original (uncompressed) file. DCB specifications for ddname1 apply to the compressed file (the FLAMFILE). Record and block formats which are completely different from one another can thus be set for the original and compressed files depending on the particular problem, in other words the subsystem allows an application to use files that have absolutely nothing in common with the entries in the program (see <<flam4.flamsub.examples,Examples>>) and that without the subsystem might have to be converted. If the FLAMFILE is accessed without a SUBSYS specification, it behaves like a 'normal' file, in other words it can be read (copied, transferred) by means of utilities or file transfer programs without being decompressed! Similarly, a FLAMFILE which is transferred by a file transfer program can be read and processed via the subsystem. [[flam4.flamsub.preconditions]] === Preconditions FLAM must be installed on the computer both as a utility (V4.0 or higher) and as a subsystem. Data records can be written, read, modified, inserted or deleted. The data set organization may be of PS or VSAM. The accesses must be logical, in other words either in sequential order or according to a key. Accesses according to the RBA (relative byte address) of a data record or an alternate index are not possible! A DCB for PS files or an ACB for VSAM files can be coded in the calling program. The programs (or more precisely the file control block DCB) must be stored in the low address space. A FLAMFILE in KSDS format must have the same structure as in the FLAM utility (see <<flam4.main.flamfile.details,FLAMFILE details>>), i.e. * Relative key position: 0 * Key length: one byte longer than the original * Record length: between 80 and 32760 bytes * Control interval size: any, depending on record length Although FLAM supports a wide range of record length, please take care on performance views. FLAM compresses a number of data records in a row (depending on MAXR and MAXB parameter). MAXB=64 means 64 KB of Data will be compressed. Assume a compression rate of 90 %, this will lead to a compression result of 6.4 KB compressed data. If you had defined the VSAM-KSDS-FLAMFILE like your original file (i.e. with record size of 400 byte) FLAM has to write 17 VSAM records for the compressed data, each with a new built key. So has FLAM to read 17 records to decompress one original record. So it is better to define a larger RECSIZE for the FLAMFILE, in this example you should use RECSIZE(7168). NOTE: The runtime system of COBOL (PL/I, C) checks all       assigned VSAM files. The FLAMFILE must therefore be tuned to the VSAM file type if COBOL programs are used: for accesses to VSAM-ESDS it must also have been created as ESDS, while for accesses to VSAM-KSDS a KSDS-FLAMFILE must exist as well. With Assembler programs, on the other hand, the FLAMFILE and the original file need not necessarily be of the same type (providing this is also meaningful). === Principle of operation All the JCL specifications are checked before a batch job is started by JES. The parameters for the subsystem are transferred and verified by FLAM-sub. If an error is detected, the DD statement is rejected as a JCL error. In addition, a message is output in the JCL list. The job is thus only started if there are no errors; otherwise it is aborted in the usual way. An OPEN command call in the program causes a connection to be set up to the FLAM subsystem. FLAM- sub decides at this stage whether the file must be compressed or decompressed. An open input means decompression (read only), while an open output means compression (write only). An open I/O allows full I/Os to the FLAMFILE via the key of the original records. At the same time, the record and block lengths are taken from the calling program (or from the DCB specifications in the JCL) and - in the case of an open output - transferred to the FLAM file header of the FLAMFILE (unless the `HEADER=NO` parameter has been specified). The FLAM parameters specified in the JCL are also activated at the time of the open and the compression/ decompression routines set accordingly. All read and write accesses take place in accordance with the specifications in the program. Asynchronous VSAM calls are executed synchronously by the subsystem, while return codes are not returned (or the error routines activated) until the CHECK call. It makes no difference whether the file is accessed by the program as BSAM, QSAM or VSAM. FLAM-sub maps all calls to the currently available FLAMFILE. The record format can always be either variable or fixed. If an error occurs, the error routine remains active in the calling program and is not overlaid by the subsystem. The error return codes that are returned by the subsystem correspond to those of the DMS (see also: https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3SC236852/$file/idad500_v2r3.pdf[MVS/DFP Macro Instructions for VSAM Data Sets] for VSAM error codes). In other words, the error routines need not be modified; the IEC ... messages of the DMS (see also: http://192.234.241.151/mvs/iea2m720.pdf[z/OS MVS System Messages Volume 7 (IEB - IEE)]) are still traced if necessary. Additional messages are output by FLAM-sub with `WTO,Routcde=11` for FLAM errors and subsystem errors (see section <<flam4.subsystem.messages,'Subsystem messages'>>). They are documented both in the system log and in the JCL list. No other messages are generated (the `FLAM SHOW=ALL` parameter of the utility has no effect). A CLOSE for the file causes FLAM to close the FLAMFILE and free all the work areas again that were requested with the OPEN. New OPEN calls are now allowed. === Restrictions It is not normally necessary to modify the JCL as a result of using the FLAM subsystem. If specifications such as the record and block lengths are omitted from the programs (utilities such as IEBGENER and SORT function in this way), however, DCB specifications must be included in the DD statement! The usual principle, whereby the values are automatically taken from a catalog entry in such cases, does not work if a subsystem is used. An OPEN routine only recognizes the actual presence of a subsystem file and no longer accesses a catalog entry (even if one exists). ==== In general [width='100%',cols='^1,12',align='center'] | *ADC* | `MODE=ADC` is not allowed in update mode. | *DGD* | Data Generation Groups must be specified with the absolute name   (`FILE.G0004V00`), not with the relative name (`FILE(+1)`). | *DISP* | The DISP parameter in the DD statement (e.g. `DISP=NEW` or   `DISP=(..., DELETE)` cannot be interpreted  and thus has no effect.   All files that are assigned directly via FLAM-sub   (`DSN=filename, SUBSYS=FLAM`) must be cataloged.   If new files must be created, a second DD statement can be used as shown   in the example JCL below this table. Alternatively, the file must have   been created in a previous STEP.   All types of access (GET, WRITE, PUT, POINT, ERASE, CHECK) with   appropriate RPL modifications for VSAM are possible via the subsystem.   The following restrictions apply (see also:   https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sc236852/$file/idad500_v2r3.pdf[manual DFSMS/MVS Macro Instructions for Data Sets]). ==== DCB calls (PS files) [width='100%',cols='^1h,12',align='center'] |CLOSE  |All attempts to write in LOCATE mode are rejected. |LOCATE |Data Generation Groups must be specified with the          absolute name (FILE.G0004V00), not with the relative name (FILE(+1)). |POINT  |A POINT in conjunction with BSAM accesses is rejected          with the error message IEC141I 013-BC .. (it is not even          passed on to the subsystem). |VBS    |A file with RECFM=VS or VBS (spanned records) can be          written in but not read (IEC141I 013-A8 ...). ==== ACB/RPL calls (VSAM files) [width='100%',cols='^1h,12',align='center'] |CHECK      |Asynchronous calls are executed synchronously by              FLAM-sub (though, as usual, no response to errors until CHECK). |CNVTAD     |CNVTAD returns invalid specifications or zero. |ENDREQ     |ENDREQ (terminate a request) has no effect (FLAM              does not support locks and only holds the last key). |RPL        |Accesses with more than one RPL (RPL list) are not              supported (only the first RPL is interpreted). |SHOWCB     |`SHOWCB ACB=...` +              The CINV, KEYLEN, LRECL and RKP fields contain the              values for the original file, while all other specifications              (such as ENDRBA, HALCRBA, etc.) refer to the FLAMFILE. |VERIFY     |VERIFY (synchronize end of data) has no effect (VSAM              control blocks are not updated). |VSAM-KSDS  |If a VSAM-KSDS file must be loaded via FLAM-sub              (OPEN OUTPUT in the program), the position and              length of the key must be notified to the subsystem              (important: the key position is 1 byte higher for FLAM              than the RKP for IDCAMS!) see example JCL following this table.              The reason for this is as follows:              These specifications are normally transferred by              means of IDCAMS when the file is cataloged. With              VSAM accesses these specifications are contained in              the catalog entry and not in the ACB. The FLAMFILE              has been cataloged there with completely different              values however, so that the parameters of the original              file are no longer available. This information is              contained in the compressed file for all subsequent              accesses (INPUT or I/O) and does not need to be              specified again. [[flam4.flamsub.used.parameters]] === Used FLAM parameters Parameters for FLAM are transferred in the DD statement of the SUBSYS specification: or The used parameters correspond to those of the FLAM utility (see <<CLEP.COMMAND.FLAM,FLAM command>>). Parentheses () can also be used instead of the equals sign '=', e.g. MO(ADC). Any apostrophes contained within the parameter string literal must be duplicated (e.g. SUBSYS=(FLAM,'CRYPTOKEY=C''PASS WORD WITH BLANKS'''). Valid FLAM utility parameters available in FLAM-sub: [width='90%',cols='2,1,4',align='center',options='header'] |Parameter   | short form | Link (use z/OS parameter only) |CRYPTOMODE  | CRYPTOM    | <<CLEP.COMMAND.FLAM.CRYPTOMODE,FLAM CRYPTOMODE>> |CRYPTOKEY   | CRYPTOK    | <<CLEP.COMMAND.FLAM.CRYPTOKEY,FLAM CRYPTOKEY>> |FILEINFO    | FI         | <<CLEP.COMMAND.FLAM.FILEINFO,FLAM FILEINFO>> |FLAMDDN     | FLAMD      | <<CLEP.COMMAND.FLAM.FLAMDDN,FLAM FLAMDDN>> |HEADER      | HE         | <<CLEP.COMMAND.FLAM.HEADER,FLAM HEADER>> |KMEXIT      | KME        | <<CLEP.COMMAND.FLAM.KMEXIT,FLAM KMEXIT>> |KMPARM      | KMP        | <<CLEP.COMMAND.FLAM.KMPARAMETER,FLAM KMPARM>> |MAXBUFFER   | MAXB       | <<CLEP.COMMAND.FLAM.MAXBUFFER,FLAM MAXBUFFER>> |MAXRECORDS  | MAXR       | <<CLEP.COMMAND.FLAM.MAXRECORDS,FLAM MAXRECORDS>> |MAXSIZE     | MAXS       | <<CLEP.COMMAND.FLAM.RECSIZE,FLAM MAXSIZE>> |MODE        | MO         | <<CLEP.COMMAND.FLAM.MODE,FLAM MODE>> |MSGDDN      | MSGD       | <<CLEP.COMMAND.FLAM.MSGDDN,FLAM MSGDDN>> |ODSORG      | ODSO       | <<CLEP.COMMAND.FLAM.ODSORG,FLAM ODSORG>> |OKEYLEN     | OKEYL      | <<CLEP.COMMAND.FLAM.OKEYLENGTH,FLAM OKEYLEN>> |OKEYPOS     | OKEYP      | <<CLEP.COMMAND.FLAM.OKEYPOSITION,FLAM OKEYPOS>> |SECUREINFO  | SEC        | <<CLEP.COMMAND.FLAM.SECUREINFO,FLAM SECUREINFO>> |SPLITMODE   | SPLITM     | <<CLEP.COMMAND.FLAM.SPLITMODE,FLAM SPLITMODE>> |SPLITNUMBER | SPLITN     | <<CLEP.COMMAND.FLAM.SPLITNUMBER,FLAM SPLITNUMBER>> |SPLITSIZE   | SPLITS     | <<CLEP.COMMAND.FLAM.SPLITSIZE,FLAM SPLITSIZE>> |TRANSLATE   | TRA        | <<CLEP.COMMAND.FLAM.TRANSLATE,FLAM TRANSLATE>> It is possible to control FLAMSUB via environment or system variables as follows. An environment variable overwrites a system variable. [width='90%',cols='^1h,4',align='center'] |Environment variables |are stored in or set in a C program. It is used in the actual STEP only and must be repeated for every other STEP. |FL_ZEDC_SUPPORT |controls use of ZEDC hardware algorithm. *Possible values:*       ADC is still in effect on compression.       Decompression will be done in       software, if ZEDC-compressed data       is found.       Instead of ADC, ZEDC is used. Without       hardware, software is used. *Default:* without variable, ZEDC hardware is            used when found. Otherwise, ADC is still            in effect. *Valid for:* * compression * decompression. NOTE: When ZEDC hardware is not found and the algorithm is required, a software routine is used. |System Variable |are stored in `SYS1.PARMLIB(IEASYMxx)`. When system- and environment variable are found, the environment variable is used. A system variable is used system-wide in any STEP. |&FLZEDC |Controls using of the ZEDC hardware-algorithm. *Possible values:* +       ADC is still in effect on compression.       Decompression will be done in software,       if ZEDC compressed data is found.      Instead of ADC, ZEDC is used.      Without hardware, software is used. *Default:* without variable, ZEDC hardware is            used when found. Otherwise, ADC is still            in effect. *Valid for:* * compression * decompression |&FLOGQL1 |First qualifier in logstream with name LOGR. Without this parameter no logging is done. *Possible values:* + * 1-8 characters as in IXCMIAPU defined. Activates FLAM logging. |&FLOGQL2 |Second qualifier in logstream with name LOGR. *Possible values:* + * 1-8 characters as in IXCMIAPU defined. |&FLOGQL3 |Third qualifier in logstream name of LOGR. *Possible values:* + * 1-8 characters as with IXCMIAPU defined *Valid for:* * compression * decompression *Example:* IXCMIAU defines the logstream name FLAM.USAGE Then in Parmlib member must be stored: NOTE: Without any system variable FLAM cannot log any data. Look for some examples for how to define a logstream in FLAM.JOBLIB. === Subsystem control parameter These parameters are keyword parameters that must be specified separately from the FLAM parameters. They serve control of the subsystem and have nothing to do with FLAM: [width='90%',cols='^1h,9',align='center'] |IG10  |Causes return code 10 (not a FLAMFILE) to be ignored when         opening for reading. The records are transferred to the calling         program without being decompressed.         This parameter is meaningful in systems which can contain both         compressed and uncompressed files (e.g. for tests). |TRACE |Activates the TRACE function.         All function calls to FLAM and the control blocks (ACB, RPL) of the         calling program are traced.         The trace file must be specified in the JCL. The FLAM parameter         `MSGDDN=ddname` specifies the DD name (default: `FLPRINT`). [[flam4.subsystem.messages]] === Subsystem messages FLAM-sub only outputs a message on the console in the event of an error (by means of WTO ,ROUTCDE=11). This message is also documented in the JCL log. The letter after the message number specifies the time at which the error was detected: [width='50%',cols='^1h,4',align='center'] |I |When the subsystem was initialized |C |When the JCL was analyzed |A |When the file was allocated |O |When the file was opened |D |During the I/O operation |E |When the file was closed Except when the subsystem is initialized during the IPL of the operating system, errors only affect the specified file for a particular job, in other words the subsystem remains active for the other files. [width='100%',cols='^1h,12',align='right'] |FLM0500I |*INITIALIZATION OF SUBSYSTEM FLAM COMPLETED*             The FLAM subsystem has been initialized correctly and is now available.             Response: None |FLM0501I |*SUBSYSTEM FLAM NOT INSTALLED ON THIS SYSTEM*            The subsystem cannot be initialized. It has not been            installed on the computer.            Response: Insert the entry FLAM,FLSSIPL in SYS1.PARMLIB(IEFSSN..). |FLM0502I |*SUBSYSTEM FLAM ALREADY INITIALIZED*            The program for initializing the subsystem was restarted            after the IPL and then rejected. The subsystem that was            already active is still active.            Response: FLAM-sub need not be restarted. |FLM0503I |*NO MEMORY RECEIVED FOR INITIALIZATION*            The operating system cannot make any memory available for initialization.            The subsystem is not active.            Response: An analysis is necessary (system dump). |FLM0504I |*SUBSYSTEM COULD NOT FREE SYSTEM MEMORY*            The memory made available by the operating system            cannot be freed. The subsystem has nevertheless been            initialized and is now available.            Response: An analysis is necessary (system dump). |FLM0505I |*SUBSYSTEM FLAM FUNCTION MODULE NOT FOUND*            A FLAM-sub module required to initialize the            subsystem is missing. The module was named by a            previous operating system message. The subsystem            has not been initialized.            Response: Store the subsystem modules in a library            belonging to the LINKLIST concatenation. |FLM0506I |*MODULE IEFJSVEC NOT FOUND*            The IEFJSVEC operating system module required to            initialize the subsystem is missing.            The subsystem has not been initialized.            Response: Set the missing module in a library            that has been linked with the LINKLIB. |FLM0507I |*IEFJSVEC: NO MEMORY FOR SSVT*            The subsystem initialization procedure was aborted by            the IEFJSVEC operating system module because there            is insufficient memory.            Response: An analysis is necessary (system dump). |FLM0508I |*LOGIC ERROR IN IEFJSVEC*            The subsystem initialization procedure was aborted by            the IEFJSVEC operating system module due to an            internal error.            Response: An analysis is necessary (system dump). |FLM0510I |*INTERNAL ERROR. RC = no* +            An internal error has been detected.            The subsystem has not been initialized.            Response: Please inform your sales partner. |FLM0515I |*INITIALIZATION OF SUBSYSTEM FLAM FAILED*            The subsystem cannot be initialized due to an error.            The error situation was documented in a previous            message. |FLM0519I |*FLAM SUBSYSTEM IS NOT LICENSED*            The license does not allow use of the subsystem. |*FLM0520C*/ *FLM0502C* | *PARAMETER ERROR: ...* /  *SYNTAX ERROR: ...*            An invalid parameter was entered in the DD statement            of the JCL for FLAM-sub               Response: Correct <<flam4.flamsub.used.parameters,parameters for FLAM>> and restart job. |FLM0523C |*NO MEMORY RECEIVED FOR JCL-CONVERTION*             A subsystem module was not allocated any memory by             the operating system.             Response: An analysis is necessary (system dump). |FLM0530A |*PARAMETER ERROR: ...* / *SYNTAX ERROR: ...*             An invalid parameter was entered in the DD statement             of the JCL for FLAM-sub. The invalid parameter is displayed.             Response: Correct <<flam4.flamsub.used.parameters,parameters for FLAM>> and restart job. |FLM0531A |*NO MEMORY RECEIVED FOR ALLOCATION*             A subsystem module was not allocated any memory by             the operating system.             Response: An analysis is necessary (system dump). |FLM0540O |*OPEN ERROR. DDNAME=ddname. RC= no (FLAM)/(VSAM)*            An error was detected at the time of the open for the            file assigned in the JCL with ddname. FLAM return            codes are specified in decimal format and VSAM errors            in hexadecimal format see also            <<CLEP.APPENDIX.REASONCODES,reason codes>>,            <<CLEP.APPENDIX.RETURNCODES,return codes>>            and DFSMS Macro Instructions).            This message is followed by the IEC141I 013-xx message of            the data management system, whereby the DD name used by the            program is output. The message IEC161 may be output in            connection with VSAM accesses.            The reported FLAM message numbers are equal to the numbers            in FLAM utility (ch. 8 in the manual FLAM(MVS)).            In the table below are some examples. |FLM0541O |*ALLOCATION FAILED FOR DSN filename SVC99 ERROR CODE = no1. INFO CODE = no2.*            An error was detected when an attempt was made to            allocate the file filename dynamically. The codes are            specified in hexadecimal format.            Response: Analyse the error and info codes of the SVC99 as described in the            https://www-01.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R3sa231371/$file/ieaa800_v2r3.pdf[MVS Programming: Authorized Assembler Services Guide, GC28-1763].            e.g. error code = 1708, info code = 2 or 5 means: File is            not cataloged (remember: only cataloged files are            allowed using FLAM-sub). |FLM0543O |*TRANSLATE-PARAMETER INVALID WITH OPEN I/O - IGNORED*            The TRANSLATE parameter is ignored in connection with an OPEN I/O.            Input and output records can only be translated            according to the specified table with an OPEN INPUT or an OPEN OUTPUT.            Processing continues without translating the data. |FLM0544O |*FORCED BY PARAMETER TO ACCESS AS UNCOMPRESSED DATA*            No FLAMFILE was identified when a subsystem file was            opened (message: FLM0440O with RC=10). The set            subsystem parameter IG10 forces processing to            continue on the basis of an uncompressed (original)            file.            Important: If there is no original (uncompressed) file,            unpredictable errors may occur. |FLM0552D |*I/O ERROR. DDNAME = ddname. RC = no (FLAM)/(VSAM) file-name*            An error was detected by the FLAM subsystem while            reading or writing in the specified file file-name. FLAM            return codes are specified in decimal or hexadecimal            format and VSAM errors in hexadecimal format.            This message may be followed by the IEC020I 001-..            message of the data management system.            You can find a list of VSAM return codes in the manual            entitled 'DFSMS Macro Instructions'.            All FLAM return codes are listed in the section            <<CLEP.APPENDIX.RETURNCODES,return codes>>. Examples can be            found in a following table. |FLM0553D |*NO MEMORY RECEIVED FOR I/O OPERATIONS*            A subsystem module was not allocated any memory by            the operating system. Consequently, no other information is available.            Response: Specify a higher value for REGION in the EXEC statement. |FLM0570E |*CLOSE ERROR. DDNAME = ddname. RC = no file-name*            An error was detected when an attempt was made to            close the specified file.            Since compressed-file records may have to be written            as well when a file is closed, see also FLM0552D message. [width='90%',cols='^1,12',align='center'] |no:       |Description (FLM0540O) |-1        |Not enough memory (license rights may have been violated) |10        |The file is not a FLAMFILE (input or I/O |11        |FLAMFILE format error |12        |Record length error |13        |File length error |14        |Checksum error |21        |Illegal matrix buffer |22        |Illegal compression method |23        |Illegal CODE in FLAMFILE |24        |Illegal BLOCKMODE |25        |Illegal record length |31        |File not assigned (DD statement missing) |33        |Invalid file type |34        |Invalid record format |35        |Invalid record length |36        |Invalid block length |40        |Cannot load module or table (TRANS parameter) |60 - 78   |FLAM syntax error |120       |Name generation in error. Generating a new file name is             impossible due to the lack of digit numbers in the name (i.e. only 1             digit number is in the name, cannot generate more than 9 file names). |121       |One fragment of the split FLAMFILE is missing. |122       |Sequence check error of a serially split FLAMFILE. The fragments             are not in ascending order. |123       |Fragments of the split FLAMFILE do not belong together. |124       |The FLAMFILE was split in more fragments than the actual version             can handle. |130       |Security violation: FLAMFILE is not in original state during read (i.e.             concatenation of FLAMFILEs, updates, inserts). Allowed to be ignored (SEC=IGNORE). |131       |Missing records in a FLAMFILE. Allowed to be ignored. |132       |A member was inserted into a group FLAMFILE. Allowed to be ignored. |133       |Sequence error: FLAMFILE records are not in ascending order. Allowed             to be ignored. |134       |Security error: FLAMFILE starts without security information, but             then one were found. Cannot be ignored. +             Perhaps concatenation of FLAMFILEs without and with security information. |531       |Some fragments missing during decompression and parallel split |Response: |If RC = -1 and correct license, specify a higher value for REGION             in the EXEC statement; if RC = 11 - 14, the file is no longer available in             its original state, the data contents have been modified (possibly by a             file transfer program) or another type of error has occurred and             must be rectified by following the instructions provided.             Some security violations are allowed to be ignored, but take             care of the situation. [width='50%',cols='^1,4',align='center',options='header'] |no: |Description (FLM0552D) |11  |FLAMFILE format error |12  |Record length error |13  |File length error |14  |Checksum error If one of the above codes is returned, the data in the FLAMFILE has been mutilated (e.g. as a result of a file transfer). [width='50%',cols='^1,4',align='center',options='header'] |no:     |Description |7       |Password not declared |15      |Record length greater than 32 KB |16      |Record length greater than MAXB - 4 |25      |Illegal record length |29      |Password in error |123-134 |see FLM0540O Detecting a security violation the FLAM error code is reported as a hexadecimal value (nn**mmmm**). + *nn* describes, where the error was detected: [width='50%',cols='^1,4',align='center',options='header'] |nn |Description |01 |Header |02 |Segment |03 |Membertrailer |04 |Filetrailer *mmmm* is the error: [width='50%',cols='^1,4',align='center',options='header'] |*mmmm* |Description |0001   |MAC1, the data MAC |0002   |MAC2, the chaining MAC |0003   |MAC3, the MAC over MACs |0010   |data missing |0020   |data inserted |0040   |data updated |0080   |record counter compressed data |0100   |byte counter compressed data |0200   |record counter original data |0400   |byte counter original data |0800   |chaining on FLAM encryption The error codes are ORed, e.g. 030180 means: record and byte counter of the compressed data do not fit with the stored information, detected in the member trailer. It is allowed to ignore these violations (SEC=IGNORE), but take care of the situation. === Installing FLAM-sub FLAM-sub installation including installation instructions can be downloaded from our website: https://flam.de/ or by using the following link: https://flam.de/en/download/flam/latest/zSeries/zos/31bit/ There you can find downloads using SMP/E (System Modification Program/Extended) and XMIT (Transfering Load Modules between Mainframes). FLAM-sub is an interface to FLAM (z/OS), the compression and encryption utility, and may only be used in conjunction with a license for the FLAM utility. [[flam4.flamsub.examples]] === Examples ==== Input/output with cataloged files The USER.EXAMPLE.INPUT file has been created as a compressed file (FLAMFILE), for example with the FLAM utility. It must now be read by another program. The USER.EXAMPLE.OUTPUT file was created by this program previously and must now likewise be compressed. Both files are cataloged. Two different procedures are possible. a) When the file was opened, the program specified the record and block lengths in the ACB or the DCB (or in the FD section if COBOL programs are used). Solution: The SUBSYS specification in the DD statement is sufficient. Since the 'correct' values are specified in the calling program, the data records are transferred to or from the subsystem in accordance with them. b) The calling program assumes that an 'original' catalog entry exists, i.e. neither a record length nor a block length is specified in the program (IEBGENER, SORT and numerous utilities function in this way). Solution: Specify additional DCB attributes in the DD statement. The program is presented with the specified DCB attributes, irrespective of the actual catalog entry. The subsystem transfers records in accordance with these specifications. FLAM, on the other hand, reads or writes compressed-file records on the disk in cataloged format. The subsystem activity is confirmed by the system messages in the JCL listing. ==== FLAM parameters and subsystem Cf. example 1, except that a specific compression method (ADC) must be set for the output file. Solution: Enter the necessary parameters in the SUBSYS specification of the DD statement. The FLAM utility and the ''D,SHOW(ATT)'' parameters or the I OPTION in the FLAM panels allow you to check whether the compression procedure is successful. ==== Creating a new file A file called USER.EXAMPLE.NEWDAT must be created. It is not cataloged: Solution: Specify a second DD statement for FLAM-sub. The original file description is given a new DD name, to which a FLAM parameter in the SUBSYS specification refers. The compressed file USER.EXAMPLE.NEWDAT is thus created exactly the same as the original. The advantage of this method is that any subsequent copy or transfer programs which function without the SUBSYS specification will find the same catalog entry as for the original and therefore do not need to be specially tuned. The new DD statement requires the DCB specification, since it was also mandatory in the original. Otherwise, the compressed file can be set in any way, e.g.: As far as the calling program (and the subsystem) is concerned, the original records are 121 bytes long. The FLAMFILE, on the other hand, has longer records and blocks for performance reasons (this is the normal, recommended case). The file descriptions can thus be separated from one another. ==== Temporary files FLAM-sub cannot process any temporary files directly. A second DD statement is necessary for this purpose. It is not necessary to specify a file name on account of the FLAMDD specification for DDNAME. A temporary file name is generated automatically by JES. FLAM-sub branches directly to the temporary file. ==== Other subsystems Other subsystems, such as JES for SYSOUT/SYSIN, must be activated by means of a second DD statement. Depending on the program which is used, it may be necessary to specify DCB parameters in order to process the original file (DDNAME statement, cf. example 1). ==== Loading a VSAM-KSDS file If a KSDS file is loaded, the file is opened for writing (OUTPUT). The keys must be transferred to VSAM in ascending order (this is also checked by FLAM-sub). It is possible to load the file in I/O mode, in other words it must contain at least one record. At the same time, this leads to a deterioration in performance and an increase in the number of accesses. The file itself is normally created using IDCAMS and is already cataloged when the job is executed. The simplest method is to create a compressed KSDS file with the FLAM utility. ===== Load a real VSAM-KSDS file A ''real VSAM-KSDS file'' means, an ACB is provided to open the data set. When the file is loaded via the subsystem, the key description of the original data must be specified in the form of parameters: The original records are up to 512 bytes long in this example, while the control interval takes up 20480 bytes and the key begins at position 21 and is 64 bytes long. The subsystem should use the full record length of the VSAM file (7168 bytes). NOTE: FLAM counts the key position starting at 1 (corresponds to RKP=0). The VSAM file itself requires the entries (see also <<flam4.flamsub.preconditions,PRECONDITIONS>>) for the example: Important: Even if a higher value is specified for `RECSZ`, the FLAMFILE record length is restricted to 7168 bytes by the `MAXS` parameter. NOTE: A VSAM file must be empty when it is loaded, in other words either it must not contain any records or the REUSE parameter must have been specified for IDCAMS, to allow the file to be overwritten. ===== Load a VSAM-KSDS file via a utility Most utilities (like IEBGENER or SORT) use a DCB to access a subsystem data set. FLAM subsystem then normally declares the data as physical sequential (PS) and has no knowledge about a key description. Subsystem parameter overwrite this situation and force the subsystem to recognize the output data as key sequenced records: The original records are up to 512 bytes long in this example, while the control interval takes up 20480 bytes and the key begins at position 21 and is 64 bytes long. The subsystem shall use the full record length of the VSAM-KSDS file USER.EXAMPLE.OUTPUT (7168 bytes). NOTE: FLAM counts the key position starting at 1 (corresponds to RKP=0). The VSAM file USER.EXAMPLE.OUTPUT itself requires the entries (see also <<flam4.flamsub.preconditions,PRECONDITIONS>>) for the example: *Important:* Even if a higher value is specified for RECSZ, the FLAMFILE record length is restricted to 7168 bytes by the MAXS parameter. NOTE: FLAM subsystem checks the ascending order of the key sequence of the output records and returns the VSAM return code, if in error. The utility normally is unaware of this situation and returns a 'WRITE ERROR' without any further information. ==== TRACE function A trace function is activated for both the input file and the output file for test purposes: Different files must be specified for the trace. FLTRACE is the assignment for the OUTPUT file trace. FLPRINT is taken as the default name, since no parameter has been specified in the DD statement. The trace for INPUT is as follows (the records have been shortened here): The names of the FLAM functions (FLMOPN, FLMGET, etc.) and their parameters are equal to those listed in the manual for FLAM V4 (Chapter 3, Interfaces). The parameters are numbered in the same way as in the manual. The next specification is the parameter address. The parameter contents are enclosed in parentheses ''()''. The control blocks ACB and RPL are specified by the subsystem interface, even if a PS file is accessed. Please refer to the IBM manuals for further details of these control blocks, e.g. ''Macro Instructions for VSAM Data Sets'', ''Data Areas'', or to the ''SYS1.AMODGEN(IFGACB)'' and ''SYS1.AMODGEN(IFGRPL)'' macros. ==== FLAMFILE split ===== Serial split To split a file in several fragments, depending on the amount of data, the serial split is used. The file FLAM.SUBDAT.A01.ADC is cataloged, the filename has two numeric characters (at least 1 numeric character is necessary). Compression method ADC is used for higher compression. One file must not exceed 200 MB data. When more than 200 MB data are to be written, file FLAM.SUBDAT.A01.ADC is closed and file FLAM.SUBDAT.A02.ADC is searched and allocated, or if not found in the catalog, created. With two numeric characters it is possible to generate up to 99 files. If your organisation requires special filenames or a higher flexibility for data set allocation is needed, assigning with DD-names is recommended. Only the first DD- name is passed to the subsystem. All files must have the same record length, but the data set organization or format may differ. When more than 200 MB are to be written, the file with DD-name CMP01 is closed and CMP02 is opened. To read a split FLAMFILE it is not necessary to pass any parameter to the subsystem. The filename of the first fragment is named in the DD-statement: All following files will be allocated dynamically by the subsystem. Assigning files via DD-statement is possible as well. The DD-name must have at least one numeric character, the first name is passed to the subsystem: NOTE: The files must be assigned in the same order as they were written. The subsystem checks the sequence of the files. In case of errors, message FLM0540O and RC=122 is reported, and the data management system detects an open error. ===== Parallel split Parallel split means: up to 4 files are written or read in parallel. All files must be cataloged and assigned within JCL! Therefore, it is necessary to assign the subsystem files via the DD-statement. The DD-name must have at least one numeric character, the first name is passed to the subsystem. All files must have the same record length, but the data set organization or format may differ. JCL required for reading a split FLAMFILE in parallel: The files may be in different order than they were written, the subsystem uses the original order automatically. NOTE: If one file is missing, message FLM0540O with RC=531 is reported by the subsystem and the data management system detects an OPEN-error. Using `DISP=NEW` in the assigned DD-statements will lead to a system error 50D, so it is really necessary to catalog all files. ==== Encryption ===== Encryption via CRYPTOKEY parameter To encrypt/decrypt the file a key is passed (`CRYPTOKEY=...`) to the subsystem. The cryptographic method is chosen by parameter `CRYPTOMODE`. Without this parameter, method FLAM is used (compatible to FLAM-sub V3): Using parameter PASSWORD instead of CRYPTOKEY is allowed and compatible to FLAM-sub V3. Please remember: Any apostrophes contained within the parameter string literal must be duplicated: ===== Encryption via KME-module A program name that supports the <<flam4.appendix.kmexit,FKME-interface>> will be used as followes: This method benefits from a fully automatic encryption/decryption without any manual user action. The key used for encryption is never seen in any protocol. ===== Encryption using FKMEFILE Program FKMEFILE is an example for using the KME interface. It reads a record containing a key from a sequential file and returns it to the subsystem. A parameter ddname is needed for the file to read. The key must be the first record of the file. The syntax is as of parameter CRYPTOKEY: the key may be a string, a C'string with blanks', a A'key in ascii', or a X'hexvalue'. Trailing blanks are ignored. Just to test it on the fly: ====   Using zEDC =====  Automatically With `MODE=ADC` the zEDC accelerator card zEDC will be used, when it is installed. Nothing else is to be done. On decompression: If no card is found and the compression mode was zEDC a software routine decompresses the FLAMFILE. ===== Never Setting an environment variable for the actual job, the zEDC algorithm will not be used, although the card was found. Same for all jobs when a system variable is defined in SYS1.PARMLIB(IEASYMxx): `*SYMDEF(&FLZEDC='OFF')*` ===== Always zEDC Setting an environment variable for the actual job, the zEDC algorithm will be used, although the card was not found. Same for all jobs when a system variable is defined in SYS1.PARMLIB(IEASYMxx): `*SYMDEF(&FLZEDC='ON')*` ",
"",
""
],
[
"flam4_manual-user_i_o_interface_b393.html",
"User I/O Interface",
"== User I/O Interface The user interface for I/O allows FLAM to use user-defined file access methods instead of the operating system defined ones. This is possible when using the FLAM utility for the original file and when using the *FLAM record interface* for both original file and compressed FLAM file. One possibility is to pass the compressed records immediately to post-processing routines without creating a compressed file. During decompression, the compressed records may be received from pre-processing step instead of reading them from a file. A direct application could be the integration of FLAM with a file transfer application, avoiding the creation of intermediate files. Generally this interface allows intercepting all input and output data of both FLAM and FLAMUP. This allows the user to adapt FLAM easily to specific access methods. === Using user I/O interface The user can replace the FLAM file accesses methods with custom file access methods by using the User I/O interface. These access methods are used by the FLAM utility for accessing the original file, the compressed file and the target file. In the record level interface, however, only access routines for the compressed file exist. The use of user-defined access routines can be specified for each file separately via the parameters `DEVICE=USER` or `IDEVCE`, `ODEVICE`. However, the user-provided I/O routines must be linked to the FLAM utility or to the FLAM record level interface before. The following routines must be provided by the user: * Open and Close (USROPN, USRCLS) * Sequential Read and Write (USRPUT, USRGET) * Optionally random access Read and Write (USRPKY, USRGKY) * Delete and Positioning (USRDEL, USRPOS). ==== How does it work [width='100%',cols='h,1*',align='right'] |`USROPN` |For each allocated file this function is called once and only once. A working area of 1024 bytes is passed to the routine. This working area acts as file-specific memory and is passed from function to function until USRCLS is called. Files are identified via symbolic file names. The access mode is specified in parameter `OPENMODE`: INPUT, OUTPUT, INOUT, OUTIN. File format and file attributes are specified in the parameters `RECFORM`, `RECSIZE`, `BLKSIZE`, etc. These settings may be adapted to special requirements. Via pre-defined and user-defined return codes, the successful execution as well as special status information and errors can be reported to the higher layers. |`USRCLS` |This function is called to close the file. The 1024 bytes working area reserved for this file is de-allocated after returning control to FLAM. |`USRGET` |This function is called to retrieve the next record. The maximum amount of characters that may be returned is specified in parameter `BUFLEN`. If it is necessary to truncate the record, this must be signalled via a return code. Also, the end of file condition must be signalled via a return code. For each record returned, the record length must be returned as well (also for records with fixed record length!). |`USRPUT` |This function is called to write a record. If it is not possible to write the record in full length, the return code record truncated must be reported to the higher layers. Another possibility is to fill the record with the padding character (`PADCHAR`) as specified in `USROPN` and to return the corresponding return code. |`USRPOS` |This function is called to move the current read or write pointer. Relative positioning (forward and backward) from the current position as well as absolute positioning from file start or file end is possible. |`USRGKY` |With this function, a record with a specified key is read. The corresponding key is contained in the record area at the position and in the length as specified with the parameter `KEYDESC` during `USROPN`. Reading by key also sets the current read pointer for following `USRGET` function calls. If no record is found, this must be signalled via a return code. Afterwards it is possible to read the record with the nearest higher key with function `USRGET`. |`USRPKY` |With this function, a record with a specified key is updated or inserted. If the record has the same key as the record last read, the old record is replaced with the new record. Otherwise, the record is inserted. If this is not possible (duplicate keys may be forbidden), this must be signalled via an appropriate return code. The writing of records with a key also updates the position of the current write pointer. |`USRDEL` |With this function the last read record is deleted. ==== Compression (schematic) image::pics/flam4_user_io_compression.png[User IO compression,align='center'] *Parameter for FLAM or FLAMUP:* COMPRESS, IDEVICE = USER, DEVICE = USER ==== Decompression (schematic) image::pics/flam4_user_io_decompression.png[User IO decompression,align='center'] *Parameter for FLAM or FLAMUP:* DECOMPRESS, ODEVICE = USER, DEVICE = USER === Examples ==== ASSEMBLER example This example sets up a DUMMY device that returns immediately the return code END OF FILE during read. During write, all records are accepted and OK is always returned without actually writing the records to a storage medium. The functions `USRGKY` and `USRPOS` always end with the return code INVALID KEY or INVALID POSITION. The function `USRDEL` always returns the code INVALID FUNCTION. This functionality is equivalent to a file assignment of DUMMY. By filling in appropriate code into the sequences marked with three periods, this routine can be used as a template for specific user written I/O routines. ==== COBOL example The user I/O can also be implemented in COBOL or in another higher programming language. The following example implements two different functions that can be selected via the symbolic file name (LINKNAME or DDNAME). Using the DD-name DATBASE, ten records can be read with the content: 'THIS IS A DATA BASE RECORD FROM THE USER I/O' Then return code END OF FILE is returned. Using DD-name 'USER...', 20 records can be read with the content: 'THIS IS A USER RECORD FROM THE USER I/O' Then return code END OF FILE is returned. In both cases, the call protocols are written to the terminal. This allows to observe precisely the sequence of the different calls. ",
"",
""
],
[
"flam4_manual-user_exits_013c.html",
"User Exits",
"== User Exits To be even more flexible, FLAM provides user exits which can be used for pre- and post-processing of uncompressed records as well as FLAMFILE records. User exits are needed for inserting, deleting and editing records or fields before or after a compression or decompression procedure. FLAMFILEs can also be modified to make it personal and incompatible by swapping bytes via FLAM user exits. The effect is basically the same like enciphering (by symmetrical exit modules). Code conversion is controlled via standard code tables or user defined code tables. For special cases where a 1:1 code conversion is not possible for all characters, user exits can be used, too. === Specific Addressing Modes User exits can be written for any addressing mode (`AMODE=ANY`, `AMODE=31`, `AMODE=24`, no mode specified). The addressing mode only has to be taken into account if FLAM is loaded with `AMODE=31` and, for some reason, the user exit is only able to run with `AMODE=24`. Only in this case, the addressing mode must be switched in the user exit itself. It must be noted that the save area, the return address, the parameter list and the parameters can be addressed only in `AMODE=31`. The addressing mode used by FLAM is stored in the most significant bit of register R14 and can be looked up there. In all other cases, the addressing mode is already set correctly and it is switched over again by FLAM after the return, if this is necessary. It is irrelevant whether the return is executed with a BR14 or a BSM 0,14 (Branch and Set Mode is a return branching instruction that set the addressing mode). === Original Data Input EXK10 This user exit serves as an interface between the data record that is transferred to FLAM for compression. Special processing can be defined for: * start of file * record level * end of file Records can be passed on, modified, deleted or inserted. This exit can be used to modify records in a structure dependent way. EXK10 is only available in FLAM and FLAMUP and corresponds to EXD10 during decompression. ==== Principle of Operation EXK10 In this user exit, the original records (which shall be compressed) are passed to a user module immediately after they are read from the input file. This user exit can be used with the FLAM utility or with the subprogram FLAMUP. Records can be accepted, modified, inserted and deleted by this exit. The exit is activated via the parameter `EXK10=<user module name>`. The user exit module must be contained in the library that has been assigned with the STEPLIB command. [width='70%',cols='^2,^3',align='center'] |*user module name* |free choice (max. 8 characters) |*Register usage*   | |R1                 |Address of parameter list |R13                |Points to save area (18 words) |R14                |Contains return address |R15                |Contains call address (entry point) [width='90%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 |  0    |First call for file (after OPEN) |                 |  4    |Record read and passed |                 |  8    |Last call for file (before CLOSE) |**2. RETCO**     |*F*    |Return code |                 |  0    |Accept record / no error |                 |  4    |Do not accept record |                 |  8    |Insert record |                 | 12    |Enforce end of compression |                 | 16    |Error in user exit; abnormal termination |**3. RECPTR**    |*A*    |Record pointer |**4. RECLEN**    |*F*    |Record length (maximum 32760) |**5. EXWORK**    |*256F* |During the first call, the working storage area contains                            the symbolic file name of the original file within the                            first 8 characters. The rest of the area is padded with                            x00. This area can be used by the user exit module for                            any purpose. With each call this working storage area                            is made available again with the old content.                            NOTE: If a record shall be extended or inserted, the                            necessary working storage area must be provided by                            the user exit module.                            Return code 12 is only necessary if the compression                            shall be finished before the end of the input file is                            reached.                            For function code 0 and 8, no record is passed to the                            module. For function code 8, it is allowed to insert a                            record with return code 8.                            For return code 8, the record provided by the user exit                            module is processed. Then the user exit module is                            called again for the old record from the input file.                            The following table shows the *valid function and return codes:* [width='45%',cols='^2,^1,^1,^1,^1',align='center'] |Function code |    | 0 | 4 | 8 |Return code   |  0 | x | x | x |              |  4 |   | x | |              |  8 |   | x | x |              | 12 |   | x | |              | 16 | x | x | x === Compressed Data Output EXK20 This user exit treats compressed data before it is written to a FLAMFILE. Special processing can be defined for: * start of file * record level * end of file This exit can be used to modify records in a structure independent way. With this exit it is possible to modify the data with an own encryption routine or a special code translation can be applied if a non-transparent file transmission method shall be used. It is possible to insert own records in front of the compressed records, for example archiving control records or origin information. Another possibility is the extension of records to append specific revision information. EXK20 is available in FLAM, FLAMUP and FLAMREC and corresponds to EXD20 during decompression. ==== Principle of Operation EXK20 In this user exit, the compressed records are passed to a user module immediately before they are written to the compressed file. This user exit can be used with the FLAM utility or with the subprogram FLAMUP. This user exit can accept, modify, insert and delete records. The exit is activated via the parameter `EXK20=<user module name>`. The user exit module must be contained in the library that has been assigned with the STEPLIB command. [width='70%',cols='^2,^3',align='center'] |*user module name* |free choice (max. 8 characters) |*Register usage*   | |R1                 |Address of parameter list |R13                |Points to save area (18 words) |R14                |Contains return address |R15                |Contains call address (entry point) [width='90%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 | 0     |First call for file (after OPEN) |                 | 4     |Record passed |                 | 8     |Last call for file (before CLOSE) |**2. RETCO**     |*F*    |Return code |                 |  0    |Accept record / no error |                 |  4    |Do not accept record |                 |  8    |Insert record |                 | 12    |Enforce end of compression |                 | 16    |Error in exit; abnormal termination |**3. RECPTR**    |*A*    |Record pointer |**4. RECLEN**    |*F*    |Record length (maximum 32760) |**5. EXWORK**    |*256F* |During the first call the working storage area contains                            the symbolic file name of the original file within the                            first 8 characters. The rest of the area is padded with                            x00. This area can be used by the user exit module for                            any purpose. With each call, this working storage area                            is made available again with the old content.                            NOTE: If a record shall be extended or inserted, the                            necessary working storage area must be provided by                            the user exit module.                            Return code 12 is only necessary if the compression                            shall be finished before the end of the input file is                            reached.                            For function code 0 and 8, no record is passed to the                            module. For function code 8, it is allowed to insert a                            record with return code 8.                            For return code 8, the record provided by the user exit                            module is written. Then the user exit module is called                            again for the old compressed record. Table of valid function codes and return codes: [width='45%',cols='^2,^1,^1,^1,^1',align='center'] |Function code |    | 0 | 4 | 8 |Return code   |  0 | x | x | x |              |  4 |   | x | |              |  8 |   | x | x |              | 12 |   | x | |              | 16 | x | x | x === Original Data Output EXD10 This exit treats the decompressed records immediately before they are written to the target file. Special processing can be defined for: * start of file * record level * end of file Records can be passed on, modified, deleted or inserted. This exit can be used to modify records in a structure dependent way. EXD10 is only available in FLAM and FLAMUP and corresponds to EXK10 during compression. ==== Principle of Operation EXD10 In this user exit, the decompressed records are passed to a user module immediately before they are written to the output file. This user exit can be used with the FLAM utility or with the subprogram FLAMUP. This user exit can accept, modify, insert and delete records. The exit is activated via the parameter `EXD10=<user module name>`. The user exit module must be contained in the library that has been assigned with the STEPLIB command. [width='70%',cols='^2,^3',align='center'] |*user module name* |free choice (max. 8 characters) |*Register usage*   | |R1                 |Address of parameter list |R13                |Points to save area (18 words) |R14                |Contains return address |R15                |Contains call address (entry point) [width='90%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 | 0     |First call for file (after OPEN) |                 | 4     |Record passed |                 | 8     |Last call for file (before CLOSE) |**2. RETCO**     |*F*    |Return code |                 |  0    |Accept record / no error |                 |  4    |Do not accept record |                 |  8    |Insert record |                 | 12    |Enforce end of compression |                 | 16    |Error in exit; abnormal termination |**3. RECPTR**    |*A*    |Record pointer |**4. RECLEN**    |*F*    |Record length (maximum 32760) |**5. EXWORK**    |*256F* |During the first call the working storage area contains                            the symbolic file name of the original file within the                            first 8 characters. The rest of the area is padded with                            x00. This area can be used by the user exit module for                            any purpose. With each call this working storage area                            is made available again with the old content.                            NOTE: If a record shall be extended or inserted, the                            necessary working storage area must be provided by                            the user exit module.                            Return code 12 is only necessary if decompression                            shall be finished before the end of the compressed file                            is reached.                            For function code 0 and 8, no record is passed to the                            module. For function code 8, it is allowed to insert a                            record with return code 8.                            For return code 8, the record provided by the user exit                            module is written. Then the user exit module is called                            again for the old record.                            A change of the record length is accepted if the output                            file is defined with `RECFORM=V`. Table of valid function codes and return codes: [width='45%',cols='^2,^1,^1,^1,^1',align='center'] |Function code |    | 0 | 4 | 8 |Return code   |  0 | x | x | x |              |  4 |   | x | |              |  8 |   | x | x |              | 12 |   | x | |              | 16 | x | x | x === Compressed Data Input EXD20 This user exit treats the compressed data immediately after it is read from the FLAMFILE. Special processing can be defined for: * start of file * record level * end of file This exit can be used to modify records in a structure independent way. With this exit it is possible, to decrypt the data with an own decryption routine or to apply the reverse code translation as used during compression. For a proper operation of FLAM it is indispensable that all changes applied to the compressed data are reversible. User exit EXD20 must deliver exactly the same data as user exit EXK20 received. All modifications applied to compressed data with EXK20 must be undone with EXD20. EXD20 is available in FLAM, FLAMUP and FLAMREC and corresponds with EXK20 during decompression. ==== Principle of Operation EXD20 In this user exit, the compressed records are passed to a user module immediately after they are read from the compressed file. This user exit can be used with the FLAM utility or with the subprogram FLAMUP and in the record level interface FLAMREC. This user exit can accept, modify and delete records. The exit is activated via the parameter `EXD20=<user module name>`. The user exit module must be contained in the library that has been assigned with the STEPLIB command. [width='70%',cols='^2,^3',align='center'] |*user module name* |free choice (max. 8 characters) |*Register usage*   | |R1                 |Address of parameter list |R13                |Points to save area (18 words) |R14                |Contains return address |R15                |Contains call address (entry point) [width='90%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 | 0     |First call for file (after OPEN) |                 | 4     |Record passed |                 | 8     |Last call for file (before CLOSE) |**2. RETCO**     |*F*    |Return code |                 |  0    |Accept record / no error |                 |  4    |Do not accept record |                 |  8    |Insert record |                 | 12    |Enforce end of decompression |                 | 16    |Error in exit; abnormal termination |**3. RECPTR**    |*A*    |Record pointer |**4. RECLEN**    |*F*    |Record length (maximum 32760) |**5. EXWORK**    |*256F* |During the first call the working storage area contains                            the symbolic file name of the original file within the                            first 8 characters. The rest of the area is padded with                            x00. This area can be used by the user exit module for                            any purpose. With each call this working storage area                            is made available again with the old content.                            NOTE: If a record shall be extended or inserted, the                            necessary working storage area must be provided by                            the user exit module.                            Return code 12 is only necessary if decompression                            shall be finished before the end of the compressed file                            is reached.                            Because of the necessary synchronisation with the                            construction of the matrix, this return code is not                            always possible.                            For function code 0 and 8, no record is passed to the                            module. Table of valid function codes and return codes: [width='45%',cols='^2,^1,^1,^1,^1',align='center'] |Function code |    | 0 | 4   | 8 |Return code   |  0 | x | x   | x |              |  4 |   | x   | |              |  8 |   | x   | x |              | 12 |   | (x) | |              | 16 | x | x   | x [[flam4.appendix.kmexit]] === Key Management KMEXIT This user exit returns a key to the FLAM utility for en-/decryption of a FLAMFILE. So, it is possible to enter any PASWORD/CRYPTOKEY in a secure way without notice to the JCL or the protocol. This exit is implemented as an interface to special key management systems, without influence to the FLAM utility programs. ==== Principle of Operation KMEXIT This user exit is an interface to a special (e.g. user written) key management system. On encryption, parameters (`KMPARM=...`) are passed to the module. It returns a key for encryption of the FLAMFILE and a string of up to 512 bytes. This data is stored in the FLAMFILE as a user header (see parameter COMMENT or function FLMPUH). On decryption, parameters (`KMPARM=...`) and the data stored in the user header are passed to the exit. The module returns the same key as on encryption. It is up to the module, how to create a key and what kind of information is to be stored into the user header of the FLAMFILE. This data will help the module to find the correct key on decryption. The exit is activated via the parameter `KMEXIT=<user module name>`. The user exit module must be contained in the library that has been assigned with the STEPLIB command. [width='70%',cols='^2,^3',align='center'] |*user module name* |free choice (max. 8 characters) |*Register usage*   | |R1                 |Address of parameter list |R13                |Points to save area (18 words) |R14                |Contains return address |R15                |Contains call address (entry point) [width='90%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 | 0     |Decryption |                 | 1     |Encryption |**2. RETCO**     |*F*    |Return code |                 | 0     |No error |                 | else  |Error(s) detected |**3. PARMLEN**   |*F*    |Length of parameter (up to 256 byte) |**4. PARAM**     |*XLn*  |Parameter |**5. DATALEN**   |*F*    |Decryption: +                             -> Length of data +                            Encryption: +                            -> Buffer length of field DATA (512) +                            <- Length of returned data (max. 512) |**6. DATA**      |*XLn*  |PData (in length of DATALEN) |**7. CKYLEN**    |*F*    |Length of key for en-/decryption +                            -> Buffer length of field CRYPTOKEY (64) +                            <- Length of returned key (max. 64) |**8. CRYPTOKEY** |*XLn*  |Returned key (in length of CKYLEN) |**9. MSGLEN**    |*F*    |Message length +                            -> Length of message buffer (field MESSAGE) (128) +                            <- Length of returned Message length (max. 128) |**10. MESSAGE ** |*CLn*  |Returned message (in length of MSGLEN)                            If a message is returned (MSGLEN > 0), it is sent to the                            protocol (FLM0445 ...).                            The returned key is not sent to the protocol.                            The data DATA is stored 'as is' in the user header of                            the FLAMFILE. If special security is required, it has to                            be done by the exit.                            Usage of this exit overwrites the parameter COMMENT                            and CRYPTOKEY, if any.                            The exit is called only once if encryption of many files                            into a Group-FLAMFILE `(C,FLAMIN=user.*)` is required.                            It is called only at the beginning of the first file.                            The exit is called many times for decryption of many                            FLAMFILEs `(D,FLAMFILE=user.*.aes)`. It is called after                            opening each FLAMFILE.                            In the DD-statement, concatenated FLAMFILEs are                            treated as one FLAMFILE!                            NOTE: Look for an example in FLAM.SRCLIB (KMX-SAMPL). === User exits used by FLAM utility ==== Compression with EXK10, EXK20 image::pics/flam4_user_exit_comp_utility.png[User exit compression,align='center'] During compression, it is possible to call additional routines for pre-processing of original records and for post-processing of compressed records. E.g., pre-processing may perform a selection of specific records or fields. Post-processing may introduce additional encryption of the compressed record. Instead of using the more complicated record level interface record-orientated processing can be done often with user exit EXK10. ==== Decompression with EXD10, EXD20 image::pics/flam4_user_exit_deco_utility.png[User exit decompression,align='center'] During decompression, it is possible to call additional routines for pre-processing of compressed records and for post-processing of original records. E.g., pre-processing may decrypt encrypted records. Post-processing may perform a selection of specific records or fields. Instead of using the more complicated record level interface record-orientated processing can be done often with user exit EXD10. === User exits used by record interface ==== Compression with EXK20 image::pics/flam4_user_exit_comp_rec_interf.png[User exit compression,align='center'] The user exit for compressed records can also be used under the record level interface. The actual interception of original records by the interface is not affected. ==== Decompression with EXD20 image::pics/flam4_user_exit_deco_rec_interf.png[User exit decompression,align='center'] The user exit for compressed records can also be used under the record level interface. The actual interception of original records by the interface is not affected. === User exit examples ==== EXK10/EXD10-user exit The following exit routine can be used for compression as well as for decompression and has the purpose of modifying fields within records. The sample code is found in the library FLAM.SRCLIB. ==== EXK20/EXD20-user exit Since FLAM protects compressed files against manipulations by applying a checksum, it is possible to provide encryptions within the user exits with a very low overhead. Because the compressed data is already encrypted, simple deterministic character swapping within the compressed data cannot be detected easily by an unauthorized user. During decompression this character swapping - if not redone by an authorized user - will lead to a check sum error and the compressed file cannot be read. The symmetric construction of the user exits allows to use the same routine for encryption as well as for decryption provided that algorithms are used that will restore the original data when executed twice. This is the case with mutual character swapping. Similar results can be obtained with translate tables for cyclic (cycle length 2) character code exchange. ",
"",
""
],
[
"flam4_manual-biflam_e65f.html",
"BIFLAM",
"== BIFLAM This appendix describes the line compression and decompression (BIFLAM) solution delivered with FLAM4 for the IBM z/OS environment. === Bi-/serial compression with BIFLAMK Bi-/serial compression does not employ FL-Matrices. The compression effect is achieved by comparing the original data with a sample and/or by using serial compression techniques. BIFLAMK works synchronously. Each call results immediately in output data. It does not need a memory-compression is done on a call-by-call or record-by-record basis. Bi-/serial compression is especially suitable for integration into other products or applications. The compression effect is considerably lower than compression based on the FL-matrix. The advantage is the independence of each record. In many environments, this independence is a necessary requirement for integration. Beside compression, BIFLAMK offers two more functions that become more and more important as requirements for data security and data integrity are rising. All compressed records are encrypted and protected against modification using checksums over both original and compressed file. BIFLAMK offers several compression modes that can be selected via a function code. First, a vanilla serial compression mode is provided that does not require a sample record. All compressed records are independent from each other and can be decompressed individually. Second, a bi-serial mode is provided that can be adapted to different environments. This compression mode is based on a comparison of the record with a sample record byte by byte. The result is a bitmap that denotes all positions where characters are equal and the remaining differing characters. The first option allows to control the post-processing of the remainder. A serial compression can be applied to the remainder or the remainder is simply encrypted. The serial compression of the remainder can be bypassed if the CPU overhead is considered too high or the compression ratio is satisfactory. The second option controls the processing of the sample. If a dynamic sample is used, a checksum is computed for each sample record and is inserted into the compressed record. This slightly reduces the compression effect and increases CPU overhead. On the other hand, data security is improved because modifications are detected more easily. For an exact error analysis it is even possible to decide whether the compressed record or the sample has been modified. If a static sample is used, no checksum of the sample is computed. In this case, modifications in the sample can only be detected by using the checksum of the original file. The third option allows the storage of samples within the compressed file. During decompression, these records are restored again as samples. With this method, BIFLAMK can create sequences of records that can be decompressed by BIFLAMD without additional information (samples). One possibility would be to provide one sample first. Then all records are compressed against this sample and bi-serial compression is used to compress the remainders as well. Another possibility is to use dynamic samples by using the processor of each record as the sample for the current record. This sequence result in good compression ratios if adjoining records are similar (reports, data entry lists). The disadvantage is that the individual records are not independent from each other. This sequence must be decompressed as a whole. However, additional information (like samples) is not necessary. It does not make much sense, to use a different sample for each record. Sample records can only be compressed with simple serial compression. In addition the compressed data of the original data has to be stored as well. ==== Principle of operation BIFLAMK BIFLAMK is used for compression of data record by record. The compressed data is always returned in the same call. BIFLAMK is reentrant. For operation, a working storage area is needed that must be provided by the calling program. The content of the area before the call is ignored by BIFLAMK. All calls to BIFLAMK are totally independent from each other. All areas can have any alignment. The working storage area for the input record and for the compressed record must not overlap. In-place compression is not possible. [width='45%',cols='^2,^3',align='center'] |*Name*       |BIFLAMK |*Parameters* | |R1           |Address of parameter list |R13          |Points to save area (18 words) |R14          |Contains return address |R15          |Contains call address (entry point) [width='80%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 |  0    |Serial compression without sample |                 |  8    |Biserial compression with sample, serial post                            compression of the remainder and static sample |                 |  9    |Sample record for biserial compression with serial post                            compression |                 | 10    |Biserial compression with sample, serial post                            compression of the remainder and dynamic sample |                 | 11    |Sample record for biserial compression with serial post                            compression |                 | 12    |Biserial compression with sample, serial post                            compression and encryption of the remainder and                            static sample |                 | 13    |Sample record for biserial compression with                            encryption |                 | 14    |Biserial compression with sample, serial post                            compression and encryption of the remainder and                            dynamic sample |                 | 15    |Sample record for biserial compression with                            encryption |**2. RETCO**     |*F*    |Return code |                 |  0    |Function executed |                 |  2    |Invalid function code |                 |  3    |Length error +                            - working storage too small +                            - return area too small +                            - record bigger than 32767 bytes |**3. WORK**      |*XLn*  |Working storage area. The working storage area must                            be at least 512 bytes in size. For biserial compression                            the working storage area must be at least 512 bytes                            + length of return area. |**4. WRKLEN**    |*F*    |Length of working storage area in bytes |**5. BUFLEN**    |*F*    |Length of return area or maximum length of                            compressed record; this size must be at least 8 bytes                            + 1.1 * length of original record. |**6. RECIN**     |*XLn*  |Original record |**7. RECLEN**    |*F*    |Record length in bytes |**8. COMPREC**   |*XLn*  |Compressed record (length of this area = BUFLEN) |**9. COMPLEN**   |*F*    |Length of compressed record in bytes                            The next two parameters are only used for biserial                            compression: |**10. SAMPREC**  |*XLn*  |Sample |**11. SAMPLEN**  |*F*    |Sample length in bytes === Bi-/serial decompression BIFLAMD BIFLAMD decompresses compressed records created with BIFLAMK. For the serial decompression, no sample record (including length) is used. This implies that BIFLAMD has two fewer parameters. Therefore, it is necessary to inform BIFLAMD during the call which mode (serial or bi-serial) should be used for decompression. For a proper decompression, it is necessary that BIFLAMD receives exactly the same compressed records and sample records as created with BIFLAMK. Modification (code translations) must not be applied to the compressed data and the sample records. If compressed data shall be transmitted between different computers, the file transmission must be transparent. BIFLAMD automatically detects if a record was compressed serial or bi-serial and will report an error message if the compression syntax does not correspond to the call function code. Also modifications in compressed data, sample records and original data are detected via the checksums. ==== Principle of operation BIFLAMD BIFLAMD is used for record by record decompression of compressed data that was created with BIFLAMK. BIFLAMD is reentrant. For operation, a working storage area is needed that must be provided by the calling program. The content of the area before the call is ignored by BIFLAMD. All calls to BIFLAMD are totally independent from each other. All areas can have any alignment. The working storage area for the compressed record, for the sample record, and for the output record must not overlap. In-place decompression is not possible. [width='45%',cols='^2,^3',align='center'] |*Name*       |BIFLAMD |*Parameters* | |R1           |Address of parameter list |R13          |Points to save area (18 words) |R14          |Contains return address |R15          |Contains call address (entry point) [width='80%',cols='^3,^1,10',align='center',options='header'] |*Parameter list* |       | |**1. FUCO**      |*F*    |Function code |                 |  0    |Serial decompression without sample |                 |  8    |Biserial decompression with sample |**2. RETCO**     |*F*    |Return code |                 |  0    |Function executed |                 |  1    |Sample record for biserial decompression returned; no                            original record was written (only during biserial                            decompression) |                 |  2    |Invalid function code or record is compressed serially                            (function code = 8) or record is compressed biserially                            (function code = 0). |                 |  3    |Length error - working storage area too small -                            compressed record smaller than 3 bytes - return area                            too small. |                 |  4    |Checksum error in compressed record |                 |  5    |Checksum error in sample record (only for dynamic                            samples) |                 |  6    |Checksum error in original record |                 |  7    |Other errors in compressed record |                 |  8    |Sample record is shorter as during compression (only                            for biserial compression) |                 |  9    |Compressed record too short |**3. WORK**      |*XLn*  |Working storage area. The working storage area must                            be at least 512 bytes in size. For biserial compression,                            the working storage area must be at least 512 bytes                            + 1.125 * the sum of length of the return areas. |**4. WRKLEN**    |*F*    |Length of working storage area in bytes |**5. BUFLEN**    |*F*    |Length of return areas; maximum length of the                            original record or the sample record in bytes |**6. RECOUT**    |*XLn*  |Original record (length of area = BUFLEN) |**7. RECLEN**    |*F*    |Record length in bytes |**8. COMPREC**   |*XLn*  |Compressed record |**9. COMPLEN**   |*F*    |Length of compressed record in bytes                            The next two parameters are only needed for biserial                            decompression: |**10. SAMPREC**  |*XLn*  |Sample record (length of area = BUFLEN) |**11. SAMPLEN**  |*F*    |Length of sample record in bytes |**12. RETCO**    |*F*    |Return code === Compression data flow with BIFLAMK image::pics/flam4_biflam_comp.png[BIFLAM compression,height=771,width=774,align='center'] BIFLAMK processes original records and sample records on a record by record basis. When only serial compression is used (function code 0), BIFLAMK only processes original records and compiles them into compressed records. If bi-serial compression with sample (function codes 8,10,12,14) is used, an original record is processed in combination with a sample record to create a compressed record. For storage of the sample records (function codes 9,11,13,15), only the sample record is processed to create a compressed record. === Compression data flow with BIFLAMD image::pics/flam4_biflam_deco.png[BIFLAM decompression,height=771,width=774,align='center'] BIFLAMD processes compressed records record by record if necessary in combination with a sample record - and creates an original record or a sample record. During serial decompression (function code 0), the compressed record is only processed and will always create an original record. Sample records are not necessary. During bi-serial compression (function code 8), always one compressed record is processed at a time. Depending on compression, the sample record is read in addition and the original record is created. If a sample record was compressed during compression, this sample record is reconstructed during decompression. This situation is signalled with a return code of 1. ",
"",
""
],
[
"flam4_manual-lexemes_603d.html",
"Lexemes",
"[[CLEP.APPENDIX.LEXEMES]] == Lexemes The regular expressions used by the command line compiler are shown below. This content is printed on the screen with the built-in function `LEXEMES`. To describe the regular expression the following character classes are used: * :print:  - all printable characters * :space:  - all blanks, tabs and new lines * :cntr:   - all control characters * :alpha:  - all letters ([[a-z]|[A-Z]]) * :alnum:  - all letters and digits [0-9] * :digit:  - all decimal numbers [0-9] * :xdigit: - all hexadecimal numbers [[0-9]|[a-f||[A-F]] All comments and separators are ignored by the scanner and not passed with the token to the parser. This means that the separators (SEP) are used in the grammar but will never be part of or own tokens. If a binary entry for a string is possible and no classification is done it is taken as a binary string in local character set  representation (c) without null termination. This default can be changed. In this case the help message for this argument should be described the default interpretation of the binary string. For binary strings it is still possible to enter a null-terminated string, but then the prefix *s* must be used. If no binary entry is feasible, only a null-terminated string in local character representation (s) can be built and taken by default. ",
"",
""
],
[
"flam4_manual-grammar_ac2b.html",
"Grammar",
"[[CLEP.APPENDIX.GRAMMAR]] == Grammar Below you can see the grammar used by the command line compiler. This content is printed on the screen if the built-in function <<CLEP.BUILTIN.GRAMMAR,GRAMMAR>> is used. There are two context free grammars, one is used for the command line the other for the parameter file. The parameter file contains mainly the same argument list as the command line. The property file defines the default settings. For this a different grammar is applied. Properties can be set for each argument, i.e. for arguments not used or arguments in overlays. Based on that, properties are set by using the path (dotted keyword list). A property is always a 'SUPPLEMENT' for the argument list on the command line or parameter file. Thus all defined properties have the same effect as arguments on the command line. A property sets this argument to the corresponding value if it is not defined on the command line. ",
"",
""
],
[
"flam4_manual-properties_9f07.html",
"Properties",
"[[CLEP.APPENDIX.PROPERTIES]] == Properties All properties can be written to a global property file with the built-in function <<CLEP.BUILTIN.GENPROP,GENPROP>>: A property file for a certain command can be generated with: The first command shows the valid root path for the property file. A property file can contain properties for more than one root path. The property file parser will only interpret properties where the root matches, i.e. if the property file is assigned to a certain owner and possibly to a certain command, then only properties for this owner, the program itself and possibly the command will be accepted, all other properties are ignored. The second long comment gives some help for handling a property file. Thereafter the generated properties for this root are listed for all supported commands. The format is: The path denotes the unique dotted keyword list for one argument. The 'SUPPLEMENT' is a string normally in double quotation marks containing the value list for this argument in accordance with the syntax of the command line parser (strings then normally in single quotation marks, a opposite usage of the quotation marks is possible but not recommended). This means for example that a string that requires apostrophes must be included in apostrophes `(''...'')`. The supplement string is returned by the corresponding command line parser if no value for this argument is entered on the command line or is included in the parameter file. Behind the property definition the type and help message are printed as comment to help in editing the generated property file. The property values can be related to the current default settings at time of generation, what means that if hard coded default values or another property file is already in use, then these values are taken over into the new property file. The property file can contain parameter which are not available on the command line. Such parameter are only documented in the property file. On the other side not all command line parameter are available as property. If a description for a property argument is available which is not a part of the user manual this description is written as comment in front of the corresponding property definition. Below you can see the documentation of all parameter which are only available as property followed by all defined default properties in form of a sample property file for all available commands. ",
"",
""
],
[
"flam4_manual-properties-remaining_documentation_27c8.html",
"Remaining Documentation",
"=== Remaining Documentation Below you can find the documentation for all parameters which are only available over the property definitions. These parameters are not a part of the description for each command above. This list is generated and can be empty. In this case all parameters are available over the command line. If available, the manual page otherwise the help message is printed. The SYSTEM destination allows the log messages to be written to the logging system of the operating system. On Unix and z/OS(R) systems the syslog() call is used. On Windows(R) the event logging facility is used. This registry key will be created by using the DLL flevent.dll The SYSTEM destination allows the log messages to be written to the logging system of the operating system. On Unix and z/OS(R) systems the syslog() call is used. On Windows(R) the event logging facility is used. This registry key will be created by using the DLL flevent.dll ",
"",
""
],
[
"flam4_manual-properties-predefined_defaults_ec56.html",
"Predefined Defaults",
"=== Predefined Defaults Below you can find a sample property file which contains all predefined default values for all supported commands when this documentation was created. ",
"",
""
],
[
"flam4_manual-return_codes_157e.html",
"Return Codes",
"[[CLEP.APPENDIX.RETURNCODES]] == Return Codes The return codes of the program are also called completion codes and returned at program termination. This content is printed on the screen with the built-in function <<CLEP.BUILTIN.ERRORS,ERRORS>>. The command line is interpreted by CLE the command string by CLP. For example: A command execution (run) will return 0 or 1 on success, 4 if a warning occurs (only some of the files converted), 8 in case of an error or special condition codes greater then 64 can be returned. If the command execution was successful (return code 0) but a relevant warnings was logged then the return code is 1 (anything was fine, but please have a look in the log (e.g. a key is close to expire)). A return code of 2 indicates that a call to the finish function failed. Such a fail of the finish function is not recognizable if the run function (command execution) returns with a warning or an error. On the other side, if the finish failed then an additional warning in the log cannot determined because the condition code is still 2. All completion codes bigger than 8 and smaller or equal to 64 indicate an error in front of the command execution. A relevant warning is a warning written to the log by a used component. Warnings written by components which are removed from procession because the format does not fit or something else, are still in the log but not relevant for the completion code 1. ",
"",
""
],
[
"flam4_manual-return_codes-special_condition_codes_f737.html",
"Special Condition Codes",
"=== Special Condition Codes Special condition codes are issued for a dedicated job/batch control. For error conditions, which must be handled in a special way, the condition codes below are defined.          operation was done (FLMRTC_LIM).          as being a FLAM compressed file. The very beginning of the          file is corrupted to such an extent that the FLAM syntax          cannot be recognized or the file is empty (FLMRTC_CFF).          be detected as an ASCII-based charset if the first block of          data contains only ASCII characters (<128). In consequence,          character conversion will eventually run into an 'malformed          encoding' (ENOMSG) error on the first multi-byte character          which results in this condition code. In this case, it makes          sense to re-run the command with the correct ASCII CCSID, for          example Latin-1 (FLMRTC_TAS).          Please restart the job with a larger block size.          This could happen, for example, if PGP is used with BZIP2          compression and large (900 KiB) blocks. In this case, 1 MiB          would be a reasonable block size (FLMRTC_NBS). ",
"",
""
],
[
"flam4_manual-return_codes-reason_codes_2193.html",
"Reason Codes",
"[[CLEP.APPENDIX.REASONCODES]] === Reason Codes Below you can find the list of reason codes returned after command execution. Each command returns a reason code for the corresponding warning (return code 4) or error (return code 8). This content is printed on the screen with the built-in function <<CLEP.BUILTIN.ERRORS,ERRORS>>. * 1 - Fatal error (may not happen) * 2 - System error (wrong size of data types) * 3 - Handle error (not in right shape) * 4 - Interface error (parameter incorrect) * 5 - Activity not possible * 6 - Memory allocation failed (not enough memory) * 7 - Length error (need more data at read or more space at write) * 8 - Control code wrong * 9 - Version not supported * 10 - Function not supported * 11 - Mode not supported * 12 - Suite not supported * 13 - Confidentiality mode not supported * 14 - Integrity mode not supported * 15 - Verification mode not supported * 16 - Wrong header checksum * 17 - Wrong pot checksum * 18 - Wrong data checksum * 19 - Wrong checksum * 20 - Wrong message authentication code (MAC) * 21 - Wrong key test value * 22 - Syntax error (file not formatted correctly) * 23 - Count error (supplied or calculated amount wrong) * 24 - End of list (handle points behind last or first element) * 25 - Delete of file failed * 26 - Type error (supplied or calculated type wrong) * 27 - Rebuild required (flush not possible) * 28 - No change (informational) * 29 - Status error (handle not in right state) * 30 - Orientation not supported * 31 - Split method not supported * 32 - Maximum delimiter amount achieved * 33 - Error at compression * 34 - Error at decompression * 35 - Maximum header length achieved * 36 - Maximum data length achieved * 37 - Open of FLAMFILE failed * 38 - Record format not supported * 39 - Writing to file failed * 40 - Reading from file failed * 41 - Get position of file pointer failed * 42 - Set position of file pointer failed * 43 - End of file (informational) * 44 - Rename of FLAMFILE failed * 45 - Delete of FLAMFILE failed * 46 - Close of FLAMFILE failed * 47 - Seek in file does not work * 48 - Set of buffer size for FIO failed * 49 - FLAMFILE format not supported * 50 - No FLAMFILE * 51 - No entry found * 52 - Construct is empty * 53 - Connection error * 54 - Unsupported FLAM-ID * 55 - Remote procedure call failed * 56 - Method not supported * 57 - Open of file failed * 58 - Error from ZLIB (GZIP) * 59 - Character set not supported * 60 - Space too small * 61 - Logging facility not available * 62 - Error from character conversion module * 63 - Open of hash output file failed * 64 - Close of file failed * 65 - Error with FKME * 66 - Error at character conversion * 67 - Info not supported * 68 - Band not supported * 69 - Open of report file failed * 70 - Size error (supplied or calculated size wrong) * 71 - Invalid character encountered * 72 - Incomplete character encountered * 73 - Error with byte order mark (BOM) * 74 - Format wrong or not supported * 75 - Auto conversion not possible * 76 - Error from BZIP2 library * 77 - Environment variable are not or cannot be defined * 78 - Dynamic load of a function failed * 79 - Access control or license violation * 80 - Compression limit not reached * 81 - Error from LZMA/XZ library * 82 - Error from XML parser (EXPAT) * 83 - Whole first block is padding * 84 - Command line parser failed * 85 - Mapping failed * 86 - Open of temporary file failed * 87 - Wrong magic bytes * 88 - Corrupted or no FLAMFILE * 89 - Initialization error * 90 - Parameter not formatted correctly * 91 - Binary data detected * 92 - From and to are equal * 93 - Data is encrypted (key required) * 94 - Key value wrong * 95 - Reallocation required * 96 - Invalid username * 97 - Authentication failed * 98 - Hash calculation failed * 99 - Processing of one or more files failed * 100 - Hash/checksum file is empty * 101 - Read of hash/checksum file failed * 102 - Name of hash/checksum file is not valid * 103 - Hash/checksum file is not formatted correctly * 104 - Open of code table failed * 105 - Code table is not formatted correctly * 106 - Attribute settings not supported * 107 - Option wrong or not supported * 108 - Invalid parameter combination * 109 - Open of info file failed * 110 - Protocol wrong or not supported * 111 - Differences found * 112 - Try again with an ASCII code page (LATIN1) for read * 113 - Data incomplete * 114 - Procedure not supported * 115 - Key not found * 116 - OpenPGP error * 117 - Algorithm not supported * 118 - Key is inactive * 119 - Key is invalid * 120 - Key is expired * 121 - Positioning failed * 122 - Sequence error, incorrect order * 123 - Update not possible * 124 - Regular expression error * 125 - Value out of range * 126 - Usage measurement not possible * 127 - Dummy processing not possible * 128 - Open of inverse file failed * 129 - Internal error (may not happen) * 130 - Micro Focus support failed * 131 - Dynamic string library error * 132 - Open of usage log failed * 133 - Serialization failed * 134 - Deserialization failed * 135 - Program call (PC) failed * 136 - Row specification wrong * 137 - Record delimiter not supported * 138 - End of table (informational) * 139 - End of member (informational) * 140 - Have more data (informational) * 141 - Alignment error * 142 - Not enough space available (internal buffer too small) * 143 - Plausibility error * 144 - Unexpected remaining rest * 145 - Length parameter too small (the resulting space is not sufficient) * 146 - Virus found * 147 - Connection was closed * 148 - Error from anti virus scanner * 149 - Authorization failed * 150 - Command execution failed * 151 - Already exists * 152 - Tell offset in file does not work * 153 - Record too long * 154 - Record too short * 155 - Dynamic allocation of a file failed * 156 - Re-open of file failed * 157 - No such file or directory * 158 - Permission denied * 159 - No space left on device * 160 - Restart with larger block size required * 161 - Close/end encountered (special handling required) * 162 - Missing field definition * 163 - Element already deleted * 164 - Error from ZSTD library * 165 - Crypto error * 166 - Open of side/parameter file failed * 167 - Write of side/parameter file failed * 168 - Length mismatch * 169 - Compile of regular expression failed * 170 - Validation based on regular expression failed * 171 - Replacement based on regular expression failed * 172 - Ignore record ",
"",
""
],
[
"flam4_manual-version_a606.html",
"Version",
"[[CLEP.APPENDIX.VERSION]] == Version Here you can see the version of the program and its components. This content is printed on the screen if the built-in function <<CLEP.BUILTIN.VERSION,VERSION>> is used. ",
"",
""
],
[
"flam4_manual-about_3153.html",
"About",
"[[CLEP.APPENDIX.ABOUT]] == About This is the about information for the program (flam4). Its content is printed on the screen if the built-in function <<CLEP.BUILTIN.ABOUT,ABOUT>> is used. ",
"",
""
],
[
"flam4_manual-glossary_2ba6.html",
"Glossary",
"[glossary] == Glossary    compression algorithm of FLAM4.    the successor of DES and 3DES. It uses the Rijndael algorithm    with a fixed block size of 128 bits and a variable key length of 128,    192 or 256 bits, providing a high grade of security.    7-Bit encoding, which is the source for later character sets    based on more bits.    Specification for remote data transmission between customers and    credit institutions. The BCS is used, for example, in cash management    systems to enable multi-bank capability, i.e. the processing of data    from different credit institutions with software.    the most significant byte first, i.e. at the lowest byte address.    This behavior is most important when two computers with different    byte orders communicate with each other. The big-endian format is    used by Motorola 6800 and 68k, Xilinx Microblaze, IBM POWER,    System/360, System/370, ESA/390, z/Architecture and PDP-10.    are interpreted. This is important when exchanging data between    different systems. For UTF-16 and UTF-32 a BOM sign at the beginning    of the data stream is necessary, as more than one byte is used for    the encoding of one character. UTF-8 uses the BOM sign 'EF BB BF',    which is used to mark a text file as UTF-8, even though byte order    is not issue here.    from the byte order mark (BOM).    from the byte order mark (BOM).    entities that consist of multiple bytes, e.g. Unicode characters.    This is important when exchanging data between different systems.    A big-endian machine stores the most significant byte first, i.e. at    the lowest byte address. A little-endian machine, however, stores the    least significant byte first.    individual Unicode characters and sequences of Unicode    characters.    lowercase or some special representation (CASE=UPPER/LOWER).    Identifier'. The encoding of a specific code page is    referred to by a 16-bit number.    see also: https://en.wikipedia.org/wiki/CCSID[CCSID]    components which transform data stream in data stream (e.g. character    conversion, compression, de/encryption, de/encoding, ...).    This scheme was taken over by other vendors like Microsoft, SAP or    Oracle Corporation. The term Codepage is used synonymously for    character encoding or character set.    characters represented as numerical values that create the code    space. The Unicode code space has a total size of 17 * 65536 code    points. The same code space may have several codepages.    if their full compatibility decompositions are identical.    methods via the CONV command. These are various read and write    procedures, many useful conversion tools and some special data    formatting features.    diacritical sign. Typical diacritical marks are the acute (´) and    grave (`), which are often called accents. Diacritical marks may be    a dash, dot or tick above or below a letter, or in some other    position such as within the letter or between two letters.    developed by IBM as 8-Bit-encoding, which, however, does not use all    code words. EBCDIC originates from the older 4-Bit-Code BCD (Binary    Coded Decimals) and is applied solely on Mainframes. The EBCDIC    codepages are available in German, US, Swedish, Arabian, Latin-1 and    other languages. Moreover, there exists a Unicode set of characters    based on EBCDIC and it is called UTF-EBCDIC.    sequence of bytes used to identify a longer public key. Fingerprints    are created by applying a cryptographic hash function to a public    key. Since fingerprints are shorter than the keys they refer to, they    can be used to simplify certain key management tasks. +    see also: https://en.wikipedia.org/wiki/Public_key_fingerprint/[Public key fingerprint]    The C programming language has a general mechanism for reading and    writing files abstracting all Input/Output to streams of bytes.    The operating system offers redirection which can be very useful.    Examples are the standard input stream, standard output stream    and standard error stream.    Service provider interface to connect FLAM till version 4 with    different kinds of cryptographic infrastructure, hardware security    modules and/or key management systems.    encrypted and compressed data. In particular, FLAM is a utility for    converting, compressing, encrypting (with AES (Advanced Encryption    Standard)), signing and formatting of mass data with simple    interfaces for integration in all kinds of solutions. All this is    done with a minimum of CPU utilization, utilization of co-processors    and the use of professional key management solutions. Ordinarily,    FLAM provides - when used as sub-program - the commands COMP and DECO    and makes use of an element interface for the    subsystems/plugins/drivers and also the sub-program.    name of a Flamfile or that of a member.    be compressed. It is structured clearly and divided hierarchically    in records, segments and members. In this connection a segment is    referred to the single matrix of a compressed file and a member to    the entity of segments that are part of the compressed file. In    order to ensure the universal exchangeability, the FLAMFILE has to    be available in a format that is representable on all operating    systems (so-called heterogeneous compatibility). Each compressed    data segment is unique referring to data content, environment and    time. This allows - despite compression/encryption - an access down    to the record-level, without decompressing/decrypting.    the graphical user interface for running FLAM, FLUC and FLIES, quasi    a dialogue utility    the three sub-programs FLAM, FLUC and FLIES. It is a quasi-batch    utility for the sub-programs. Moreover, FLCL is a universal data    format and character set converter, which can be included easily    in professional internationalization projects. It supports    different input and output formats (GZIP, PDF, B64...) and    can be integrated into scripts or as sub-program. More than    150 codepages are supported. FLCL can be applied to various    commonly used platforms if working with processable data streams or    file I/O.    FLIES governs the compressed and encrypted segments using commands    like FIND and CHNGE. In particular, it is useful for processing    Flamfiles, which however cannot be decrypted or decompressed. For    instance the data in the file header is managed by FLIES to    re-encrypt the file, change the data access, use as backup,    archive or as mediator/headend.    converter with special focus on the high requirements in    professional internationalization projects, where Mainframes and    external applications are used as central backend.     conversion.    All components to parse a data stream in FLAM5 element list or build    a data stream from FLAM5 elements list.    used as source encoding for character conversion.    uses the DEFLATE algorithm from the ZLIB library. GZIP is the short    form for GNU zip. The used algorithm is a combination of LZ77 and    Huffmann encoding. The source code is licensed under the GPL. The    program has 9 compression steps providing either optimal CPU time    or compression ratios. The compressed file has the ending '.gz'.    As GZIP compresses only single files. Several files must first be    combined with (for example) 'tar' to a tarball which can then be    compressed to a '.tar.gz' file. GZIP files have a 10-byte header,    containing a magic number, a version number and a timestamp. With    FLCL you are able to read and write GZIP files, to mark content as    text data in the header, set operating/file system or modified time    (seconds since 1970).    commands on the command line.    different encodings on UNIX-like systems. As iconv is now part of    the GNU C Library, actual Linux systems are equipped with iconv.    Under Windows(R), iconv is provided only as DLL or static library,    which is under the license of the GPL and can be used via Cygwin or    GnuWin32. Iconv is also supported as Dynamic Link Library for PHP.    (e.g. Latin-1 to Latin-15). The frequently used Latin-1 character    set is identical with the first 256 characters of the Unicode    character set. These codepages are also called extended Ascii.    The endianness of a 16, 32 or 64 bits word or even bits can occur    in some Unicode representations. Also mixed forms of endianness are    possible, for example when the byte order within a 16 bits word    differs from that of a 16 bits word within a 32 bits word.    The little-endian format is used by x86 (including x86-64), 6502    (including 65802, 65C816), Z80 (including Z180, eZ80 etc.), MCS-48,    8051, DEC Alpha, Altera Nios II, Atmel AVR, SuperH, VAX, and PDP-11.    important information, input data) can be logged. The messages    can be redirected from stderr to stdout or a file.    capacity is far beyond that of a common Personal Computer and    that of most servers. They are applied for the highly reliable    processing of mass data, mass transactions and company critical    data and gain importance again in connection with server    consolidation and cloud computing.    copying data in FLAM4.    Canonical Composition).    by Canonical Composition).    forms is called normalization. Normalization is necessary, because    there is more than one differing possibility for many characters to    be represented as a sequence of Unicode characters. The four normal    forms consist of one form for the canonical equivalence, one for the    compatible equivalence, and both can be in a 'composed' or    'decomposed' form.    storage positions. Padding bytes are most commonly appended after the    the last data byte. When reading padded data, the padding bytes are    discarded.    zero or more members,    PDSE data sets can be stored only on DASD, not on tape. Interesting    thing is the directory can expand automatically  as needed.    Additionally it has an index which helps to locate the members inside    the PDSE faster. SPACE from deleted members are automatically reused    in PDSE .    work independently from the used operating system. Operating systems    can be for example LINUX, UNIX-like systems, WINDOWS(R) or z/OS(R).    the way retail payments are made and processed in Euro. The    motivation behind it is to make payments in Euro and across the EU    as fast, safe and efficient as national payments are now. SEPA    shall enable customers to make cashless Euro payments to anyone in    the EU, for instance by credit transfer, direct debit or debit card. +    see also: https://en.wikipedia.org/wiki/Single_Euro_Payments_Area/[SEPA]    see also: https://en.wikipedia.org/wiki/Secure_Shell/[SSH]    the new identity card issued in Germany (nPa) requires that each    printed character - even the diacritical characters - is 'composed'.    It means that they remain in their original form and are not    'decomposed' into several bytes. For that reason, the Sub Charset    'Latin in Unicodes' with some more than 500 letters is used.    encoding by system specific characters (e.g. 0x1A for ASCII or 0x3F    for EBCDIC pages) or by arbitrary characters. In the first case, you    must use SUBCHR=SYSTEM, in the other you can define your own    substitution characters. On z/OS(R), the utility iconv is available    on the system and replaces all invalid characters by system specific    characters, including the BOM sign. Note that it does not stop in    contrast to LINUX or WINDOWS(R) but completes conversion.    it will be converted to a converter-defined substitute character.    each. Some code points have no character value, some are reserved for    private use, and some are permanently reserved as non-characters.    UTF-16 with code points beyond these planes is encoded in 16 bit    surrogate pairs (High surrogate and low surrogate), which are in fact    replacement characters. UTF-16 surrogate values are illegal in    UTF-32. Note that the conversion of UTF-16 strings into UTF-8 byte    sequences requires that the High and Low surrogate have to be    combined correctly before they are transfered into UTF-8.    the transliteration of characters. This is comparable to    'translit.h' of iconv under LINUX.    tarball, a file that has the TAR file extension is a file in the    Consolidated Unix Archive format. A program or command that can open    archives is needed to open a TAR file.    Because the TAR file format is used to store multiple files in one    single file, it's a popular method for both archiving purposes and    for sending multiple files over the internet, like for software    downloads.    The TAR file format is common in Linux and Unix systems, but only for    storing data, not compressing it. TAR files are often compressed    after being created, but those become TGZ files, using the TGZ,    TAR.GZ, or GZ extension.    System. +    see also: https://www.ecb.europa.eu/paym/target/target2/html/index.en.html/[TARGET]    another. The TO-Code specifies the output encoding that characters    are converted to.    to represent it in another writing system rather in that, in which    the language is usually written respectively in which it is    available in written form. For the term of transcription it does not    matter, in which medium the expression is available. Note that the    transliteration of an expression is a particular type of    transcription.    original language into any target language; the process will be also    denoted as 'Translating'.    writing system S2 means, that the characters contained in the    expression are exchanged from S1 to S2 according to a fixed rule. In    the simplest case, this can be a table which assigns each character    of S1 a character of S2. Frequently, there are complications for the    simple case, if for example a single character is assigned to a    digraph or vice versa or if a character is mapped in context A onto    a specific character, in context B however onto another character.    For example: in a payment order from Germany, the name of the    receiver must be written explicitly in Latin letters so that a    transliteration of the original text with help of a table is    required.    standardize a single character set that eliminates the need for    different and incompatible encodings in different countries and    cultures. The text should be always readable with a    Unicode-supporting appropriate editor. This allows an error    free data exchange (for the purpose of readability) also on a global    and international level. For this character set, 8 bits (1 byte) are    no longer sufficient to for a representation of every possible    character. The length of characters encoded in Unicode can be between    1 and 4 bytes. ISO 10646 is a practically equal notation of the    Unicode character set called Universal Character Set (UCS).    see also: https://en.wikipedia.org/wiki/URL/[URL]    substitution table to transliterate those characters that are not    handled respectively replaced by the system table.    encoding for Unicode characters. The term Unicode is used equivalent    to UCS. UTF-8 has a central meaning in the global character    conversion for internet protocols.    assigned to each Unicode character. UTF-16 is used in Java for    internal character sequence representation. UTF-16 is the eldest    format of the Unicodes.    Unicode representation, as other formats need variable byte lengths    for their representation. One disadvantage of UTF-32 is the greater    space requirement compared to UTF-8 and ISO-8859 character sets and    the missing backward compatibility to ASCII.#    see also: https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zconcepts/zconcepts_169.htm/[VSAM] ",
"",
""
],
[
"flam4_manual-imprint_4ecb.html",
"Imprint",
"[colophon] == Imprint ",
"",
""
],
]);
