[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
-----------------------------------------------------------------------