ILNATIVE

Exposes COBOL 01 level data items as managed primitives where possible.

Restriction: This directive is supported for managed COBOL only.

In general:

Any COBOL level-01 data item that is equivalent to a managed COBOL data type is handled internally as that native type, where possible (see COBOL Type Compatibility)
Other numeric items will either be handled as native managed types or will be stored within a byte array, according to the setting of the ILOPTIMIZEDATA directive, and according to their usage within the program.
If a parameter of a PROCEDURE DIVISION USING or ENTRY … USING statement corresponds to a .NET native type, the parameter is exposed as a data item of that type in the method signature for the entry point.
BY REFERENCE parameters that don't correspond to a managed COBOL data type are exposed as internal type-neutral objects representing the byte array/offset pair of the data item.

The compiler usually converts parameters in the calling program to the appropriate type, by examining the target method signature. This signature is available if the method is in the same source module as the calling program or in a module identified by the ILSOURCE directive or in an assembly identified by an ILREF directive.

Where the called program is not known at compile time or not available until run time, the calling program sets up parameter types based on only the data items in the CALL statement. At run time the types of the parameters might not match those in the target method and this causes the .NET CLR or JVM to raise an exception because it can't convert the data. You can avoid this by specifying the NOILNATIVE directive for both the calling and the called program.

Syntax:

>>-.----.---ILNATIVE----------><
   |    |        
   +-NO-+

Parameters:

None

Properties:

Default:	ILNATIVE
IDE equivalent:	None. You can specify ILNATIVE as an additional Compiler directive under Project > Properties > COBOL

Comments:

A COBOL data item that is represented as a managed primitive performs significantly better than one that isn't. However, there are some situations where using IL native types is not suitable, such as when the call arguments do not match in dynamic calls, or when your program relies on the DEFAULTBYTE Compiler directive initializing an item that will be exposed as an IL native type.

You can avoid these problems by specifying the NOILNATIVE directive when compiling your program.

Example:

The following programs demonstrate a case for compiling with NOILNATIVE:

cmain.cbl

      01 ws-data pic 9(4) comp-5.
       procedure division.
       call “csub” using ws-data.

csub.cbl

       linkage section.
       01 ls-data.
          03 ls-value pic 9(4) comp-5.

       procedure division using ls-data.
          move 100 to ls-value.
          exit program.

Compile the two programs independently, with the default setting of ILNATIVE, using commands such as:

cobol cmain jvmgen;
cobol csub jvmgen(sub);

When you run the program cmain, an exception is raised at run time due to the different types of the ws-data and ls-data data items.

However, if you specify NOILNATIVE directive for both programs, as follows, both data items will be represented with the same type and so the argument will be successfully passed to the subprogram.

cobol cmain jvmgen noilnative;
cobol csub jvmgen(sub) noilnative;