FairCom RTG COBOL Edition User's Guide

xddgen Configuration File

The -std=<dialect> parameter for xddgen determines which configuration file controls the conversion. The conf directory contains one configuration file for each value of <dialect> (e.g., for ACUCOBOL, specify ‑std=acu when running xddgen acu.conf is used). The file default.conf is used if ‑std= is not specified.

You can make customized copies of these files and give them new names. Use those names when running xddgen. For example, you could make a copy of acu.conf and call it myacu.conf. Use xddgen -std=myacu to use this file.

Configuration Options

comp-1-16bit-signed-binary - When set to yes, COMP-1 and COMP-2 are mapped as per the ACUCOBOL definition.
When using xddgen to create an XDD file for an FD containing a COMP‑1 field, the correct mapping depends on the COBOL compiler being used. It should be mapped into a Float for most compilers. However, the ACUCOBOL compiler defines COMP‑1 as a 16-bit signed integer, so it should be mapped to BinarySigned. To achieve this, use the following configuration property:

comp-1-16bit-signed-binary: yes

sign-trailing-separate - The ACUCOBOL -Ds compiler switch causes numbers to have separate leading sign by default (when no COMP specification is in place). This option defaults to no (0). Setting it to yes invokes TRAILING SEPARATE. The configuration file named acu‑Ds.conf enables this flag (use ‑std=acu-Ds).
binary-size - Defines the allocated bytes according to PIC:

Value: signed unsigned bytes
------ -------- -----
'2-4-8' 1 - 4 2
5 - 9 4
10 - 18 8
'1-2-4-8' 1 - 2 1
3 - 4 2
5 - 9 4
10 - 18 8
'1--8' 1 - 2 1 - 2 1
3 - 4 3 - 4 2
5 - 6 5 - 7 3
7 - 9 8 - 9 4
10 - 11 10 - 12 5
12 - 14 13 - 14 6
15 - 16 15 - 16 7
17 - 18 17 - 18 8

binary-byteorder - Determines the byte-order. Can be set to native (to use the byte-order of the original) or big-endian (to force big-endian byte order).
suppress-dash-in-field-names - When set to yes, dashes are eliminated from the file name rather than being substituted. The default, no, causes dashes to be substituted with underscores. See Suppress dash or replace with underscore.

Handling Names Larger Than 31 Characters

The xddgen utility is able to generate the XDD if a field name is larger than 31 characters to allow more flexibility in generating the XDD. Two configuration entries accommodate this situation:

user-defined-names-len (defaults to 31) - Can be any number between 31 and 64. It determines the number of significant chars in fields and table names.
check-redefinition (defaults to yes) - If yes, check for field names redefinitions that would cause having multiple SQL fields with the same name and if so, error out.

The behavior when names larger than user-defined-names-len is encountered has been changed so that, instead of generating an error, it produces a warning and truncates the name to the maximum allowed length.

More xddgen enhancements

Several enhancements have been made to the latest version of xddgen:

Generate an XDD for EXTERNAL files

Support was added xddgen to generate an XDD for files defined as EXTERNAL. By default, xddgen does not generate XDD files for external files, but it is now possible to change the xddgen configuration file follows to instruct xddgen to generate XDD files for EXTERNAL files:

# If yes, generates xdd file also for "external files"

# Value: 'yes', 'no'

consider-external-file: yes

Now when an external file is ignored, xddgen generates a warning message to inform about it.

Key based on a redefine

The xddgen utility used to return an error if a key was based on a redefine of a field or, in case of split keys, if one of the specified fields was a redefine. Now the logic has been changed to allow these conditions and produce a warning indicating the situation.

It is possible to change the behavior from the default of generating a warning to the old behavior of getting an error (or even to allow it without any warning) by changing the xddgen configuration entry:

# behaviour when a key is based on a redefine of a field.

# Value: 'ok', 'error', 'warning'

key-on-redefines: warning

Rationalized xddgen behavior on error

If an error occurs while generating an XDD, the XDD will not be generated (although other XDDs may be generated). The xddgen utility will always return a value different than 0 on the occurrence of an error. This implies it is sufficient to check the return code to see if something failed during xddgen execution.