Hi All-
Can someone please give me a little more info on this error code.

This error started to show up in our client’s non production application when we upgraded to Nat4.1.3 in our non production environments. We have an outside agency that is hosting our exx v6.1 XML adapters. They do not use the XMl servlet, just the adapters and exx jar files. Broker receives the request, Natural processes the message, sends the response (a port sniffer has proven the response leaves Broker and is a good message) and the client then displays the above mentioned error.

Please note that all the contractors at the outside agency that wrote the client app have left. I am working with a network person who is new to WebSpherer App Server and doesn’t know their app. I have taken their app and inserted the exx v7.2.11 jar file in it and sent it back to them to deploy.

I do have an open support request (579780) but at this point I am taking any kind of info I can get from anywhere.

Here is the SOAP response form the client’s WAS log:

<SOAP-ENV:Envelope xmlns:SOAP-ENC=“http://schemas.xmlsoap.org/soap/encoding/” xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd=“XML Schema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”><SOAP-ENV:Body xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”><SOAP-ENV:Fault xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”>SOAP-ENV:CLIENTBroker Error 0013 0207: rpcCall: error returned from server application for program FMARC0N7 (FMARC0N7 9999 NAT6974 Conversion error on Server, reason 6 ,003.): number = 06974 in line 9999 of program FMARC0N7 status=O, level=01http://192.168.108.13/XMLAdapter</SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>

Thanks,
Chris

This is a NAT6974 error from the Natural server. NAT6974 reason 6 is:
6: Format buffer error for :3: rd parameter.
You may want to set the TRACE=2 on the Natural RPC Server so you can see the data buffers being processed. If the error is happening on the client side, you should be able to see the message and its format description leaving the RPC server.

Check the Natural subprogram FMARCON7 and the IDL / Wrapper you are using - there is probably some mismatch in the third parameter (format, length, position, etc). Are you using AUTORPC=ON in the Natural RPC Server or are you using a generated stub: are the IN and OUT’s still lined up as they were in the previous version? If IN or OUT was omitted, it defaults to INOUT (values are sent to the server and received from the server).

Hi Chris,

without having a trace it’s even impossible to speculate about this issue.
Try to produce a Natural RPC Server trace or an EntireX Java trace on the RPC client (-Dentirex.trace=2). A network sniffer trace of the Broker calls would also be sufficient.

Another important question is what version of Natural RPC you are using. Are you using the “old” version (module NATRPC) or version 6.1.1 (module NATRPC61) ?

Thanks Doug and Rolf-

Here is a little more info:

We have done some more testing and the problem is happening on the server side. It looks like the problem happens in the trace during the ‘Convert to intern’ action. The next statement, the execute subprogram is never done.

Here is our working production trace:
SEND-LEN: 30720 REC-LEN: 280
M *** Logon to PPPROD executed
M *** Convert to intern
M *** Execute callnat… FMARC0N7 at 13:57:05
M *** Back from execute callnat FMARC0N7 at 13:57:05
M *** Convert to extern
M *** Logged off to SYSTEM at 13:57:05
M *** Ready for reply to FMARC0N7 at 13:57:05

And here is our nonproduction trace that doesn’t work:
SEND-LEN: 30720 REC-LEN: 300
TRACE DATA DISPLAYS HERE
M *** Logon to PPTEST executed
M *** Convert to intern
M FMARC0N7 9999 NAT6974 Conversion error on Server, reason 6 ,003.
M *** Ready for reply to FMARC0N7 at 07:58:50

Does anything stand out here?

We are using RPC v5.1 and we have also tried v6.1. We’ve tried with compression=2 and compression=0.

We do notice that the REC-LEN is different for prod and nonproduction (as seen above) but we can’t explain the difference.

Thanks,
Chris

Hi Chris,

are you really sure that the definition in your IDL file matches the pda of the Natural subprogram ?

You are using groups in your IDL file (level 2 fields), does your Natural subprogram has the same group structure ?

Also, in case you are running a vanilla Natural 4.1.3 it might make sense to upgrade to the actual service pack.

This issue has been resolved by using the jar file from hotfix EXX721.23 in the client application.

Thanks for the responses.

Chris