[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unknown system state during get request
Hello Scott,
I did not want to burden this mailing list with the details of the "several
hours" it would take to upgrade to the latest HTTPAPI on my original post.
But now that you asked .... We are using your HTTPAPI software on MANY
systems, not just a few. For it to work on those systems we have to
download it to our 5.1 system and compile it (fast and easy so far) and send
the compiled software to all those systems and install it on each of them.
The sending and installing is what takes several hours of time. This is all
in an effort to keep all the systems we support on the same release of
software. We try to do this to avoid total confusion even though the many
systems are running a wide variety of OS versions. I am very thankful that
we have been able to run one (old) version of HTTPAPI for so many years
without any problems.
If we do need to upgrade to the latest version of HTTPAPI to figure out (or
help figure out) what the problem is, then that is what we will do. I was
hoping someone else encountered this situation on their system and would be
able to say "change this little setting on that command page" and all would
be fixed. So if we can't make a simple change and get it to work, then we
will have to upgrade and run our quick tests to see if it will work.
I do not think the problem is within HTTPAPI. Your version 1.16 has been
working on so many systems (for 4 years or more!) that I do not see how it
could have a problem.
As you stated there are 2 possibilities: (1) HTTPAPI is providing bad
information to the API. Or (2) The API has a bug. How do we figure out
which situation is the culprit? About 10 days ago I did use STRDBG to walk
thru some of the HTTPAPI subprocedures. My notes from then say that it
returned *Off from comm_connect. I think I checked some pointers at that
time and the parms did contain pointers, but I had no way of knowing if the
pointers were correct or not. I probably missed what I really needed to be
looking for. The subprocedures seemed to work correctly up to that point.
What can I do to help figure out the cause of this situation? I am open to
all options.
Eric
----- Original Message -----
From: "Scott Klement" <sk@xxxxxxxxxxxxxxxx>
To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Monday, November 29, 2010 1:53 PM
Subject: Re: Unknown system state during get request
> hi Eric,
>
> What I can tell you is that HTTPAPI is calling the gsk_secure_soc_init()
> API provided by OS/400. The API is failing with error code
> GSK_ERROR_IO, and errno is set to EUNKNOWN. That's all the information I
> have about the error at this point.
>
> As the error is occurring during a call to an IBM API, we're left with
> two possibilities: (1) HTTPAPI is providing bad information to the API.
> Or (2) The API has a bug.
>
> Unfortunately, "Unknown System State" isn't a lot of information!
>
> I'm curious about your inability to upgrade to the latest HTTPAPI. You
> say it'll take you several hours -- but I don't understand why. I would
> like to understand it better so I know how to improve HTTPAPI in the
> future. What difficulty do you have updating HTTPAPI?
>
> Even if I had a fix for HTTPAPI that solved the problem you encountered,
> I don't see how I could get it to you? If I issue a new copy of HTTPAPI
> with the fix, you'd be unwilling to install it because of the time it
> takes to update?
>
>
>
> On 11/29/2010 12:58 PM, Eric Wasek wrote:
>>
>> We use a simple program to send a get request to a server and receive
>> back information in an IFS file. But instead of information in a
>> file, it is getting an error. Following is the debug information.
>>
>>
>> HTTPAPI Ver 1.16 released 2006-05-07
>>
>> New iconv() objects set, ASCII=819. EBCDIC=0
>>
>> https_init(): entered
>>
>> -----------------------------------------------------------------
>>
>> Dump of local-side certificate information:
>>
>> -----------------------------------------------------------------
>>
>> http_url_get(): entered
>>
>> http_persist_open(): entered
>>
>> http_long_ParseURL(): entered
>>
>> (GSKit) I/O: Unknown system state.
>>
>> ssl_error(406): (GSKit) I/O: Unknown system state.
>>
>> SetError() #30: SSL Handshake: (GSKit) I/O: Unknown system state.
>>
>>
>> Some of the code from the program is as follows.
>>
>>
>> C CALLP HTTP_DEBUG(*ON: DBGFILE)
>>
>> c eval rc = https_init(*BLANKS)
>>
>> c if rc< 0
>>
>> c eval msg = http_error(rc)
>>
>> c if rc = HTTP_NOTREG
>>
>> c exsr RegisterMe
>>
>> c return
>>
>> c else
>>
>> c dsply msg
>>
>> c return
>>
>> c endif
>>
>> c endif
>>
>> c eval rc = http_url_get(
>>
>> c UrlText :
>>
>> c '/tmp/httptest.html')
>>
>>
>> This code is a modified version of example 3 from Scotts examples.
>> We
>> change the UrlText constant to what we use during production and
>> compile this code on our version 5.1 system and send it to another
>> remote 5.1 system to test. It runs correctly on our 5.1 system, but
>> not on the remote system. We have been running this get request on
>> the local system for many years, but it has yet to work on this
>> remote
>> system.
>>
>>
>> We have changed the UrlText constant to perform the get request to
>> the
>> Klements site (like in example 3) and it works correctly from both
>> the
>> local and remote systems. So we know that it can work from both the
>> local and remote systems. It just does not work from the remote
>> system with the url needed for the live, production software.
>>
>>
>> We know that this is a very old version of the programs (1.16). But
>> this wonderful old version is working great at several locations. To
>> upgrade all of them would require several hours that I do not wish to
>> use as part of this project unless necessary. We are only currently
>> using the basic functions of version 1.16 and do not want to upgrade
>> until we need to use some more advanced functions.
>>
>>
>> A search of the archives found some PTFs for 5.4 (while the problem
>> system is on 5.1) and some Digital Certificate Manager information
>> that should not affect what we are trying to do.
>>
>>
>> Any ideas or assistance is appreciated.
>>
>>
>> Eric Wasek
>>
>>
>>
>>
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list. To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------