Optimizer Options

#### Search Results

Search

# Optimizer Options

When the Natural Optimizer has been activated, you can specify checks by setting the options explained in this section.

The options cannot be used for specifying statements to be optimized.

This document covers the following topics:

- List of Options

- ARCH Option

- ARROPT Option

- PGEN Option

- UNICC Option

- Prerequisites for Code Generation with Unicode Operands

- Influence of other Natural Parameters

## List of Options

The following table lists and describes the Natural Optimizer Compiler options. Default values are underlined (this is the value that will be assumed if the option is not present).

A Natural Optimizer Compiler option consists of a string surrounded by brackets or single quotation marks (except in the Natural `OPTIONS` statement), with options separated by commas. Some options have values, while the very existence of some options in the option string is sufficient to modify the environment.

The following rules apply:

- Optional clauses are surrounded by square brackets [ ].

- Choices are surrounded by curly braces { }.

- Each choice is separated by vertical lines "|".

- Only one of these choices can be specified;

  `ON` is equivalent to `Y` (Yes),

  `OFF` to `N` (No).

- Options specified without the optional clause `ON` or `OFF` (if applicable), or their equivalent values, are interpreted as set to `ON`. For example, `OVFLW` is identical to `OVFLW=ON`.

- Except for the option `OFF`, any specified option switches on optimizing (as if `ON` was specified) and the default values apply. For example, `INDEX` is identical to `ON,INDEX`.

Option | Explanation
--- | ---
`ABEND` | Forces the Natural Optimizer Compiler to generate code which causes Natural to be abnormally terminated immediately when the `ABEND` option is encountered by the Natural Optimizer Compiler during compilation. The option must appear by itself or it will be ignored. Other parameters are not changed or reset by this option. This option can be useful for debugging purposes.
`ARCH` | Specifies the architecture level to be used for code generation. For more information, see ARCH Option in the following section.
`ARROPT` | Specifies the generation to be used for array assignments of the type A(*):=scalar. For more information, see ARROPT Option in the following section.
`CACHE[={ON| OFF |Y|N}]` | Switches variable caching on or off. See also Variable Caching in the section Performance Considerations.
`CPU= /370` | Specifies the target architecture.
`DIGTCHCK[={ON| OFF |Y|N}]` | Specifies whether the digits of packed and unpacked numeric fields (formats P and N) are to be checked when moving to another variable of the same type and precision. For example, if `DIGTCHCK` is `ON` and an unpacked numeric variable (format N) contains an invalid digit, such as `X'FA'`, moving to another unpacked numeric variable with the same precision will generate a `S0C7` (or `NAT0954`) error. If `DIGTCHCK` is `OFF`, no error is generated but the generated code is much faster.
`ERRDUMP[={ON| OFF |Y|N}]` | Specifies whether NOC should abend if an error condition is detected during the compile phase. This is useful for debugging the Natural Optimizer Compiler itself.
`INDEX[={ON| OFF |Y|N}]` | Specifies whether array indexes will be checked for out-of-bound values in the optimized code. See also the following Note.
`INDX[={ON| OFF |Y|N}]` | Specifies whether array indexes will be checked for out-of-bound values in the optimized code. Additionally, `RANGE` will be set on. Therefore, this option is equivalent to `INDEX=ON,RANGE=ON`. See also the following Note.
`IO[={ON| OFF|Y|N}]` | Provided for compatibility reasons only. No effect.
`LOOPS[={ON| OFF |Y|N}]` | Provided for compatibility reasons only. No effect.
`MIX[={ON| OFF |Y|N}]` | Provided for compatibility reasons only. No effect.
`NODBG``[={ON| OFF|Y|N}]` | If `NODBG=OFF/N` (default), the Natural Debugger can be used to debug optimized code (then, additional code is generated to check whether `TEST` mode has been set on). If `NODBG=ON/Y`, less code will be generated, the program will run faster and consume less CPU time. On the other hand, the functionality of the Natural Debugger will be limited, because the Natural Debugger might not receive control for optimized statements. See also `NODBG` in the section Performance Considerations.
`NOSGNTR[={ON| OFF |Y|N}]` | Applies to packed numbers only. If `NOSGNTR=OFF` (default), signs of positive packed numbers which are the result of an arithmetic operation or the target of an assignment are set according to the `COMPOPT` parameter `PSIGNF`. If `NOSGNTR=ON`, the signs resulting from execution of the generated machine instruction are left unchanged. See also the section Influence of other Natural Parameters.
`ON` | Switches on optimizing. If no additional option is specified, the default value defined for each option is in effect. As indicated in the following Note, this may cause unintended results, in particular regarding the options `INDEX, INDX, OVFLW`, and `RANGE`.
`OFF` | Switches off optimizing.
`OPTLEV={ 2|3}` | Specifies optimization level - roughly equivalent to the number of passes through the program. `OPTLEV=3` is useful when `PGEN` is specified, since some branch targets cannot be determined during the first pass and `PGEN` output is made during the last pass. Thus, some values may be shown improperly.
`OVFLW[={ON| OFF |Y|N}]` | Specifies whether checks for overflow in arithmetic operations or assignments will be included in the optimized code. See also the following Note.
`PGEN[={ON| OFF |Y|N}]` | Specifies whether a disassembly of the optimized code should be output. This option also enables all other tracing options: see PGEN Option in the following section.
`RANGE[={ON| OFF |Y|N}]` | Specifies whether range checks will be performed in operations with arrays. This ensures that array ranges will have an equal number of elements in corresponding dimensions of all operands. See also the following Note.
`SIGNCHCK[={ ON|OFF|Y|N}]` | Specifies whether the result of a multiplication with a packed or unpacked numeric multiplier should be checked for a negative zero. If zero is multiplied by a negative number, the MP machine instruction generates a negative zero result. If `SIGNCHCK` is on, this negative zero is converted to a positive zero. The check for a negative zero is done for every multiplication with a packed or unpacked numeric multiplier.
`TRENTRY` | For internal use by Software AG only. Do not change the setting of this parameter.
`UNICC` | Specifies whether the optimized code is generated for IF and DECIDE statements with Unicode operands. For more information, see UNICC Option in the following section.
`ZD``[={ ON|OFF|Y|N}]` | Specifies whether divisors should be checked for zero. If this option is specified, then code is inserted, so that the program behaves according to the `ZD` profile parameter of Natural, that is, Natural error `NAT1302` is issued or the result is zero. If this option is not specified, Natural error `NAT0954` occurs if the divisor is zero. See also ZD - Zero-Division Check in the Natural Parameter Reference documentation.

Note for INDEX, INDX, OVFLW and RANGE:

If the option `INDEX`, `INDX`, `OVFLW` or `RANGE` is set, extra instructions are added to the generated code to detect data overflow and index-out-of-range situations should they occur during program execution. Although the use of these options slightly increases the generated code, we recommend to use them to guarantee that erroneous programs are detected and cannot lead to unpredictable results, storage corruptions or abnormal program terminations.

Below is information on:

- Example of INDEX and OVFLW

- Optimum Code Generation

### Example of INDEX and OVFLW

    DEFINE DATA LOCAL
    ...
    1 P1 (P1/9)
    ...
    1 P3 (P3/9)
    ...
    1 I (I4)
    1 J (I4)
    1 K (I4)
    1 L (I4)
    END-DEFINE
    ...
    P1(I:J) := P3(K:L)
    ...
    END

#### Explanation of Example

With `INDX=ON` or `INDEX=ON` set, code is generated to verify that `I`, `J`, `K` and `L` are within the ranges defined for `P1` and `P3` respectively.

With `INDX=ON` or `RANGE=ON` set, code is generated to verify that `I:J` and `K:L` denote ranges of the same length.

With `OVFLW=ON` set, code is generated to verify that the value of `P3` fits into the corresponding `P1` variable.

For example: Value `100` would cause an overflow here.

Example Error Situation:

If one of the occurrences of `P3` contains the value `100`, with `OVFLW=OFF` set, the value assigned to the corresponding `P1` occurrence will be zero. If the index variable `I` is zero or greater than `9`, with `INDX=OFF` set, storage areas that do not belong to Array `P1` will be corrupted. If these options (`OVFLW` and `INDX`) are set to `ON`, a Natural error occurs like it does in standard Natural runtime.

For the NOC option specified above, additional code is generated. However, this is well compensated for by the advantage of a check that, for example, protects against hard-to-debug errors. Undetected errors can, of course, lead to unpredictable results.

### Optimum Code Generation

To assure that the least amount of code is generated and thus achieve optimum performance, use:

    OPT='NODBG,NOSGNTR,SIGNCHCK=OFF,ZD=OFF'

However, only apply this setting to objects that have been thoroughly debugged; see also Note for INDEX, INDX, OVFLW and RANGE.

## ARCH Option

The `ARCH` option specifies the hardware architecture level to be used for generating code for executable Natural objects.

When you specify an `ARCH` value, the Natural Optimizer Compiler generates newer and faster machine instructions that can improve the performance of the generated code. You cannot specify a value that is higher than the architecture level of your current machine. An executable Natural object cataloged with an `ARCH` level can only run on a machine with the same or a higher architecture level. Therefore, we recommend not to use the `ARCH` option if the cataloged objects are intended to execute on any machine, especially on a machine with a lower architecture level.

For detailed information on architecture levels, see the related literature from IBM (z/Architecture, Principles of Operation).

The following architecture levels are supported by the `ARCH` option of the Natural Optimizer Compiler:

Architecture Level | IBM Hardware Facility Required
--- | ---
`0` | Specifies that no architecture level is used. This is the default setting for compatibility with all mainframe platforms supported by Natural.
`1` to `4` | These values are not evaluated and treated as `ARCH=0`.
`5` to `6` | z800 or z900 Extended-Translation Facility 2 z890 or z990 HFP Multiply-and-Add/Subtract Facility
`7` | z9 to z109 Extended-Immediate Facility
`8` | z10 General-Instructions-Extension Facility Execute-Extensions Facility
`9` | zEnterprise 196 Load/Store-on Condition Facility Floating-Point-Extension-Facility Distinct-Operands Facility High-Word-Facility
`10` | zEnterprise EC12 (zEC12) Decimal Floating-Point Facility Decimal Floating-Point Zoned-Conversion Facility
`11` | zEnterprise z13 Decimal Floating-Point Packed-Conversion Facility
`12` | zEnterprise z14 Vector Packed-Decimal Facility

Note
With an `ARCH` value greater zero, the Natural Optimizer Compiler generates instructions up to the facility level described in the table above. An `ARCH` value higher than the architecture level of the underlying machine is rejected at compile time. The attempt to start a program compiled with an `ARCH` level on a machine with a lower architecture level, causes a NAT1394 runtime error. You can display information on the current machine by using the `TECH` system command.

This section covers the following topics:

- Support for Architecture Level 10

- Support for Architecture Level 11

- Support for Architecture Level 12

- Compatibility for Architecture Level 10 and 11

- Compatibility for Architecture Level 12

### Support for Architecture Level 10

When `ARCH=10` is set, the Natural Optimizer Compiler generates instructions provided by the Decimal-Floating-Point (DFP) Zoned-Conversion Facility for the numeric operations described in the following section. This can significantly improve the execution speed for statements that use these operations.

> Operations Optimized by ARCH=10

>   The following arithmetic operations on variables of the Natural data formats I (integer), N (numeric unpacked) and P (packed numeric) benefit from `ARCH=10`:

>   - Value assignments:

>     `P:=I`

>     `P:=N`

>     `N:=I`

>     `N:=N`

>     `N:=P` only if the number of packed digits is less than or equal to 15.

>     `I:=N`

>   - Arithmetic operations, such as `ADD`, `SUBTRACT`, `DIVIDE` and `MULTIPLY` statements, but only if both of the following conditions apply:

>     At least one of the operands used is in the format N or I.
>     The operation result does not exceed 34 (integer + precision) digits.

>   - Comparisons, such as `IF` and `DECIDE` statements, but only if both of the following conditions apply:

>     At least one of the operands used is in the format N.
>     Both operands are in different formats.

### Support for Architecture Level 11

When `ARCH=11` is set, the Natural Optimizer Compiler uses machine instructions introduced with the DFP Packed-Conversion Facility. In addition to the numeric operations optimized with `ARCH=10`, `ARCH=11` also optimizes operations that use packed variables only.

### Support for Architecture Level 12

When `ARCH=12` is set, the Natural Optimizer Compiler generates machine instructions newly introduced with the Vector-Packed-Decimal Facility (VPD) in the z14 hardware class. This can improve the execution speed for assignments, comparisons, and calculations if at least one packed operand is involved.

VPD machine instructions are generated for the same Natural operations described for Architecture Level 11, except they are applied only to arithmetic operations whose results do not exceed 31 (integer + precision) digits.

### Compatibility for Architecture Level 10 and 11

When `ARCH=10` is used, the Natural Optimizer Compiler generates machine instructions introduced with the Decimal-Floating-Point (DFP) Zoned-Conversion Facility, DFP Packed-Conversion Facility or the Vector Packed-Decimal Facility (VPD). These instructions execute faster than the standard machine code instructions for arithmetic operations, but they do not accept data which is improper in terms of the zoned numeric data type (N).

This may cause runtime errors, when an N-field is defined within a `REDEFINE` section of an alpha or binary variable and the N-field is not properly initialized before used in an arithmetic operation.

A numeric zoned field carries one digit in one byte. Usually, each byte contains x’F’ in the left halfbyte (Zone bits) and the digit value (0-9) in the right halfbyte (Numeric bits). This applies for all bytes, except for the last one, which contains (A-F) in the left halfbyte (Sign bits).

A sign halfbyte (C,A,F,E) represents a positive value, whereas (B,D) stands for a negative value. A value other than (0-9) inside the numeric halfbytes (N) and a value other than (A-F) inside the sign halfbyte (S) is considered invalid. The data inside the zone halfbytes (Z) is not regarded by arithmetic conversion instructions and can have any value (0-F).

Example for a variable defined as (N6):

ZN | ZN | ZN | ZN | ZN | SN | Sign is | Value is | Works with `ARCH<=9` | Works with `ARCH>=10`
--- | --- | --- | --- | --- | --- | --- | --- | --- | ---
F1 | F2 | F3 | F4 | F5 | F6 | F=positive | 123456, ok | yes | yes
F3 | F2 | F6 | F3 | F3 | D2 | D=negative | 323662, ok | yes | yes
40 | 40 | 40 | 40 | 40 | 40 | 4=invalid | 000000, ok | yes | NAT7024
00 | 00 | 00 | 00 | 00 | 00 | 0=invalid | 000000, ok | yes | NAT7024
12 | 13 | 14 | 15 | 16 | 17 | 1=invalid | 234567, ok | yes | NAT7024
51 | 6B | 72 | 7A | 12 | F1 | F=positive | 1B2A21, invalid | NAT0954 | NAT7024

When `ARCH=9` (or lower) is used, invalid sign halfbytes (0-9) are automatically corrected by the generated code to a positive sign (F). This turns N-fields with a blank contents into valid data with value zero. The same applies for Hexa zero data.

When `ARCH=10` (or higher) is used, invalid sign halfbytes (0-9) remain unchanged and lead to a program check (Data exception) when accessed by a DFP or VPD instruction. If such an abend occurs, Natural issues a NAT7024 error instead of a NAT0954 to clearly indicate that the error is caused by an N-variable that does not contain valid numeric data.

If a numeric halfbyte (N) contains a value other than (0-9), a program check (Data exception) happens regardless of the ARCH level used.

#### Conclusion:

Do not use `ARCH=10` (or higher) to catalog a program which operates unclean numeric data, with a sign value other than (A-F).

For example:

    OPTIONS MCG=(PGEN,ARCH=9)
    DEFINE DATA LOCAL
    1 #A (A6)
    1 REDEFINE #A
      2 #N (N6)
    END-DEFINE                                     /*  ARCH=9  ARCH=10
    #A := H'F1F2F3F4F5F6'   ADD 1 TO #N  WRITE #N  /*  ok       ok
    #A := H'F3F2F6F3F3D2'   ADD 1 TO #N  WRITE #N  /*  ok       ok
    #A := H'404040404040'   ADD 1 TO #N  WRITE #N  /*  ok       NAT7024
    #A := H'000000000000'   ADD 1 TO #N  WRITE #N  /*  ok       NAT7024
    #A := H'121314151617'   ADD 1 TO #N  WRITE #N  /*  ok       NAT7024
    #A := H'516B727A12F1'   ADD 1 TO #N  WRITE #N  /*  NAT0954  NAT7024
    END

Moreover, when `ARCH=10` (or higher) is used, Natural can issue a NAT1305 (truncated numeric value) instead of a NAT1301 error (intermediate result too large) for the following reason: The DFP or VPD numeric format is used for calculating intermediate results and an overflow is only detected at the end of the arithmetic operation when the DFP is converted into the format of the result.

### Compatibility for Architecture Level 12

When `ARCH=12` is used, the Natural Optimizer Compiler generates machine instructions introduced with the Vector Packed-Decimal Facility (VPD) which are compatible in terms of data incorrectness with the code generated with `ARCH=9` or below.

Numeric data fields (N) with incorrect sign representations (0-9) are converted into the positive sign value (F). This accepts numeric fields with a blank or hex00 content and treats them as value zero. A data exception (abend) does not occur in these cases.

## ARROPT Option

The `ARROPT` option determines the generation algorithm to be used for array assignments of the type `A(*):=scalar`.

Valid values for `ARROPT` are:

Value | Explanation
--- | ---
`ON` | Recommended setting for arrays with a minimum of 50 occurrences. `ON` is the default setting.
`OFF` | Recommended setting for arrays with less than 50 occurrences.

## PGEN Option

The `PGEN` option causes the Natural Optimizer Compiler to output the generated code and internal Natural structures. Thus, code and structures can be examined, for example, for bug fixing, performance review and support issues.

An understanding of IBM's /370 assembler is required to interpret the results produced by the `PGEN` option.

We recommend that you use this option with the assistance of your local Software AG representative.

Below is information on:

- Setting PGEN

- Sub-Options of the PGEN Option

- Output of the PGEN Option

- Working with the PGEN Output

### Setting PGEN

To use the `PGEN` facility, set the `PGEN` option when activating on the Optimizer Compiler.

Since the buffer is kept in memory, it is possible that the user thread will not be big enough to hold the trace information. In this case, try setting `PGEN` on only for the portion of the program which is to be traced, for example:

`OPTIONS MCG=(PGEN=ON,TRGPT=ON)` or `OPTIONS MCG=+PGEN,TRGPT` | Turns tracing on, including tracing of the GPT entries
`OPTIONS MCG=(PGEN=OFF)` or `OPTIONS MCG=-PGEN` | Turns tracing off

Various options affect the content of the output. The basic `PGEN` option causes a formatted listing of Natural source lines and a disassembly of the corresponding code to be generated and kept in memory for extraction by the `NOCSHOW` utility as described below, under Output of the PGEN Option.

The `TRSTMT`, `TRGPT`, `TRMPT` and `TRVDT` options cause hex dumps of internal data structures associated with each line to be output.

The `TRBASES` and `TRCACHE` options cause information on base registers and cache variables to be printed out.

### Sub-Options of the PGEN Option

The following table describes the options when `PGEN=ON`. For an explanation of the syntax used see the introduction to List of Options above.

Option | Explanation
--- | ---
`LPP={5|..| 55 |..|255}` | Lines-per-page for the trace output, only used when `TREXT=ON`.
`NOsrcE[={ON| OFF |Y|N}]` | If `NOsrcE=OFF`, the Natural source statement is included in the output.
`TRACELEV={ 0 |..|255}` | Specifies the trace level. Each bit in this one byte value specifies a buffer type to trace; these bits can be set on by using the `TRxxx` options as well.
`TRBASES[={ON| OFF |Y|N}]` | Specifies whether base register allocations are traced.
`TRCACHE[={ON| OFF|Y|N}]` | Specifies whether `CACHE` entries are traced.
`TREXT[={ON| OFF |Y|N}]` | If `TREXT=ON`, trace is directed to the user exit `NOCPRINT` as described below.
`TRGPT[={ON| OFF |Y|N}]` | Specifies whether `GPT` entries are traced.
`TRMPT[=ON| OFF |Y|N}]` | Specifies whether `MPT` entries are traced.
`TRSTMT[={ON| OFF |Y|N}]` | Specifies whether `STMT` entries are traced.
`TRVDT[={ON| OFF |Y|N}]` | Specifies whether `VDT` entries are traced.

See also the examples below.

### Output of the PGEN Option

There are two places to where the Natural Optimizer Compiler can direct the output of `PGEN`:

- Internal Buffer
- User Exit NOCPRINT

#### Internal Buffer

The contents of this buffer is overwritten each time a `CHECK`, `CAT`, `STOW` or `RUN` command is executed. A system utility `NOCSHOW` is provided whereby the contents of this buffer can be viewed, searched or printed.

To invoke the NOCSHOW utility

- Enter the direct command `NOCSHOW` after a `CHECK`, `STOW`, `CAT` or `RUN` where the Natural Optimizer Compiler has been active.

The following PF keys are available on the screen:

Key | Function
--- | ---
PF2 | Position to top of output
PF4 | Position one line backward
PF5 | Position one line forward
PF6 | Print to report (1)
PF7 | Position one page backward
PF8 | Position one page forward
PF9 | Print via Entire Connection to report (7)
PF10 | Scan for text string
PF11 | Repeat scan

#### User Exit NOCPRINT

If `TREXT=ON` is specified, the Natural Optimizer Compiler passes every output line to the user exit `NOCPRINT` instead of adding it to the trace buffer.

`NOCPRINT` is invoked following normal OS register conventions. Register 1 points to a full word containing the address of the 81 byte print line with ANSI carriage control characters in position 1. Register 13 points to an area of 18*4 bytes which may be used as a save area. Register 14 contains the return address and Register 15 contains the entry address of `NOCPRINT`.

The user exit `NOCPRINT` can be written in any language which supports the register conventions described above. It must be linked to the Natural nucleus together with the Natural Optimizer Compiler nucleus.

### Working with the PGEN Output

This section provides hints and explanations on how to interpret the output created with the `PGEN` option.

- At the top of the `PGEN` output are some disassembled lines which do not appear to belong to any source line. These are the instructions which make up the prologue, which is executed whenever control passes from non-optimized to optimized code. Permanent base registers are loaded and control is passed to the correct point in the prologue. See Example Section A below.

- Sometimes a lot of source lines are printed without any code. This indicates that there was no code required or that these statements are excluded from the NOC optimization. See Example Section B below.

  Moreover, when the code generated for a Natural statement consists only of:

      BAS   R14,RETH
      DC    X'....'

  this indicates a return back to the standard runtime, as this statement could not be NOC optimized (see line `0170`).

- If the `NODBG=OFF` (default) has been specified, a sequence of instructions is generated at the start of each Natural statement:

      BALR R9,R11
      DC X'....'

  This sequence sets the line number (in case of error) and checks whether the `TEST` mode is switched `ON`. Without this sequence, debugging of NOC-compiled statements by the Natural Debugger is not possible. See Example Section C below.

- Sometimes there is a line break between disassembled lines. This break indicates an internal statement separation. It happens because often a single Natural statement will generate multiple internal (pseudo-code) statements.

- The Natural variables operated are inserted in the Assembler code.

- The items on the right side (e.g. “START 8FEC”) are of internal nature. They document the path how the code was generated by the NOC modules.

- All kind of addresses inside the code are resolved and provided in the form “`=(00044)`”. It documents the offset in the code to which the branch is executed.

- The first and the last code instruction contains the NOC version used to compile this program. The meaning of “`4700 8410`” is NOC V841.

#### Example Section A:

     000000 4700 8410           NOP   1040(,R8)                         START  8FEC
     000004 5880 D354           L     R8,CONST                                 D9DC
     000008 5870 D370           L     R7,LOCAL                                 D9DC
     00000C 4810 6006           LH    R1,6(,R6)                                90A0
     000010 1F60                SLR   R6,R0                                    90BA
     000012 47F1 A000           B     0(R1,R10)                                90C0

     000016 4DE0 B040           BAS   R14,RETH                           RETN  F0AA
     00001A 0034                DC    X'0034'                                  F0C0

#### Example Section B:

     0010 0010 OPTIONS MCG=(PGEN,OVFLW,INDX)
      0020 DEFINE DATA LOCAL
      0030 1 I(I4)
      0040 1 P(P7.2)
      0050 1 T(P7.2)
      0060 END-DEFINE
      0070 *
      0080 SETTIME
      0090 *

#### Example Section C:

     0100 FOR I=1 TO 100000

     00001C 0D9B                BASR  R9,R11                             MOVE 1724A
     00001E 004A                DC    X'004A'                                 17278
     000020 D203 7000 8148      MVC   I(4),#KST0148                            97D2

     000026 47F0 A044           B     68(,R10)         =(00044)          GOTO  EF44

     00002A 0D9B                BASR  R9,R11                              ADD 1724A
     00002C 006A                DC    X'006A'                                 17278
     00002E BF0F 7000           ICM   R0,B'1111',I                             BB20
     000032 5A00 8148           A     R0,#KST0148                              1E4E
     000036 0D90                BASR  R9,0                                     F12A
     000038 4710 B15C           BO    NAT1301                                  1E9E
     00003C BE0F 7000           STCM  R0,B'1111',I                             A9CC

     000040 0D9B                BASR  R9,R11                               IF 1724A
     000042 007C                DC    X'007C'                                 17278
     000044 BF0F 7000           ICM   R0,B'1111',I                             BB20
     000048 5900 819B           C     R0,#KST019B                              3FDA
     00004C 47D0 A054           BNH   84(,R10)         =(00054)                EF44

     000050 47F0 A078           B     120(,R10)        =(00078)          GOTO  EF44

     0110   ADD 1.00 TO P

     000054 0D9B                BASR  R9,R11                              ADD 1724A
     000056 0092                DC    X'0092'                                 17278
     000058 FA41 7004 819F      AP    P(5),#KST019F(2)                         20A0
     00005E 0D90                BASR  R9,0                                     F12A
     000060 4710 B15C           BO    NAT1301                                 1071C
     000064 910D 7008           TM    P+4,X'0D'                               120B0
     000068 4710 A070           BO    112(,R10)        =(00070)               120F6
     00006C 960F 7008           OI    P+4,X'0F'                               1210ª

     0120 END-FOR
     0130 *

     000070 0D9B                BASR  R9,R11                             GOTO 1724A
     000072 00A4                DC    X'00A4'                                 17278
     000074 47F0 A02A           B     42(,R10)         =(0002A)                EF44

     0140 T:=*TIMD(0080)

     000078 0D9B                BASR  R9,R11                             SYFU 1724A
     00007A 00AE                DC    X'00AE'                                 17278
     00007C 4DE0 B0D8           BAS   R14,SYSFUNC                              5F1A
     000080 0190 B881           DC    X'0190B881'                              5F28

     000084 F246 7009 8190      PACK  T(5),#KST0190(7)                   MOVE  AD18
     00008A 910F 700D           TM    T+4,X'0F'                               12130
     00008E 4710 A0A0           BO    160(,R10)        =(000A0)               12176
     000092 17EE                XR    R14,R14                                 1218E
     000094 43E0 700D           IC    R14,T+4                                 12194
     000098 43EE B488           IC    R14,PSGNTR(R14)                         121AA
     00009C 42E0 700D           STC   R14,T+4                                 121B2
     0000A0 F040 7009 0002      SRP   T(5),2,0                                 ACA2
     0000A6 17EE                XR    R14,R14                                 1218E
     0000A8 43E0 700D           IC    R14,T+4                                 12194
     0000AC 43EE B488           IC    R14,PSGNTR(R14)                         121AA
     0000B0 42E0 700D           STC   R14,T+4                                 121B2

     0150 T:=T / 10
     0160 *

     0000B4 0D9B                BASR  R9,R11                              DIV 1724A
     0000B6 00C0                DC    X'00C0'                                 17278
     0000B8 F864 D100 7009      ZAP   OP1(7),T(5)                              AC60
     0000BE FD61 D100 81A1      DP    OP1(7),#KST01A1(2)                       327A
     0000C4 F844 7009 D100      ZAP   T(5),OP1(5)                              AC60
     0000CA 910D 700D           TM    T+4,X'0D'                               120B0
     0000CE 4710 A0D6           BO    214(,R10)        =(000D6)               120F6
     0000D2 960F 700D           OI    T+4,X'0F'                               1210A

     0170 DISPLAY 'ELAPSED TIME (S)' T

     0000D6 4DE0 B040           BAS   R14,RETH                           RETN  F0AA
     0000DA 00D2                DC    X'00D2'                                  F0C0

     0180 END

     0000DC 40D6 D7E3 F844 2000 DC    X'40D6D7E3F8442000'  =' OPT8à..'    END  927E
     0000E4 0000 0000           DC    X'00000000'                                nf
     0000E8 40D5 D6C3 F8F4 F140 DC    X'40D5D6C3F8F4F140'  =' NOC841 '         92E4

## UNICC Option

The `UNICC` option controls the generation of optimized code for `IF`, `DECIDE FOR` and `DECIDE ON` statements that contain Unicode operands.

Valid values for `UNICC` are:

Value | Explanation
--- | ---
`ON` | Generates optimized code and checks whether `COLLATE=OFF` is set (see the `CFICU` profile parameter in the Parameter Reference documentation). If `COLLATE=ON` is set, execution of the optimized code will fail with a NAT7023 Natural system error.
`FORCE` | Generates optimized code analogous to `ON` but without `COLLATE=OFF` check. The code optimized with `FORCE` performs better than the code optimized with `ON` but can cause wrong results if `COLLATE=ON` is set.
`OFF` | Optimized code is not generated. `OFF` is the default setting.

## Prerequisites for Code Generation with Unicode Operands

The Natural Optimizer Compiler generates optimized code for Natural statements with Unicode strings if the following requirements are met:

Statement | Requirement
--- | ---
All statements | All operands used in the statement must be of the type Unicode.
`EXAMINE` | The `ARCH` option must be set to a value greater than or equal to `6`.
`IF` `DECIDE FOR` `DECIDE ON` | All Unicode character strings must be normalized. The `ARCH` option must be set to a value greater than or equal to `5`. The `UNICC` option must be set to `ON` or `FORCE`. The `COLLATE` option of the `CFICU` profile parameter must be set to `OFF` (see the Parameter Reference documentation).
`MOVE` `MOVE SUBSTRING` `RESET` | The `ARCH` option must be set to a value greater than or equal to `5`.

## Influence of other Natural Parameters

The global parameter `ZD` influences the behavior of the NOC compiler. See the description of the `ZD` option as described under List of Options above.

The `COMPOPT` parameter `PSIGNF` (see also the system command `COMPOPT` in the Natural System Commands documentation) influences the behavior by forcing the signs of positive packed decimal numbers to F if `ON`, and to C if `OFF`. The parameter is applied if `NOSGNTR=OFF` is specified.

See the chart below for packed data (Format P) ":"

`NOSGNTR=OFF` | and | `PSIGNF=ON` | All signs are normalized to F (default).
`NOSGNTR=OFF` | and | `PSIGNF=OFF` | All signs are normalized to C.
`NOSGNTR=ON` |  | All signs are left as they were generated by the last operation.

For numeric data (Format N) the signs are always normalized to F, regardless of the settings of `NOSGNTR` and `PSIGNF`.

### On this page

- List of Options
- ARCH Option
- ARROPT Option
- PGEN Option
- UNICC Option
- Prerequisites for Code Generation with Unicode Operands
- Influence of other Natural Parameters