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