[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unknown system state during get request
Thomas,
Thanks for the clarification.
Nor do I know where the DSM certificate file is stored. Your guessing is as
good as my guessing. That is what is great about this forum - everyone can
submit their thoughts and in the end we will (hopefully) come up with a
method to correct the situation.
What a great link. I did check out that pdf and on page 487 of the text
(499 of 562 of the pdf) it shows EUNKNOWN as a possible error in many, many
functions. Probably too many to be useful. I will do more checking for
other clues in this manual as time allows.
Now on to the email from Scott that just came in.
Eric
----- Original Message -----
From: "Thomas Raddatz" <thomas.raddatz@xxxxxxxxxxx>
To: "HTTPAPI and FTPAPI Projects" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, November 30, 2010 12:19 PM
Subject: 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
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------