In Gen 8.5 via a series of PTFs, two new parameters were add to the Transaction Enabler. These parameters allow users to:
This article is designed to assist users to better understand these parameters and how and when to use them.
The 8.5 PTFs that introduced these new parameters are:
RTN85015 - Windows
RTI85303 - HP-UX Itanium
RTL85303 - Solaris
RTR85303 - AIX
RTX85303 - Linux
The Transaction Enabler uses TCP/IP sockets to communicate between the Clients and aefuf, aefuf and aefad as well as between the aefad and cooperative Load Modules (Unix only).
TCP/IP communication like this is subject to the amount of space reserved by the TCP/IP stack for the applications and during periods of heavy throughput between the various processes, this reserved space will become insufficient. Only by starting with larger Send/Receive buffers can applications hope to have enough reserved space on the TCP/IP stack for data transmission.
Prior to the PTFS, the TE's internal mechanism for setting the size of the Send/Receive buffers was to use the default settings on the host system. Users could influence the size of the buffers by making system wide changes to the defaults and the TE would use them at startup time.
Applications using TCP/IP communications can set the buffer size without relying on the system settings and it was decided to allow users to control what the TE allocates for the buffer size. This was done by adding the startup parameter -b to both the aefad and aefuf processes. The -b parameter tells the processes to allocate Send and Receive buffers in 65K increments depending on the value of the parameters e.g. to allocate 10 increments:
-b 10 = 656,000 bytes.
Setting the parameter and implications:
The algorithm used by the aefad and aefuf to set the Send/Receive buffers based on the parm value of -b is as follows:
To determine what happens when you use a certain value and what decision the TE makes on how to use the value, you must start the TE (both the aefuf and aefad) with logging (ex. -t31). In the logfiles you will see messages (see below) that will show how the TE processed the -b parameter.
Here is an example of an aefad logfile where the system default value is 131k for the Send buffer and 1024k for the Receive buffer. The user set the -b to 2. You can see that the aefad for the Send buffer determined that the user value higher than the system default and that the system default for the Receive buffer was higher than the user value.
14:29:03.520===>aefad: SYSTEM SND_BUF (131072) < USER setting(-b2 * 65536)...using USER
14:29:03.520===>aefad: SYSTEM RCV_BUF (1024000) > USER setting(-b2 * 65536)...using SYSTEM
If the user selects a value for the -b parameter that the system, for some reason cannot allow, they would see the following message in the trace log that the system default will be used.
14:32:17.683===>aefad: Buffersize (10240000) rejected by the system
The value to use for this parameter depends on the following factors:
In many cases, the default value will suffice and these factors should be considered before changing it:
By default, the TE will accept properly formatted SOAP requests from Clients. This behavior was introduced in Gen 8.5. WebService requests, like all other Client requests must go through the aefuf process and NOT directly to the aefad. WebService requests directly to the aefad will be rejected with one of the following error messages:
TIRM030E: Application failed - Updates have been backed out
ODC: (Transport-WS:55) "Send failure: Connection was reset" occurred in handleComm(WS)().
OR
TIRM030E: Application failed - Updates have been backed out
ODC: (Transport-WS:56) "Recv failure: Connection was reset" occurred in handleComm(WS)().
In the above referenced PTFs, users have the ability to disable the WebService with the parameter -n. The default value is -n1, which means that this TE will accept Webservice requests. A value of -n0 will disable this feature and any WebService requests will be rejected by the TE and the Client will receive this type of error:
TIRM030E: Application failed - Updates have been backed out
CSU-GENERAL-ERROR: WsErrorParser::parse(): SAXParseException (line: 1, col: 1) caught: 'invalid document structure'.