Natural RPC call fails, protocol error

Product/components used and version/fix level:

Natural 9.2.1, both EntireX 10.1 and EntireX 10.9

Detailed explanation of the problem:

Calling subprogram the following error was returned

  • Error 1014 6978: Natural RPC Server returns: VEHICLEJ 9999 NAT6978 RPC protocol error on Server, reason 3 ,10010031., NE=01,VEHICLEJ999901R*

after adding this subprogram to the directory SYSRPC/ SM /A the error changed to

  • Error 1014 6978: Natural RPC Server returns: VEHICLEJ 9999 NAT6978 RPC protocol error on Server, reason 3 ,10010031., NE=01,VEHICLEJ999901R*

To address the recommendation below MAXBUFF was increased significantly but without success.

  • 3 - No space to load directory. Increase the RPC size.*

Same issue occurred on two servers.

Note, that subprogram calls a flow on IS via Direct RPC that was also called successfully via a program generated from the same IDL generated when creating Direct RPC.

To avoid recursive looping in the subprogram, this subprogram was cloned, so it is the clone that is called via Natural RPC in IDL tester.

Error messages / full error message screenshot / log file:

Latest one:

Error 1014 6978: Natural RPC Server returns: VEHICLEJ 9999 NAT6978 RPC protocol error on Server, reason 3 ,10010031., NE=01,VEHICLEJ999901R

Question related to a free trial, or to a production (customer) instance?

Licensed

A NAT6978 error is reporting an EntireX error code. NAT6978 rc 3 is:

3: The RPC protocol header or RPC format buffer is invalid.
After the reason, the corresponding EntireX error number is
shown in the message. In the case of format buffer errors,
the erroneous element is appended to the error number.
The EntireX error code is 10010031, which states:
|10010031|String buffer item overflow of the RPC protocol|
| — | — |
|Explanation|Internal error in string buffer.|
|Action|Contact Software AG Support.|

If you haven’t already, open a support request. Otherwise, we’d need the IDL that’s causing the error to be able to suggest modifications.
SYSRPC is used to create the client mapping for a CALLNAT ‘rpcsvc’ - it has no bearing on subprograms being called from a Natural RPC Server.
What recursive looping were you trying to avoid? From what you have said, you are calling a subprogram (VEHICLEJ) that calls IS service VEHICLE via DirectRPC? Is there also a subprogram VEHICLE in this library IMPERIAL? Are both Natural RPC Server and the IS DirectRPC using the same Broker ID? (ETB096?)

The IDL tester is trying to call a subprogram VEHICLEJ in library IMPERIAL. Your IDL Tester settings will identify the EntireX Broker that the Natural RPC Server is using.
image

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.