REQUEST DOCUMENT - tcp/ip

I have a program which runs a request to an AIX server where another application is located where I could query info using a wsdl.

The code used is REQUEST DOCUMENT, and on the return PARSE to deserialise the xml.

However, the synchronous call is causing me major hassle when performance is checked. The TCP/IP overhead exceeds the cpu processing required by the application. In other words 50ms is required, of which 30ms is taken up by the transportation layer.

is it possible to code ‘persistent sockets’, or request sockets to stay open from my Natural program?

There are 2 reasons, why the socket connections can’t remain in open state:

1.) REQUEST DOCUMENT uses the HTTP 1.0 protocol version, which does not support persistent connections.

2.) Mainframe TP monitors may schedule user transactions under different TCB’s or even on different SYSPLEX nodes for each dialog step. It’s technically no possible to take open sockets connections along in such an environment!

I want to add another aspect to my latest posting:
I cannot believe, that the 30 ms, you mentioned, are mainly caused by the process to establish the socket connection. I would rather think, that most of the time is wait time for data on the line, i.e. transportation time for the socket communication payload!

Thanx for the feedback.
Due to pressure on CPU-usage I had to go another route and dropped the coding as I had it.
THe processing is brilliant and interactive but one the cost of my code, the cost outside it was calculated by the bloke far more clever than I am, processing was changed completely. After trying to explain why processing should be left as it was developed, and using the technology at hand, gave up and asked what would make them happy.

Went with MQ, in asynchronous mode.

Undid the NATWEB, NATXML startup, which makes the Natural Nucleus a lot smaller. Discarded all the XML related code and have gone the asynchronous route. It caused a load of other problems, but the system owner was happy with it …

If there was a way to have persistant sockets for a period of time and save the overhead of the open/close processing, it might have helped.

Next up Im trying to convince my world to allow me development in AIX and move it serverside completely. Once thats done, changing careers …