Can Java interface with variable occurrence group?

We are currently in the process of upgrading to EXX801 on z/OS19. We desire to use the following style of IDL:

Library ‘IDLMNT’ Is
Program ‘DAVLNFN1’ Is
Define Data Parameter
1 #GROUP (/1:V)
2 #NBR (N8)
2 #CHAR (A8)

I have not found examples in the EXX8 documentation that supports this type of IDL though I have had success with Windows and z/OS batch RPC clients interfacing with a subprogram that contains the PDA that created this IDL.

When attempting a Java interface to the same subprogram with stubs created in the EXX721 workbench, we receive a “NAT1257 Access to a non-materialized X-array field not permitted” message.

We will be upgrading to the EXX8 workbench next week but am still concerned that not finding an example of this style of interface in the EXX8 examples may mean that Java cannot interface with a subprogram that has PDA that contains a group that has variable number occurrences.

Note, we are successful testing from the Java client when the subprogram PDA contains a group with a fixed number of occurrences.

Thanks for your help,
Dave Love
California Board of Equalization

Check out the documentation “mapping fixed and unbounded arrays” at

Since you are defaulting to an IN OUT, you need to instantiate a Java array object (new #group) before the call.

Hi Doug, things are getting worse with the one. We have made two changes. The EXX801 workbench is installed and we’ve simplified the subprogram interface. We now get an IDL generation error.

The subprogram:

  • Translate to upper case all occurrences of #STRING-IN

1 #GROUP(1:V)
2 #STRING-IN (A8 )
1 #I(I2)

The IDL generation error:
The idl gen failed:

/* Generated by Software AG, IDL Extractor for Natural ( on 2009-06-19 at 06:56:10
/* Natural 04.02.03 Patch 3, SYSIDL 6.1.1 Patch 8
/* Library Object Type Saved on Cataloged on
/* ----------------------------------------------------------------
/* IDLMNT DAVLNFN2 Object 2009-06-18 12:58:37 2009-06-18 12:58:37
library ‘IDLMNT’ is
program ‘DAVLNFN2’ is
define data parameter
1 #GROUP (Error) /* 1020 0019 Unsupported V-Array: (/1:V)
2 #STRING-IN (A8 )

Message 1020/0019 is not listed in the EXX801 error messages.

Note, Natural RPC client interface works. The goal is a Java client.

TIA for your help,

since (1:V) should be valid syntax (afaik!), please open a support request with Software AG.

V arrays in Natural are second class citizens for RPC, so the suggestion is to use X arrays.

The documentation at “” indicates that (1:V) (which is normal syntax for subprograms to receive arrays whose bounds are not known at compile time) is valid and supported. Dave’s example shows that (1:V) is not accepted, in contradiction to the documentation.

In any case Dave, try using (1:*) instead of (1:V) in the DEFINE DATA PARAMETER clause to see if it solves your issue.

Mapping Fixed and Unbounded Arrays
Fixed arrays within the IDL file are mapped to fixed Natural arrays. The lower bound is set to 1 and the upper bound is set to the upper bound given in the IDL file.

See the array-definition for the syntax on how to describe fixed arrays within the IDL file and refer to fixed-bound-array-index.

Unbounded arrays within the IDL file are mapped to Natural X-arrays. The lower bound is always fixed and set to 1.

See the array-definition for the syntax of unbounded arrays within the IDL file and refer to unbounded-array-index.

Natural variable arrays (Natural notation (…/1:V)) can be used on the Natural RPC server side instead of Natural fixed arrays or X-arrays. An RPC client can pass either an IDL fixed array or IDL unbounded array to a Natural RPC server with such a Natural variable array. In the RPC server, the variable array cannot be resized; this means the number of array occurrences cannot be changed, and the Natural RPC server will always pass back the same number of occurrences.

Doug, the suggestion to change #GROUP(1:V) to #GROUP(1:) worked. The IDL generator created the IDL and the Java client was able to set the number of #GROUP occurrences. So, we are ok for now using the (1:) syntax. I will also follow-up and submit a log about (1:V) causing the IDL generation to fail though the documentation states that (1:V) is valid.

Thanks for your help!
Dave Love