Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

MODIFY-MODULE-PROPERTIES

&pagelevel(5)&pagelevel

Alias:         SET-MODULE-PROPERTIES

This statement is used to define the properties of the module to be generated.

MODIFY-MODULE-PROPERTIES

SHAREABLE-CODE= *UNCHANGED / *NO / [*YES] (...)


*YES(...)



|

PUBLIC-SLICING=*UNCHANGED / *YES / *NO

,LINKAGE= *UNCHANGED / *ILCS-OUT / *ILCS-INLINE

,WORKSPACE= *UNCHANGED / *TO-STATIC-AREA / *TO-STACK

,SUBROUTINE-CALL= *UNCHANGED / *BASR / *LAB

,ETPND-GENERATION= *UNCHANGED / *NO / [*YES] (...)


*YES(...)



|

DATE-FORMAT= *UNCHANGED / *CALENDAR-DATE-ONLY / *WITH-JULIAN-DATE

,LOWER-CASE-NAMES= *UNCHANGED / *YES / *NO

,SPECIAL-CHARACTERS= *UNCHANGED / *CONVERT-TO-DOLLAR / *KEEP

,STRING-LITERALS= *UNCHANGED / *WRITEABLE / *READ-ONLY

,CONSTANTS= *UNCHANGED / *WRITEABLE / *READ-ONLY

,C-NAMES= *UNCHANGED/ *STD / *UNLIMITED / *SHORT

,FP-ARITHMETICS= *UNCHANGED / *390-FORMAT / *IEEE-FORMAT

SHAREABLE-CODE =
This option controls whether or not the generated code is shareable.

SHAREABLE-CODE = *UNCHANGED
The settings of the last MODIFY-MODULE-PROPERTIES statement are used.

SHAREABLE-CODE = *NO
The compiler does not generate shareable code.
*NO is the default setting.

SHAREABLE-CODE = [*YES] (PUBLIC-SLICING = ...)
The compiler creates shareable code in the form of an LLM with a shareable code CSECT and a non-shareable data CSECT.

PUBLIC-SLICING =
PUBLIC SLICING defines whether or not the object generated immediately after the attribute PUBLIC is distributed in slices.

*UNCHANGED

The settings of the last MODIFY-MODULE-PROPERTIES statement are used.

*YES

The object will be distributed in slices immediately after the attribute PUBLIC.*YES is the default setting.

*NO

The object is placed in a slice.

POSIX objects are always generated with PUBLIC-SLICING = *NO.

With very large programs it is a good idea to set PUBLIC-SLICING=*NO. This will avoid the use of the long run times needed to read objects with slices.

LINKAGE = *UNCHANGED / *ILCS-OUT / *ILCS-INLINE
Function calls in the generated module are handled via ILCS by default. This option can be used to specify whether the ILCS entry code for function calls is to be directly inserted at the calling point ("inline”) or whether it is to be accessed “out-of-line” in the runtime system.

*UNCHANGED

The settings of the last MODIFY-MODULE-PROPERTIES statement are used.

*ILCS-OUT

The ILCS entry code for function calls is accessed “out-of-line” in the runtime system. This reduces the volume of code in the module.

*ILCS-INLINE

By default, the ILCS entry code is generated inline. This causes the generated object to execute faster.

WORKSPACE = *UNCHANGED / *TO-STATIC-AREA / *TO-STACK
This option affects some optimization steps of the compiler.

WORKSPACE =*UNCHANGED

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*TO-STATIC-AREA

The following optimizations are performed by the compiler:

  • An auxiliary storage area is created in the static data area and supplied with constant values.
  • In the case of innermost functions (i.e. those without further calls), data that is only valid within the function (auto variables) is not placed on the stack, but is stored together with the static data in the data module.

These optimization measures eliminate the need to maintain a separate stack for innermost functions and thus reduce the function entry code, and consequently the runtime of the generated object.

*TO-STACK

The above optimizations are suppressed.

All data (doublewords for conversions as well as auto variables and tempos of innermost functions) is mapped on the stack.
If a function includes conversions, some of the conversions may require a doubleword to be placed on the stack and supplied dynamically (requiring an additional instruction) before each such conversion.

SUBROUTINE-CALL = *UNCHANGED / *BASR / *LAB
This option controls the implementation of subroutine entries via Assembler instructions.

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*BASR

The BASR instruction is generated by default.

*LAB

The LAB entry generates the machine-independent Assembler instructions LAand B. Programs with this instruction sequence are executable on all 7500 systems.

Warning: This option is not permitted in the modes C++ V3 and C++ 2017.

ETPND-GENERATION =
This option serves to delete the #pragma directive used to generate an ETPND area (see "ETPND pragma (C/C++-Compiler, #94)") or to specify the date format of the ETPND area.

ETPND-GENERATION = *UNCHANGED
The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

ETPND-GENERATION = *NO
By default, no ETPND area is created.

ETPND-GENERATION = *YES(...)

DATE-FORMAT = *UNCHANGED / *CALENDAR-DATE-ONLY / *WITH-JULIAN-DATE

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*CALENDAR-DATE-ONLY

The date format in the ETPND area is assigned the form:8-byte calendar date - 4-byte load address.

*WITH-JULIAN-DATE

The following date format is generated in the ETPND area:6-byte calendar date - 3-byte Julian date - 4-byte load address.

LOWER-CASE-NAMES = *UNCHANGED / *NO / *YES
This option for converting lowercase letters to uppercase affects all external symbols in the C language modes and in the Cfront C++ mode, but only the symbols declared with extern "C" in the modes C++ V3 and C++ 2017. When external C++ symbols are coded in the modes C++ V3 and C++ 2017, lowercase letters are always retained.

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*NO

By default, lowercase letters are converted to uppercase when generating entry names.

*YES

Lowercase letters are retained when generating entry names.

SPECIAL-CHARACTERS = *UNCHANGED / *CONVERT-TO-DOLLAR / *KEEP

This option for converting the underscore affects all external symbols in the C language modes, but only the symbols declared with extern "C" directives (not the entry names of the C library functions) in the C++ language modes. When external C++ symbols are coded, underscores are always retained.

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*CONVERT-TO-DOLLAR

By default, underscores are converted to dollar signs when generating entry names.

*KEEP

Underscores are retained when generating entry names.

Notes on LOWER-CASE-NAMES and SPECIAL-CHARACTERS

  • The (default) conversion of lowercase to uppercase and of underscores to dollar signs is required whenever the generated LLM is to be linked with objects in which the entry names have been converted accordingly. These are:

    • Object modules.
    • LLMs generated with the C V2.0 compiler.

    • LLMs generated with the C/C++ compiler, in cases where the entry names were converted accordingly.

    • Objects created with other language translators (e.g. COBOL, ASSEMBLER).

  • The C library functions are only available in full when the options LOWER-CASE-NAMES and SPECIAL-CHARACTERS are present in one of the following combinations:
    • SPECIAL-CHARACTERS=*CONVERT-TO-DOLLAR and
      LOWER-CASE-NAMES=*NO

    • SPECIAL-CHARACTERS=*KEEP and LOWER-CASE-NAMES=*YES

STRING-LITERALS = *UNCHANGED / *WRITEABLE / *READ-ONLY
This option determines whether string literals (e.g. "abc") are placed in the data module (*WRITEABLE) or in the code module (*READ-ONLY).

CONSTANTS = *UNCHANGED / *WRITEABLE / *READ-ONLY
This option determines whether constants (i.e. objects declared with the const qualifier) are stored in the data module (*WRITEABLE) or the code module (*READ-ONLY).

C-NAMES = *UNCHANGED / *STD / *UNLIMITED / *SHORT
This option determines the length of external C names and affects all external symbols in the C language modes and only the symbols declared extern "C" in the C++ language modes (not the entry names of C library functions).
This option also works with static functions.

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*STD

By default, external C names can have a maximum length of 32 characters. Longer names are truncated by the compiler to 32 characters. When generating shareable code, only 30 characters may be used.

*UNLIMITED

No name truncation occurs. In this case, the compiler generates entry names in EEN format. EEN names can have a maximum length of 32000 characters. Modules containing EEN names are stored by the compiler in LLM Format 4. More details on the subsequent processing of LLMs in Format 4 can be found under the OUTPUT-FORMAT option of the BIND statement.
The *UNLIMITED value is not supported in the Cfront C++ mode.

*SHORT

External C names are truncated by the compiler to 8 characters, which corresponds to the handling of external names within object modules. This option is required if external names exceeding 8 characters in length are used in the program and if the module generated by the C/C++ compiler is to be linked with object modules that were created with the earlier C/C++ compilers or with compilers for other ILCS languages (e.g. COBOL85).

FP-ARITHMETICS = *UNCHANGED / *390-FORMAT / *IEEE-FORMAT
This option determines whether the C/C++ compiler generates floating-point numbers and operation codes in /390 format or IEEE format. This option effects all variables and constants of the float, double, and long double data types in C/C++ programs.

*UNCHANGED

The values specified in the last MODIFY-MODULE-PROPERTIES statement apply.

*390-FORMAT

The C/C++ compiler creates code for constants and operationsin the /390 format (/390 floating-point arithmetics).
*390-FORMAT is the default setting.

*IEEE-FORMAT

The C/C++ compiler creates code for constants and operations in IEEE format (IEEE floating-point arithmetics).

Important!

  • There are no precautions when binding objects which have been compiled with different floating-point arithmetics. This characteristic can lead to unexpected results when these programs are run.

  • The same C/C++ program can produce different results depending on whether the IEEE format or the /390 format is used for floating-point data types and operations. The reasons for this are as follows:

    • IEEE floating-point numbers use a different internal notation from /390 floating-point numbers.

    • An IEEE long double has the same size and representation as a double. The layout of structures with a long double therefore depends on this option.
    • IEEE floating-point operations use different semantics from /390 floating-point operations even on the same type of operation. This is the case for example in rounding. IEEE format uses "Round to Nearest" as default whereas /390 format uses "Round to Zero" as default.

Requirements:

  • If you are using IEEE floating-point arithmetics, you must not declare the C library functions explicitly in your source program. C library functions should be declared indirectly by including the corresponding CRTE headers (see the "C Library Functions" manual [2]). Otherwise compilation error ‘CFE1079[ERROR]..: Typangabe erwartet /expected a type specifier‘ can occur.

  • For each and every CRTE function that works with floating-point numbers in your program, you must use the corresponding or matching include file. If you do not do this, the CRTE functions will not be able to process the floating-point numbers correctly. You should ensure that you include the include file <stdio.h> for the function printf() with #include <stdio.h>.

    Important!

    C++ library functions do no support the IEEE format and must therefore be replaced with C functions where necessary.

  • In the CRTE runtime environment, some C library functions use the IEEE format for floating-point arithmetics. If you are using the IEEE floating-point arithmetics, you should specify the MODIFY-MODULE-PROPERTIES statement as follows:

    MODIFY-MODULE-PROPERTIES        -
       ...
       FP-ARITHMETICS=*IEEE-FORMAT, -
       LOWER-CASE-NAMES=*YES,       -
       SPECIAL-CHARACTERS=*KEEP,    -
       ...