I receive from the RPC Server the error message
02150129 NOT ENOUGH SPACE FOR COMMUNICATION BUFF
These are the main parameters:
RPC=(SRVUSER=‘*NSC’,SRVNAME=RPC007),
RPC=(NTASKS=5,TRACE=(1,E)),
RPC=(TIMEOUT=120),
RPC=(MAXBUFF=4700),
RPC=(RPCSIZE=5000)
The value of MAXBUFF=4992 leads to the above mentioned error 02150129 in the main task. Manual: RPCSIZE=MAXBUFF+8
When I reduce MAXBUFF to 4700, I receive the error 02150129 in the 4th subtask.
The error message means that the NUM-COMBUF value in the Broker is set too small. But NUM-COMBUFF is set in the Broker version 8 to 2000.
From the Maunual:
"The NUM-COMBUFF value determines the maximum number of communication buffers that can be processed by the Broker in parallel.
The size of one communication buffer is usually 16 kBytes split into 32 slots of 512 bytes, but it ultimately depends on the hardware architecture of our CPU.
The data to be transmitted to the Broker and back to the application has to be exchanged between the Broker engine and the PSTORE (Broker Worker) process. A communication buffer is used to store the send data as well as the reply data of all requests that are active in parallel. As soon as the desired data is sent to the target application, the buffer is released."
It doesn
I got this error message at the starting point of the RPC server and not at the first use. So the RPC server must compute and check the right sizes. I am interested in the formula. Maybe SAG can shed some light on this.
The RPC Server doesn’t compute or check the sizes - so there is no formula for this.
MAXBUFF and RPCSIZE are parameters of the Natural RPC Server and they basically define the maximum message length which can be processed by the Natural RPC Server. There is a corresponding parameter in the attribute file of the EntireX Broker: MAX-MESSAGE-LENGTH.
NUM-COMBUF is a parameter of the Broker and specifies the number of communication buffers. The communication buffers keep all send and receive data needed for all active Broker requests. So this parameter is not related to a particular instance of an RPC Server. It depends on the number of requests in parallel and the size of the request and response data. The request buffer is allocated when the request arrives in Broker. The response buffer is allocated when the response is generated. The request and response buffer are deallocated after sending the response.
If you have NUM-COMBUF=2000 you get ca. 31 MB for communication buffers. If you have 1 client and 1 server and a message of size 5 MB you need ca. 10 MB for communications buffers assuming that both the request and reply is 5 MB of data. If you have more clients and/or servers which are doing RPC calls in parallel you need additional communication buffers.
You can use SMH to monitor your (remote) Broker. SMH shows you the active clients and servers as well as the number of COMBUF slots and free slots.
Hi Rolf,
You said: The RPC Server doesn’t compute or check the sizes - so there is no formula for this.
How can the RPC Server send out an error message regarding the size if it doesn’t compute the RPC parameter sizes and compares it with the broker values?
02150129 NOT ENOUGH SPACE FOR COMMUNICATION BUFF
Can you tell me what computation does the RPC Server use to come to the conclusion that the NUM-COMBUF on the broker is too small?
Thanks,
Dieter Storr
Hi Dieter,
the 02150129 error is actually the response code of a Broker call which was issued by the RPC Server. So it’s the Broker who detects the situation that there are not enough comm buffs to serve the request. The RPC Server just reports the error message received from Broker.
So it would appear that there is a formula for the calculation of COMBUFFs, but it is done by Broker, not the RPC Server.
The RPC Server supplies the MAXBUFF (message buffer size) - MAXBUFF=5000 is 5mb. NTASKS=5 means 5mb per server is needed or 25mb just for the servers is needed. Thus, it is fairly likely that with 31mb for COMMBUFFs, one or more of the servers will not have sufficient room, and certainly any client applications will not.
I presume then that we also have to allow for the number of concurrent clients. That is, if we have 5 servers and 15 clients (10 waiting for service), we really need to allow for 5mb * 20 partners = 100mb COMBUFFs required?
And the new magical dynamic memory management option in v8 can figure all of this out for us?
From all the discussions I had, the formula should be, right?
NUM-COMBUFF (broker) = (2*MAXBUFF) * NTASKS
NUM-COMBUFF= 2 * 5000 * 5
NUM-COMBUFF = 50000
Dieter Storr
One COMBUF is 16K. MAXBUFF is in K, so divide by 16:
NUM-COMBUFF = (2*MAXBUFF)*NTASKS / 16
or NUM-COMBUFF=3125
This however only allows the servers to start. You need to add in whatever the active and pending clients need also.
Douglas:
We defined NUM-COMBUF = 4000 and using TCP/IP.
Sometimes, we can bring up 11 tasks and sometimes 6 tasks fail to start.
Now, the formula to determine the size of NUM-COMBUFF doesn’t make sense:
NUM-COMBUFF (broker) = (2*MAXBUFF) * NTASKS / 16
NUM-COMBUFF= 2 * 5000 * 11 / 16
NUM-COMBUFF = 6,875
How can we avoid to get the error
02150129 Not enough space for Communication Buff.
In December, we are going into production with EXX 7.2.1.92 using TCP/IP and need a big communication buffer for our XML data.
Version 8 with the dynamic memory management is no option at this time.
Thanks,
Dieter
Hi Dieter,
I’m a bit confused now. I thought you were using Broker version 8.0. Now you say that you are running version 7.2. Please clarify.
7.2 (which by the way is out of support) has a completely different TCP/IP implementation and memory management which has been improved considerably with 7.3/8.0. Especially for large message sizes …
Broker version 7.2 uses NUM-COMBUFF only on Windows, Unix, and VSE - but not on z/OS.
If you get the 0215 0129 error with a 7.2 Broker on z/OS then this is actually a GETMAIN error. To solve this you need to increase your region size.
You can reduce the memory requirements by using EntireX compression. For Natural RPC you have to call USR4009N to enable compression (COMPRESSLEVEL).
Is there any way with v7.3/8 to see the impact of compression on memory use? if I use dynamic memory management?
I’m interested in cases similar to Dieter’s - large XML documents that probably will benefit from compression and will impact the allocation of memory within Broker in a large way.
Rolf and Douglas,
We solved the problem by starting the broker in a bigger region with the same parameters.
I thought that we were talking about a broker located on the mainframe (z/OS) and not on Windows? Then, NUM-COMBUF makes sense. We increased the size and didn’t see a difference.
The following error message in the broker was the key:
ECM0019I: Reply Buffer Getmain error
Now, we can start (and use) 20 tasks.
Hmmmm…
And yes, V8 is on our list for next year.
Thanks,
Dieter Storr
Hi Rolf,
Sorry for the confusion.
We are running EXX v7 in development and production and switched from SVC to TCP/IP because we need to communicate with up to 5mb XML data. One project will be migrated in December 2008 into production.
EXX v8 is in a special test environment and we need more time to test before we implement it in production. Our plan is to go in 1Q09 into production with this version.
HTH.
Dieter
Run a test program and check regularly “Number of COMBUF slot free” in SMH. We have also seen better response times.
Up to version 7.2 the Broker on z/OS doesn’t use pre-allocated COMBUFFS but does dynamic memory allocation. That’s why you receive the getmain error.
Starting with 7.3 the z/OS Broker uses the same technology as on Windows/Unix with COMBUFFS for TCP/IP. With 7.3/8.0 the setting of NUM-COMBUF is relevant.
BTW in case you haven’t done that already: make sure that not the complete PDA is transferred from the RPC Client to the RPC Server and then back again to the RPC Client - or only if really needed. If you have an EntireX RPC Client use the IN and OUT direction indicators in the IDL file. For a Natural RPC client specify the direction during stub generation or in case of stub-less RPC use the AD keywords in the CALLNAT statement. If you send your large XML document unintentionally back to the caller this has a severe impact on performance and memory consumption.