[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
Hey Scott,
Still trying to figure out why this is happening to the pgm...
I just got a response from IBM about this issue which I attached below..
Any idea?
//** email snip-it from IBM **//
CUSTOMER REP: Paul
ACTION TAKEN: I sent him:
In the V7R2 documentation for GSK Toolkit the parameter name changed
from GSK_OS400_READ_TIMEOUT to GSK_IBMI_READ_TIMEOUT, but it was not
marked as "new" in the v7r2 documentation. Check your code to see if
you are using the old parameter name.
Bob
//** END of email snip-it from IBM **//
Thanks,
Paul John Kenosky
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, January 11, 2016 8:52 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: FW: FW: Help - HTTP_URL_POST_XML recvresp hanging
Paul,
The web service provider shouldn't be able to prevent HTTPAPI from timing out. Likewise, HTTPAPI should time out, no matter what your CHGTCPA network settings are.
Aside from a bug in HTTPAPI or the IBM i operating system, there shouldn't be anything that would prevent it from timing out.
Unfortunately, without being able to reproduce it on my own system, there's very little I can do.
-SK
On 1/11/2016 8:01 AM, Paul Kenosky wrote:
> Hello Scott,
>
> I am having trouble re-creating the problem myself now... It has not happened lately(about a week) since I been trying to catch it in debug... and hasn't happened on its nightly run... Unfortunately, I don't think I can share the code to the web service.
>
> This is a new pgm connecting to a new web service, so I wonder if it could be something on their end that is not/was not setup correctly?
>
> I am going to setup a loop on this pgm so it makes a call to the web service every 30mins, so hopefully I can catch it in debug.
>
>
>
>
> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
> Klement
> Sent: Saturday, January 09, 2016 2:27 AM
> To: HTTPAPI and FTPAPI Projects
> Subject: Re: FW: Help - HTTP_URL_POST_XML recvresp hanging
>
> Paul Kenosky,
>
> TCPKEEPALV is not a time-out value. The default of two hours means that it'll send a packet every 2 hours to test the line and check if it's still active. This shouldn't have any impact on HTTPAPI at all.
>
> HTTPAPI should be doing it's own time out code. And with all of the people using it (and there are a LOT) I've not run into this timeout code getting "stuck" not timing out. Of course, that doesn't mean that you couldn't be unlucky and hit a bug that nobody else has, that's always possible...
>
> In order to help further, I need to know how to reproduce the problem
> you're seeing. Basically, I need to be able to run your program on my own machine where I can debug/troubleshoot it. Is that possible?
> Unfortunately, a code snippet isn't good enough, I need something that I can actually run.
>
> -SK
>
>
> On 1/8/2016 12:50 PM, Paul Kenosky wrote:
>> Thanks for helping me through this...
>>
>> I will look into CHGTCPA TCPKEEPALV(1) and see if that leads me anywhere... however you mention the default is 2 hours... I have left one of the hanging jobs run for about 6 hours before cancelling it....
>>
>> As for the TimeOut value I am using default CONST which is I believe 60secs...
>>
>> I am setting ccsids which im not really sure what it does or if I even need it...
>> (someone started the program and it was in there when I got it)
>>
>> //** below is RPG code that is making the call **//
>>
>> HTTP_SETCCSIDS ( 1208: 0);
>>
>> //'Call service to check address
>> returnCode = HTTP_URL_POST_XML
>> ( %trim(POSTLINK)
>> : %addr(soapParms) + 2
>> : %len(soapParms)
>> : *null
>> : %paddr(response)
>> : %addr(returnUserData)
>> : HTTP_TIMEOUT
>> : HTTP_USERAGENT
>> : 'text/xml; charset=utf-8'
>> : %trim(ACTIONLINK)
>> );
>>
>> if (returnCode <> 1);
>> outError = 'Validation Call Failed';
>> endif;
>> //** end RPG code that is making the call **//
>>
>>
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.c
> om_mailman_listinfo_ftpapi&d=CwIF-g&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E
> 665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=JwWl0MErlXxRxXTt91ybq7HSdHmCQR-
> KoiEe3mjB4gY&s=kqjXKsptSkcVv9bZp_7FwyWVrT6q9GeIl8YpGbDycVE&e=
> ----------------------------------------------------------------------
> -
> ----------------------------------------------------------------------
> - This is the FTPAPI mailing list. To unsubscribe, please go to:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.c
> om_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E
> 665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8GvWW
> K0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
> ----------------------------------------------------------------------
> -
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.scottklement.com_mailman_listinfo_ftpapi&d=CwICAg&c=rxuyg758I4Zd3CDHNny_Hw&r=JkfuZ4E665mlFfpIfGYhkELl0BTRh7r_Gm0xUf-MqYc&m=bYC1AHVFwN-aCe00qOW-lM4f3p8GvWWK0DljtsChZGo&s=wemwSnW4VpfHXMkUmL_15w1XbOROGJRWi963Acp6Jl8&e=
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------