Rich,I think that we reached a point at which Scott has to jump in. Right now I frankly do not have any idea why my eXpat returns a Unicode(?) value while your eXpat seems to return an Ascii value. However that is why you get garbage in MapXmlData: iconvdyn() gets Ascii data instead of an Unicode data and converts it to Ebcdic. Obviously that cannot work.
Scott, do you have an idea why Rich's eXpat passes Ascii data to HTTP API? Rich: I cannot help you with that problem next week because I will not be in the office. Thomas. Rich Kitterman schrieb:
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
-----------------------------------------------------------------------
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
----------------------------------------------------------------------- This is the FTPAPI mailing list. To unsubscribe, please go to: http://www.scottklement.com/mailman/listinfo/ftpapi -----------------------------------------------------------------------