[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unknown system state during get request
Eric,
There was a misunderstanding. I did not mean a damaged IFS file in the "C++
Run-Time Library" but a damaged DSM certificate file wherever the
certificate may be stored in the IFS. Please remember that I am just
guessing. I do not know whether a certificate is stored as an IFS file or
somewhere else that only IBM knows.
The quote I mentioned in my previous posting is the name of the pdf file
where I found the EUNKNOWN error code and the C functions that return that
code: "ILE C/C++ Run-Time Library Functions". You can download that pdf
from the iSeries Information Center:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp
Click on the "PDF" link to get to the list of pdf files available for download.
Thomas.
Am 30.11.2010 17:39, schrieb Eric Wasek:
> Thomas,
>
> OK. So how do we check for a damaged IFS file in the C++ Run-Time Library?
> Or do we just reload the whole library?
>
> We did not set up any special certificates on the remote system. It uses
> the same certificate method for our production software get request as it
> does to perform the get request to the Klements site - and the get request
> works to the Klements site. If I am missing or overlooking something please
> let me know.
>
> Eric
>
> ----- Original Message -----
> From:<thomas.raddatz@xxxxxx>
> To:<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Tuesday, November 30, 2010 2:40 AM
> Subject: Re: Unknown system state during get request
>
>
>>
>> Eric,
>>
>> I am just guessing but since the EUNKNOWN error code is returned by
>> several C stream file functions the problem might be a damged IFS file
>> ("ILE C/C++ Run-Time Library Functions"). I do not know anything about the
>> DCM but in case it stores the certificates in the IFS it may be worth a
>> try to check the certificate files.
>>
>> Thomas.
>>
>> ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 30.11.2010 01:01:25:
>>
>>> Von: ericw@xxxxxxxxxxxxx
>>> An: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
>>> Datum: 30.11.2010 01:02
>>> Betreff: Re: Unknown system state during get request
>>> Gesendet von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
>>>
>>> Hello Scott,
>>>
>>> You are very welcome (concerning the feedback).
>>>
>>> We have performed some tests that cast some light on the EUNKNOWN error.
>> We
>>> have used our test program (modeled after your example 3) from the
>> remote
>>> system to perform a get request to your Klements site. Your site is an
>> ssl
>>> site and that get request does work. We have also changed the url in
>> that
>>> test program to perform the get request to the production PC server
>> site.
>>> The url looks like this.
>>> https://www.xxx.net/XXX99/security_export.php?pass=xxxx
>>>
>>> As you can see, it does use https. This url does not work from the
>> remote
>>> system. This same url in the exact same test program does work from our
>>
>>> local system.
>>>
>>> We checked the license programs on the remote system and noticed the
>>> following.
>>> 5722CE3 V5R1M0 Client Encryption 128-bit
>>>
>>> While the local system shows:
>>> 5769CE3 V4R4M0 Client Encryption 128-bit
>>>
>>> We think this is because our local system was upgraded from V4.4 to 5.1
>>> while the remote system was always a 5.1 system. This seems strange
>> given
>>> the fact that the local system is the one that is working. This may be
>>> telling us that there is a problem with base 5.1 encryption while the
>>> upgraded 5.1 encryption is working properly.
>>>
>>> Today we created another test program, so now we have 2 of them - one
>> that
>>> performs a get request to the url that we use in production and the
>> other
>>> that performs a get request to the Klements site. We will be running
>> comm
>>> traces with both of these tomorrow to find out how they are different.
>>> Obviously, the production url will not work while the Klements site url
>> will
>>> work. We are hoping this will give us a clue to the problem. We will
>>> surely also run the comm trace for the local system using the production
>>
>>> url, since it does work. Maybe a comparison of the 3 will help to
>> figure
>>> this thing out.
>>>
>>> The EUNKNOWN error that you wrote about is probably one of many
>> situations
>>> that throw the EUNKNOWN error. We will find out more tomorrow.
>>>
>>> ----- Original Message -----
>>> From: "Scott Klement"<sk@xxxxxxxxxxxxxxxx>
>>> To: "HTTPAPI and FTPAPI Projects"<ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>>> Sent: Monday, November 29, 2010 4:29 PM
>>> Subject: Re: Unknown system state during get request
>>>
>>>
>>>> Hi Eric,
>>>>
>>>> I see... so the upgrade issue isn't about HTTPAPI's update process.
>>>> It's simply that it takes a lot of effort to update your systems
>> because
>>>> there are so many of them. Thanks for the feedback.
>>>>
>>>> I don't know what the problem is -- and that makes it very hard to
>> help.
>>>>
>>>> I do remember another place I saw the EUNKNOWN error you're receiving.
>>>> If you connect to a non-SSL page, but use HTTPAPI in SSL mode, it'll
>>>> cause that error. That's because the OS is trying to negotiate SSL
>> with
>>>> the remote server, but the data it's getting back is unencrypted,
>>>> non-SSL data... and it gets very confused.
>>>>
>>>> Might be worth looking into.
>>>>
>>>>
>>>>
>>>> On 11/29/2010 3:51 PM, Eric Wasek wrote:
>>>>> 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
>>>>>
>> -----------------------------------------------------------------------
>>>>>
>>>>
>>>>
>> -----------------------------------------------------------------------
>>>> 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
>>> -----------------------------------------------------------------------
>>>
>>
>>
>> --
>> IMPORTANT NOTICE:
>> This email is confidential, may be legally privileged, and is for the
>> intended recipient only. Access, disclosure, copying, distribution, or
>> reliance on any of it by anyone else is prohibited and may be a criminal
>> offence. Please delete if obtained in error and email confirmation to the
>> sender.
>
>
> --------------------------------------------------------------------------------
>
>
>> -----------------------------------------------------------------------
>> 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
-----------------------------------------------------------------------