The FLOAT option controls the use of the additional floating-point
registers and whether Decimal Floating Point is supported.

.-+---+-------------------------------------.
| '-,-' |
V .-AFP-. |
>>-FLOAT--(----+-+-+-----+--+----------------------+-+-+-+--)--><
| | | .-NOVOLATILE-. | | |
| | '-(--+-VOLATILE---+--)-' | |
| '-NOAFP-----------------------------' |
| .-NODFP-. |
'-+-DFP---+-----------------------------'
- NOAFP
- Compiler-generated code uses the traditional 4 floating-point
registers.
- AFP
- Compiler-generated code may use all 16 floating-point registers.
- VOLATILE
- The compiler will not expect that the registers FPR8-FPR15 will
be preserved by any called program. Consequently, the compiler will
generate extra code to protect these registers.
Extra code will
be generated even if no floating-point registers are used, and this
will hurt performance. If your application makes little or no use
of floating-point, it would be much better to compile with FLOAT(NOAFP)
than with FLOAT(AFP(VOLATILE)).
- NOVOLATILE
- The compiler will expect that the registers FPR8-FPR15 will
be preserved by any called program (as z/OS says they should be).
This option will produce the most optimal code and is highly recommended
if you have no CICS code. However, it must be used with care in any
code included in a CICS application. For a CICS application,
- either: all code containing EXEC CICS statements must be compiled
with FLOAT(AFP(VOLATILE))
- or: all code using floating-point must be compiled with FLOAT(NOAFP)
or with FLOAT(AFP(VOLATILE))
It is safe and probably simplest not to use the FLOAT(AFP(NOVOLATILE))
option in any code that runs as part of a CICS application.
However, if you are using CICS TS V4.1
or later and are using either z/OS 1.11 or have the PTF for APAR PK71900
applied to z/OS 1.9 or 1.10, then these restrictions no longer apply
to CICS programs.
- DFP
- The DFP facility is exploited: all DECIMAL FLOAT data
will be held in the DFP format described in the z/OS Principles of
Operations manual and operations using DECIMAL FLOAT will be carried
using the DFP hardware instructions described therein.
The ARCH
option must be 7 (or greater) or this option will be rejected.
- NODFP
- The DFP facility is not exploited.
Under FLOAT(DFP),
- the maximum precision for extended DECIMAL FLOAT will be 34 (not
33 as it is for hex float)
- the maximum precision for short DECIMAL FLOAT will be 7 (not 6
as it is for hex float)
- the values for DECIMAL FLOAT for the following built-ins will
all have the appropriate changes
- EPSILON
- HUGE
- MAXEXP
- MINEXP
- PLACES
- RADIX
- TINY
- the following built-in functions will all return the appropriate
values for DECIMAL FLOAT (and values that will be much easier for
a human to understand; for example SUCC(1D0) will be 1.000_000_000_000_001,
and the ROUND function will round at a decimal place of course)
- EXPONENT
- PRED
- ROUND
- SCALE
- SUCC
- decimal floating-point literals, when converted to "right-units-view",
i.e. when the exponent has been adjusted, if needed, so that no non-zero
digits follow the decimal point (for example, as would be done when
viewing 3.1415E0 as 31415E-4), must have an exponent within the range
of the normal numbers for the precision given by the literal. These
bounds are given by the value of MINEXP-1 and MAXEXP-1. In particular,
the following must hold
- For short float, -95 <= exponent <= 90
- For long float, -383 <= exponent <= 369
- For extended float, -6143 <= exponent <= 6111
- when a DECIMAL FLOAT is converted to CHARACTER, the string will
hold 4 digits for the exponent (as opposed to the 2 digits used for
hexadecimal float)
- the IEEE and HEXADEC attributes will be accepted only if applied
to FLOAT BIN, and the DEFAULT(IEEE/HEXADEC) option will apply only
to FLOAT BIN.
- the mathematical built-in functions
(ACOS, COS, SQRT, etc) will accept DECIMAL FLOAT arguments and use
corresponding Language Environment functions to evaluate them. DECIMAL
FLOAT exponentiation will be handled in a similar way.
- users of DFP need to be wary of the conversions that will arise
in operations where one operand is FLOAT DECIMAL and the other is
binary (i.e. FIXED BINARY, FLOAT BINARY or BIT). In such operations,
the PL/I language rules dictate that the FLOAT DECIMAL operand be
converted to FLOAT BINARY, and that conversion will require a library
call. So, for example, for an assignment of the form A = A + B; where A is
FLOAT DECIMAL and B is FIXED BINARY, 3 conversions will be
done and 2 of those will be library calls:
- A will be converted via library call from FLOAT DECIMAL
to FLOAT BINARY
- B will be converted via inline code from FIXED BINARY
to FLOAT BINARY
- the sum A + B will be converted via library call from
FLOAT BINARY to FLOAT DECIMAL
The use of the DECIMAL built-in function would help here:
if the statement were changed to A = A + DEC(B);, the library
calls would be eliminated. The library calls could be eliminated by
previously assign B to a FLOAT DECIMAL temporary variable
and then adding that to A.
- the built-in function SQRTF will not be supported for DECIMAL
FLOAT arguments (as there is no hardware instruction to which it can
be mapped)
- DFP is not supported by the CAST type function.
|
This information center is powered by Eclipse technology. (http://www.eclipse.org)