Hi

We are operating EntireX for a customer, and after upgrading a Win2k server to EntireX miniruntime version 812, a third party application is getting response 00200218 - API SEND or RECEIVE-LENGTH exceeds max.

After some tracing I could reproduce the error, and seems to be triggered by the combination of the following attributes:
Function = 2 'Receive
APIVersion = 2
RecieveBuffeLenght > 31647

Software AG support says that the problem is caused by transport method NET on z/OS.

The Broker is running on z/OS all right, but all communication in this scenario comes from the EntireX miniruntimes and only TCPIP communication is involved.
The application had run for several years with a version 7 miniruntime.

Has anyone experienced similar problems?

I am wondering that this had worked before.
ACIVERS=2 does not support messages with length > 32K and this is independent on the transport method.
Problem should be solved for TCP/IP with ACIVERS=3 or higher.

The following VB Script reproduces the error:

Set EBX = Createobject(“EntireX.Broker.ACI”)
EBX.APIVersion = 2
EBX.ReceiveBufferLength = 31648
EBX.Function = 2 'Receive
EBX.UserID = “EXX812”
EBX.BrokerID = “Insert V8 Broker ID”
EBX.ServerClass = “ACLASS”
EBX.ServerName = “ASERVER”
EBX.Service = “ASERVICE”
EBX.ConvID = “NEW”
EBX.Wait = “60s”
EBX.InvokeBrokerFunction
MsgBox "EntireX Return Code: " & EBX.ErrorCode & " - " & EBX.ErrorMsg

Wolfgang: The first versions of EntireX supported messages up to 2GB when using TCPIP - at least I was told.
And we also used messages >32kB for Natural RPC on z/OS by using the C-stub and TCPIP for Natural.

Steen, but this should have only worked with ACIVERS=3 or higher.
If I use TCP/IP on z/OS with ACIVERS=2, I can’t send more than 32K of data (used broker stub was BKIMBTSO).

Check your Broker MAX-MESSAGE-LENGTH in your Broker Attribute file. The default is 31467.

Wolfgang: We probably has specified the API version via RPC parms.
Douglas: MAX-MESSAGE-LENGTH not specified meaning we run the default.

But that’s actually more strange, since we upgraded the Broker on z/OS long time ago.

From broker trace we can see that the error actually comes from the broker, even we only change the miniruntime.

Can we agree, that this has nothing to do with Adabas or Net-Work communication?

Keen, this has nothing to do with Adabas or Net-Work communication or the Broker version. This problem is only related to the API version used.
Please retry with an higher API version.

earlier versions of Natural documented that the message length for API Version 2 was fixed by the version - this may be a function of the stub, and since the behaviour was unique to this API version, was dropped (I’m speculating here, I don’t have any inside knowledge).

You still have to do two things: set the MAX-MESSAGE-LENGTH to a larger value than the default and use a higher API Version.

I heard it was an issue with the SetSendDataLong function