Mainframe REQUEST DOCUMENT not completing when unix web service is down

, ,
1

Calls from the mainframe are normally working fine to the unix based web service but sometimes the web service unexpectedly goes down. This would not be an issue if the REQUEST DOCUMENT command timed out and gave us an error back but it has on one occasion sat there for many hours, blocking processing.
What configuration parameter(s) control the length of time to wait for a response before abandoning the call attempt?

2

Could it be your error handling that’s masking the problem? When I specify an invalid web address, I receive error NAT8304 on the REQUEST DOCUMENT statement. I would expect something similar if the web service was unavailable. How does your program react to an erroneous webservice specification?

3

For a non-response to a call I would expect to receive a timeout http response but the REQUEST DOCUMENT command is just hanging. One scenario is when this could occur is when the application server at the other end is having its own internal issue preventing it from responding. Its process is spinning and not able to complete the request that was received for processing. In java, the http call attempt would automatically timeout after the system default period or a user defined one. I don’t see how to achieve the same with the REQUEST DOCUMENT command. Hence, my question as to whether the timeout is in the system configuration that is not accessible to a developer.

4

Have a look at this profile/Session parameter:

RQTOUT – REQUEST DOCUMENT Timeout

The default value is 0 = no timeout

Finn

5

Oops was fooled by “unix” in the header.

This parm is not available on MF.

Finn

6

Does anyone know if there is an equivalent parameter for the mainframe call?

7

Had a look in the right documentation:
On MF this is the way to go…

RDTOUT - Timeout Value for Ongoing HTTP Requests
RDTOUT=value specifies the timeout (in seconds) for HTTP requests that are in progress.

This keyword subparameter is not supported by the IPv4-only load modules NAT2TCP4 (z/OS) and NCFIP482 (z/VSE).

8

Thank you so much. With RDTOUT set we are now getting an 8304 error that we can trap and handle.