We are trying something where an entire batch feed is being sent via a web service interface so we can store all the records into ADABAS for processing later. For larger payloads, the client is receiving this message:
EntireX Broker returned communicator error: Not enough space for Reply buffer
The data is not making it to the Natural RPC Server, but I saw this in the EntireX Broker output:
EntireX Broker Memory Pool Allocations:
Address 0x000000483E800010 Length 4481304 bytes LONG MESSAGES POOL
EntireX Broker Memory Pool Allocations:
Address 0x000000483ED00010 Length 4481304 bytes LONG MESSAGES POOL
EntireX Broker Memory Pool Allocations:
Address 0x000000483F200010 Length 4481304 bytes LONG MESSAGES POOL
Diagnostic Values:
RCB PROCESS QUEUE FCT_RECEIVE
SPFX Values:
Prefix = 22010A2800096028000000285CC1D5E200000000000960F501000000000000
00000960AE00000000
Unique-ID = 0004C1B728280000404040404040404000FCC580D185D575BEB34C12
Reply Strg: EC=00200094,RETL=0013332221,CID=0010000000004739,SEQID=18522,C
LID=1375,CST=NONE,CUID=xmluser ,UOWST=RECV_NONE,TX
T=API: Msg truncated to fit receive-buffer.
The PDA that this service is based on looks like this:
L Name F Length Miscellaneous
1 IN-FEED-TYPE A 8
1 IN-BATCH-ID A 40
1 IN-DATA (1:*)
2 IN-RECORD A 4000
1 OUT-STATUS A 8
What can I do to avoid this error?
-Brian
I will add… I thought there was support for long alphas but when I try to remove the length, it defaults to 10 bytes long. If the alpha could be dynamic I think that would help. Is that possible?
Google helped me locate this:
ETBM0129 Not enough space for Reply buffer
Explanation
The EntireX Broker buffer manager could not allocate enough memory for the Reply buffer. The value of startup parameter NUM-COMBUF is responsible for the maximum buffer size.
Action
Try the call again later. Increase the value NUM-COMBUF if the error occurs frequently.
I will try that and see if I can’t get around this.
-Brian
00200094 error on the Natural RPC server side indicates that the MAXBUFF needs to be larger. RETL=0013332221 indicates your message is about 13mb.
Make sure all the EntireX buffers are large enough to accommodate your, message - not only NUM-COMBUF (you need at least 814 just for the 13mb message), but NUM-LONG (about 6510). If using SVC, make sure IUBL and NABS are also large enough.
Are you using dynamic memory management? If you are, check that you have enough OS memory to handle the message sizes being utilized. If not, take a look at it - it reduces a lot of the hassles of figuring out memory and buffer sizes.
Brian, did you specify the DYNAMIC keyword?
@Douiglas - thanks for the suggestion on NUM-LONG as I hadn’t discovered yet that I should address that. I was able to observe the NET connection problem after raising NUM-CONBUF which is a familiar message that, in the past, had meant I needed to increase IUBL and NABS, so that is certain. Thanks also for the idea of checking with the platform folks on available OS memory. They at least should be aware of what I am looking to do. The sending application (an Oracle R12 financials module) can limit their batch sizes, splitting into multiples if necessary, and this could help determine the sweet spot for that.
@Rolf - I tried all kinds of things. The problem is that I defined my PDA externally and I can’t figure out how to specify DYNAMIC like I can if I were defining the PDA in-line in the subprogram itself. I tried using the comments field (typing in DYNAMIC and /* DYNAMIC), trying a .E on the field in the data area editor… I just can’t figure it out. Guess I will just forget about defining as an external PDA and bring it inline. I don’t think they covered how to define dynamic alphas in the data area editor when I was being trained on it back in 1988 LOL.
