We are trying to run a stubless RPC call from mainframe to a Java Service.
The data being transferred includes a variable length alpha field. At run time, this field contains xml snippets.
We had no problems generating the RPC Server but when we try to execute the process we are getting error 0013 0218.
The java stack trace shows:
2007-01-31 11:38:35.629/Worker-1 Broker Error 0013 0218: rpcCall: invalid length in buffer: RPC-REPORT-C, length: 244300005, digits: 0.
java.lang.reflect.InvocationTargetException: Broker Error 0013 0218: rpcCall: invalid length in buffer: RPC-REPORT-C, length: 244300005, digits: 0.
Broker Error 0013 0218: rpcCall: invalid length in buffer: RPC-REPORT-C, length: 244300005, digits: 0.
at com.softwareag.entirex.aci.BrokerException.a(Unknown Source)
at com.softwareag.entirex.aci.Marshal.e(Unknown Source)
at com.softwareag.entirex.aci.Marshal.getDataAV(Unknown Source)
at com.vrs.enterprisereporting.entirex.server.RimslibStub.rpc0001w(RimslibStub.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.softwareag.entirex.aci.RPCServer.a(Unknown Source)
at com.softwareag.entirex.aci.RPCService.a(Unknown Source)
at com.softwareag.entirex.aci.RPCServer.a(Unknown Source)
at com.softwareag.entirex.aci.RPCServer.b(Unknown Source)
at com.softwareag.entirex.aci.o.run(Unknown Source)
Attached is the IDL file for the RPC server.
Should we have some sort of dedicated field in the data area that contains the size of the variable length field? If so, is there a specific field name that should be used?
The documentation I have does not include 0013 0218 as a valid error message. (Not even "check program and correct error ")
Thanks

Natural 4.213 on mainframe z/OS
Entirex 7.2
Java 1.5
rimslib.idl (252 Bytes)

since versions of things matter…what version Natural RPC are you using? If you run a Natural RPC Server on the mainframe, it will show the version level of Natural RPC you are using.

also…on your Natural CALLNAT statement are you specifying direction? That is, you need to use

CALLNAT 'RPC0001W' RPC-COMPLETION (AD=A) RPC-REPORT (AD=O)

so the stub generator knows what direction each field is using.

The error is documented, although probably not helpfu to you! See
http://servline24.softwareag.com/SecuredServices/document/java/exx72150/mac/class_0013.htm#00130218

00130218 rpcCall: invalid length in buffer: , length: , digits:
Explanation The RPC response from the server is not well formed. This may happen when RPC client and RPC server are not compatible. The contains the part of the buffer that should be a length, is the length computed from the buffer part, is the number of digits parsed for the length.

I think this is the problem. Natural seems to send data for the OUT field RPC-COMPLETION but the Java RPC Server expects the data for RPC-REPORT at the same place in the buffer.

We currently have the CALLNAT with the correct AD options.
CALLNAT ‘RPC0001W’
USING RPC-COMPLETION(AD=A) RPC-REPORT(AD=O)

Natural 4.213 on mainframe z/OS
Entirex 7.2.1
RPC version is 7.2.1
Java 1.5

Does the value in RPC-REPORT-DATA start with “RPC-REPORT-C” ?

Did you define the field RPC-REPORT-DATA as “A (DYNAMIC)” in Natural ?

I have managed to correct the problem.
The Java RPC Server was compiled and executing under Java 5
I re-compiled with Java 1.4 compliance set.
I am now running 1.4 compiled code in a Java 5 VM and everything is working properly.

Thanks to everyone for their input.

Good to hear that it’s working now.

However, your explanation seems a bit strange, there should be no problem mixing different Java versions.

Could it be that you did changes to your IDL and generated/compiled the server classes but the Java RPC Server was already running ? Java caches the classes so whenever you change the Server implementation you have to bounce the Java RPC Server.

The mismatch appeared to be with the mainframe calls to the Java Server.
When executing Java 5 compiled code, the mainframe call triggered the Broker Error 0013 0218.
When executing Java 1.4 compiled code the error went away. We restarted the server and JVM for each different version, so Java caching could not be the problem.
The problem is not so much with the mixed Java versions as with the Natural to Java communication under version 5.

I could not find any setting in the Workbench that specifies Java compliance levels, although the path to the Java compiler is set to a Java 1.4 SDK

I alwys move the generated source to the appropriate package / folder structure and re-complile in the Java IDE (Eclipse) so I never use the byte code created by Workbench.