[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HTTPAPI returns a "Host name look up failed"
Thomas,
Sorry for the delay - I'm back on task now. I agree that the F11
thing was just a characteristic of V5R1's version of the debugger.
I added the breakpoint as instructed (#1, below) and got the same
values we've already seen for "element".
I added the next breakpoints as instructed (#2, below) and got the
following:
> EVAL len
LEN = 7
> EVAL localName
LOCALNAME =
> EVAL localName :x 32
00000 736F6170 3A456E76 656C6F70 65000000 -
Ë?/ø.á>ÎÁ%?øÁ...
00010 00000000 00000000 00000000 00000000 -
................
Now, here's something interesting. Compare my hex value to yours:
Mine
00000 736F6170 3A456E76 656C6F70 65000000 -
Ë?/ø.á>ÎÁ%?øÁ...
00010 00000000 00000000 00000000 00000000 -
................
Yours
00000 0073006F 00610070 003A0045 006E0076 - .Ë.?./.ø...á.>.Î
00010 0065006C 006F0070 00650000 00000000 - .Á.%.?.ø.Á.....
Notice how they're identical, except yours has two zeros leading every
two non-zero values, while mine has compressed the leading zeros out.
I would hazard an ignorant guess and say that's the problem. What to
do about it I have no clue.
At the second breakpoint, I get this:
> Eval p_xlname :x 13
00000 3F3F3F3F 3F3F3F00 00000000 00...... - ................
How would you like to proceed?
And thanks, by the way, for the amount of time & effort you've spent
helping me with this. I appreciate it very much.
Rich
[1]i'm EMAILING FOR THE GREATER GOOD
Join me
> Date: Sat, 2 May 2009 12:25:58 +0200
> From: thomas.raddatz@xxxxxxxxxxx
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: HTTPAPI returns a "Host name look up failed"
>
> Hm, I am getting more and more confused. Here are my thoughts:
>
> 1) We should ignore the F11 problem when pressing F11 at different
positions on a variable name. The
> V5R1 debugger seems to have problems with qualified variable names.
With V5R4 I always get the same
> result regardless from the position of the cursor.
>
> 2) The result of your "EVAL p_element :x 64" makes me to assume that
there is something wrong with
> character translation. The first 2 bytes (x'0026') are the length of
"element.path". Then there are 4
> slashes (x'61') with unknown vales (x'3F') in between. Although I
get a length of x'0038' and although
> the number of your x'3F' values does not match the number of
characters on my side, I assume that
> character translation goes wrong.
>
> So what to do?
>
> 1) At first I would add a breakpoint to the following statement:
>
> if (root.namespace); // add breakpoint here!
> CallbackNS( root.userdata
> : rootDepth(root)
> : element.ns
> : element.name
> : elemPath(root: element)
> : p_retval
> : wwAttrAry
> );
> else;
> Callback( root.userdata
> : rootDepth(root)
> : element.name
> : elemPath(root: element)
> : p_retval
> : wwAttrAry
> );
> endif;
> if (p_newval <> *null);
> xdealloc(p_newval);
> endif;
>
> I expect that "element" contains the same values as we already have
seen. Now we know that it is
> not the "MapXmlData" callback that messes up "element".
>
> 2) Now go to the "startElement" procedure and add a breakpoint to
these statements:
>
> // set new name & translate to EBCDIC.
>
> len = %scan(u'0000': localName) - 1;
> len = iconvdyn( len * 2 // add breakpoint here
> : %addr(localName)
> : root.xlate
> : p_xlname );
> newElem.name = %subst(xlname:1:len); // add breakpoint here
>
> When you hit the first breakpoint, look at "len" and "localName".
You should get the following values:
>
> > EVAL len
> LEN = 13
> > EVAL localname
> LOCALNAME = soap:Envelope
> > EVAL localname :x 32
> 00000 0073006F 00610070 003A0045 006E0076 - .Ë.?./.ø...á.>.Î
> 00010 0065006C 006F0070 00650000 00000000 - .Á.%.?.ø.Á......
>
> When you reached the second breakpoint "p_xlname" sould contain the
following value:
>
> > EVAL p_xlname :X 13
> 00000 A2968197 7AC595A5 85939697 85...... - soap:Envelope...
>
> If that is not true, I assume that there is a character translation
problem and that we should try to
> write a simple test program to check that.
>
> If "localname" does not contain the value as shown above, I assume
that something is wrong with eXpat
> and I do not have any idea how to proceed.
>
> The very last option we have is that you put your compiled test
environment (HTTP API and eXpat) into
> a test library, save that library to a save file and send it to me.
I then will try to run your
> programs on our box. The problem is that I have almost no time to
check that within the next two
> weeks. However I will try to do that in the evening. But I cannot
promise that.
>
> Thomas.
>
>
>
> Rich Kitterman schrieb:
> > Thomas,
> >
> > Strange doesn't begin to describe it! Here's what I learned:
> >
> > Using F11 on the element.name variable will yield varying results,
> > depending on where the cursor is positioned. If it's on the
portion
> > containing the word "element", this is displayed:
> >
> > > EVAL
> > element
> > PATH OF ELEMENT
> > =
> >
> > ....5...10...15...20...25...30...35...40...45...50...55...60
> > 1 '//// '
> > 61
> > ' '
> > 121
> > ' '
> > NS OF ELEMENT
> > =
> >
> > ....5...10...15...20...25...30...35...40...45...50...55...60
> > 1
> > ' '
> > 61
> > ' '
> > 121
> > ' '
> > NAME OF ELEMENT
> > =
> >
> > ....5...10...15...20...25...30...35...40...45...50...55...60
> > 1 ' '
> > 61
> > ' '
> > 121
> > ' '
> >
> > VALUE OF ELEMENT = SPP:C9EB2CCBCC0198D0
> > SIZE OF ELEMENT = 24
> > ALLOCSIZE OF ELEMENT = 65536
> > ATTRS OF ELEMENT = SPP:C9EB2CCBCC089C30
> >
> > If I position the cursor on either the "." or "name" I get this:
> > NAME = SPP:C9EB2CCBCC0323A0
> >
> > Positioning at the top of the program following arriving at the
> > breakpoint the first time, and searching for p_element brings me
to
> > the data structure definition, where if I position the cursor
under
> > "element" and press F11, I get "Call stack entry does not exist".
If
> > I try "EVAL element", I get exactly what I described above, with
the
> > various subfields' values as shown.
> >
> > I added the debug_msg() statement, re-created the module and
updated
> > the program, as instructed, and after running the program
> > again, here's what appeared in the debug log:
> >
> > SetError() #13: HTTP/1.1 200 OK
> > recvdoc parms: identity 521
> > header_load_cookies() entered
> > recvdoc(): entered
> > SetError() #0:
> > <?xml version="1.0" encoding="utf-8"?><soap:Envelope
> > xmlns:soap="[1]http://schemas.xmlsoap.org/soap/envelope/"
> > xmlns:xsi="[2]http://www.w3.org/2001/XMLSchema-instance"
> >
xmlns:xsd="[3]http://www.w3.org/2001/XMLSchema"><soap:Body><GetGeoIPRe
> > sponse
> >
xmlns="[4]http://www.webservicex.net"><GetGeoIPResult><ReturnCode>1</R
> > eturnCode><IP>209.131.36.158 </IP><ReturnCodeDetails>Record
> > Found</ReturnCodeDetails><CountryName>UNITED
> >
STATES</CountryName><CountryCode>US</CountryCode></GetGeoIPResult></Ge
> > tGeoIPResponse></soap:Body></soap:Envelope>
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name= u
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > INFO: endElement() - element.name=
> > http_close(): entered
> > The EVAL displaying the hex representation looks like this (and
leads
> > me to believe element is already incorrect) by the first time the
> > breakpoint is reached:
> >
> > > EVAL p_element :x
> > 64
> > 00000 0026613F 3F3F3F3F 3F3F3F3F 613F3F3F -
> > ../........./...
> > 00010 3F3F3F3F 3F3F3F61 3F3F3F3F 3F3F3F3F -
> > ......./........
> > 00020 613F3F3F 3F3F3F3F 00000000 00000000 -
> > /...............
> > 00030 00000000 00000000 00000000 00000000 -
> > ................
> >
> > I checked the compile listing and verified that ELEMENT was
defined
> > as:
> > ELEMENT DS(10304)
> > BASED(P_ELEMENT)
> > .ALLOCSIZE I(10,0)
> >
> > .ATTRS *(16)
> > .NAME A(1024)
> > VARYING
> > .NS A(1024)
> > VARYING
> > .PATH A(8192)
> > VARYING
> > .SIZE I(10,0)
> >
> > .VALUE *(16)
> >
> > So it appears that element is getting messed up before
> > that breakpoint. Should I try a different breakpoint to help
> > determine where it's getting messed up?
> >
> > Thanks,
> >
> > Rich
> >
> > > Subject: RE: HTTPAPI returns a "Host name look up failed"
> > > To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> > > From: thomas.raddatz@xxxxxx
> > > Date: Thu, 30 Apr 2009 09:02:07 +0200
> > >
> > >
> > > Rich,
> > >
> > > Strange things that happen at your side. I wonder if we are on
the
> > right
> > > track. I often experienced that the most strangest problems had
the
> > most
> > > simple solutions. Anyway, I downloaded the compiled version of
eXpat
> > from
> > > Scott's web site and guess what, it works just fine with HTTP
API
> > v1.23. I
> > > did not yet tested it with v1.25beta5 but I do not expect
anything
> > > different with that.
> > >
> > > I do not remember if there was a problem in V5R1 to display
> > variables with
> > > qualified names. Please try the following things:
> > >
> > > a) Try to display the variable using F11 instead of "eval"
> > > b) Since "element" is a variable with a global scope, try to
display
> > it
> > > from where it is defined. Once that you hit the breakpoint, go
to
> > the top
> > > of HTTPXMLR4 and search for "p_element" (f p_element). Then try
to
> > display
> > > "element" and "element.name" from there using "eval" and F11.
> > > c) If nothing helps, add a debug_msg() statement to HTTPXMLR4,
> > compile the
> > > module and update service program HTTPAPIR4. Run GEOIP and look
at
> > the
> > > debug file to see the values of "element.name":
> > >
> > > debug_msg('INFO: endElement() - element.name=' + element.name);
> > > if (p_newval <> *null);
> > > xdealloc(p_newval);
> > > endif;
> > >
> > > Creation commands:
> > > CRTRPGMOD MODULE(LIBHTTP/HTTPXMLR4) DBGVIEW(*LIST)
> > >
> > > UPDSRVPGM SRVPGM(LIBHTTP/HTTPAPIR4) MODULE(LIBHTTP/HTTPXMLR4)
> > >
> > > Or you may try to look at "p_element" when you hit the
breakpoint.
> > "EVAL
> > > p_element :X 64" should at least show you the namespace value.
So we
> > at
> > > least know, that "element" is not completely messed up:
> > >
> > > > EVAL p_element :x 64
> > > 00000 003861A2 9681977A C595A585 93969785 - ../soap:Envelope
> > > 00010 61A29681 977AC296 84A861C7 85A3C785 - /soap:Body/GetGe
> > > 00020 96C9D7D9 85A29796 95A28561 C785A3C7 - oIPResponse/GetG
> > > 00030 8596C9D7 D985A2A4 93A30000 00000000 - eoIPResult......
> > >
> > > You probably should also verify that "element" has been compiled
as
> > > expected. So after having compiled HTTPXMLR4 at option c), look
at
> > the
> > > compiler listing and search for "ELEMENT" in upper cases. You
should
> > get
> > > something similar to this:
> > >
> > > ELEMENT DS(10304)
> > > BASED(P_ELEMENT)
> > > ALLOCSIZE I(10,0)
> > > ATTRS *(16)
> > > NAME A(1024)
> > > VARYING
> > > NS A(1024)
> > > VARYING
> > > PATH A(8192)
> > > VARYING
> > > SIZE I(10,0)
> > > VALUE *(16)
> > >
> > > Info: I dropped the "References" columns to keep things simple.
> > >
> > > Thomas.
> > >
> > >
>
>
References
1. http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------