Hi,

I have a few questions on IDL generation and its mapping to Java.

The environment information

EntireX Communicator - 7.3.2
Natural - 6.2.3

1. Does the array with variable upper-bound supported as below (extracted from the EntireX documentation), which can be mapped to the Java?

Example of arrays with variable upper-bounds

…
1 NAMES (A100/V) /* 1 dimensional array /
1 TUPLES (A100/V,V) / 2 dimensional array /
1 TRIPLES (I1/1:V,1:V,1:V) / 3 dimensional array */

When I use the IDL editor on Eclipse and generate the RPC client, I found that the variable array has been initialized as an array with zero length, which is unexpected.

2. Does the arrays with variable upper-bounds and maximum supported as below, which can be mapped to Java?

Example of arrays with variable upper-bounds and maximum

…
1 NAMES (A100/V10) /* 1 dimensional array /
1 TUPLES (A100/V10,V10) / 2 dimensional array /
1 TRIPLES (I1/1:V20,1:V20,1:V20) / 3 dimensional array */

3. If variable array is supported, is there any limitation imposed such that there is implicit bound or limit on its size?

4. If variable array is not supported, what is the good practice to handle the variable list of result returned from Natural?

Thanks.

Roland

I think this should work.
At least there are customer using NAT62 using dynamic tables in natural and give or return a variable number of occurences.
You need to start an natural rpc server with the right NAT61 protocol. In unix this is a parameter of the make file.
for tables with 1 dimension I can guarantee it works because I have done it.
On the level of natural you there is an instruction to increase and decrease the number of occurences of a table;

Concerning the question of size, this depends on limits you need to fix on the level of the broker (there is a parameter for maximum length of message) and on the level of MAX_BUFF on the level of the RPC server.

Thanks for your response.

After reading your reply, I have a few follow-up questions.

1. In EntireX Communicator documentation of v.7.3.2 - Administration of EntireX RPC server - Setting Server Parameters for the RPC server, I cannot figure out the parameter <MAX_BUFF>. May you give me a pointer on this?

2. If <MAX_BUFF> is the fundamental constraint imposed on the size of the reply from EntireX broker, then

a. What is its default setting? and how large can parameter <MAX_BUFF> be set?

b. Will setting the compression level help to increase the maximum bounds of variable array?

c. What happen when the size of response is larger than <MAX_BUFF> can hold? It seems that using variable array in the request/response invocation does not give a reliable RPC handling. In such case, would we have a reliable method to handle these responses?

3. Go back to my question on my 1st post, are there any Best Practice on retrieving the list of structural data with variable-length? It would nice if there is a document describing the general practice on designing the interface particular for EntireX RPC server.

Thanks.

Roland

i’m not 100% sure but i think that the usage of conversational rpc would help you to get rid of the question if the sizes are big enough.

Regards
Sascha

Hi Sascha,

Thanks for your reply. But I still have doubt on how using conversational RPC communication can help resolving the issue of buffer overflow in handling variable array.

Issue 1

What make conversational RPC communication different from the non-conversational one is just the “connection-oriented” feature. It just make your life easier on handling the life cycle of transaction involving multiple remote calls to Entire-X RPC server.

In this sense, I don’t understand how using conversational RPC will help.

Issue 2

To use converational RPC, it will to a very large extent increase the resource overhead to the RPC server, and reduce its thoughput, not to say that it will also increase the development/maintenance overhead. I have the understanding that the conversational RPC communication should be used in a caution way, and only it is very necessary. Please correct me if I am wrong.

It is still a myth to me on handling the variable-length of list of structural data reliablely in the RPC call.

Roland

You’re right its Issue 1 and did not help It is too lang ago i used my last conversational RPC so i asked a team-mate and he also said that conversational is a cycle of calls. :oops:

Sascha

1. MAXBUFF is a parameter of the Natural RPC Server, so you need to look at the Natural documentation, see e.g. http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat423mf/parms/maxbuff.htm#fisanchor0

2a. See documentation.

2b. There is no need to use compression for arrays of variable length.

2c. MAXBUFF is not used by the EntireX Broker or the EntireX RPC components - only by Natural.

3. On the Java side it is just a standard Java array. On the Natural side you need to use X-Arrays.

There is a Broker setting of MAX-MESSAGE-LENGTH also (as Jose mentions). It defaults to 31647 and can be up to 2GB (depending on transport protocol). A single message size (MAXBUFF for Natural) cannot exceed MAX-MESSAGE-LENGTH.