Broker Error 0020 0218: API: SEND or RECEIVE-LENGTH exceeds max

, ,
1

Hello,

In testing a service (EntireX 8.2.2 exposing Natural 4.2.7 subprogram), the user is reporting “Broker Error 0020 0218: API: SEND or RECEIVE-LENGTH exceeds max” is returned. In looking this up, the doc says:

0218 API: Send Or Receive Length Exceed Max
Error Class 	0020
Description 	The maximum length possible for send-buffer or receive-buffer is 32K. A call with a send-buffer or receive-buffer greater than 32K will be rejected.
Programmer 	This is a user error. Check the program and correct the error.
Administrator 	None.

I thought EntireX no longer had this 32k limit. How can I get around this error, or is this not possible?

Thanks,

Brian

2

Brian,

what’s the MAXBUFF setting for your RPC servers ?

Cheers

   Wolfgang

3

I have MAXBUFF=60. Is this something I can bump up to 300 to get 5x the current payload size?

I notice I also have ACIVERS=8 but I think I could ACIVERS=9 with EXX 822 and NAT427, yes?

Thanks much!

4

Removed my old post… discovered a connection between broker parm IUBL and MAXBUFF and now started with IUBL=262140 and MAXBUFF=245760.

Will see if that makes a difference.

Thanks!

5

Grand, was about to explain the relationship between these parameters :wink:

6

Figured why stop there… :twisted:

New broker parm values:

IUBL = 1048560
NABS = 32768

New Natural RPC Server values:

MAXBUFF=600
RPCSIZE=1024

Restarted both… now waiting to see the test results.

7

Hi Brian,

where did you find this? Even the 733 documentation is more up-to-date:
http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/entirex/exx733/mac/class_0020.htm#00200218

8

I think this came up when I searched Empower for the error code. I don’t know the exact link I used. Thanks for sharing that the doc for the relevant versions has been updated.

9

Thanks for the feedback, I just was curious if we forgot to update it somewhere (of course documentation for older versions remain unchanged).

Did you solve your problem with the last changes?

10

Yes, the change allowed the message that failed before to be processed. I have requested the team to try the largest possible message to ensure these are sufficient before propagating these settings to the other environments.

11

Hi guys, i have the same problem.

My ACIVERS=2

See my etblog file bellow:

W00/REQUEST  2014-11-13 10:56:56.081 ETBD0282 SPFX Values:
                                              Prefix    = 800009247B84000024000000000000003D85000046850000030000000000000000000000
                                              Unique-ID = 20206167696E32342D2D30303030313732342D2D3030303031333630
                                              Key string: API=9,BID=172.20.1.110,CID=NONE,F=SEND,LS=CP1252,SC=RPC,SN=SRDSW,SV=CALLNAT,UID=DET01011,W=5
                                              0,SL=33879,RL=34391,ETXL=255,ANAME=dllhost.exe,ANODE=agin24,ATYPE=WIN32,RPCLIB=DETRAN,RPCPGM=RB00045D.
                                              Bin string: 0400050039D0DAEF85
                                              SeqID     = 5876
W00/RESPONSE 2014-11-13 10:56:56.081 ETBD0282 SPFX Values:
                                              Prefix    = 8000031818780000180000005CC1D5E200000000A3780000
                                              Unique-ID = 6164616261732D642D2D30303030373633422D2D4638344545323530
                                              Reply Strg: CID=100000000000017K,CST=NONE,CUID=DET01011                        ,EC=00200094,RETL=0003387
                                              9,TXT=API: Msg truncated to fit receive-buffer.
                                              SeqID     = 5872
W00/ACIREQST 2014-11-13 10:56:56.082 ETBD0286 Diagnostic Values:
                                              IP Address.... 172.20.1.110
W00/REQUEST  2014-11-13 10:56:56.082 ETBD0282 SPFX Values:
                                              Prefix    = 800003181800000000000000000000008800000088000000
                                              Unique-ID = 6164616261732D642D2D30303030373633422D2D4638344545323530
                                              Key string: BID=ETB002,CID=100000000000017K,F=RECEIVE,OP=LAST,SC=RPC,SN=SRDSW,SV=CALLNAT,UID=CE0CDEE52AD
                                              9B000,W=NO,RL=33879.
                                              SeqID     = 5877
W00/RESPONSE 2014-11-13 10:56:56.082 ETBD0282 SPFX Values:
                                              Prefix    = 8000031818000000000000005CC1D5E20000000051000000
                                              Unique-ID = 6164616261732D642D2D30303030373633422D2D4638344545323530
                                              Reply Strg: EC=00200218,TXT=API: SEND or RECEIVE-LENGTH exceeds max .
                                              SeqID     = 5877

Can you give me a tip to solve it?

Did you set “IUBL” and “NABS” parameters at “etbfile”? My file don’t have this parms.

I’m using a separated NATPARM to start the rpc server. The atributes “MAXBUFF” and “RPCSIZE” need to be changed in this file?

Thanks a lot and best regards.

12

0020 0218 error specifically indicates that the MAX-MESSAGE-LENGTH attribute (set in the Broker Attribute file) for this service has been exceeded. The earlier default for this was something like 31467 (slightly less than 32k) and that value may be carried over from older attribute files - the new default is 2147483647 (~2gb).

For EntireX Broker on mainframes, the EXTENDED?ACB?SUPPORT=YES attribute needs to be set in the DEFAULTS=NET section to support >32kb messages. For non-mainframe (LUW) environments, TCP transport supports up to the 2gb message size.

13

Hi
Guilherme,

This is not a good idea. You should always use the highest possible ACI version (which seems to be 9 in your environment). ACI version 2 restricts the buffer length to 32k.

14

I agree with Rolf - especially as Natural RPC does no longer honor ACIVERS and uses the highest possible value which is supported by all three involved components (Natural RPC, EntireX Broker stub and EntireX Broker).