On 7/3/24 12:43 PM, Scott Klement wrote:
If you want me to look into it, I need some way to reproduce the problem
on my own machine -- this is important, because it gives me a place to
do deep debugging. Do you have a code sample that I can run that will do
that?
I think I'll hold off on setting up that sort of thing, at least this
week, since you'd need to have a Google Geocoding API key, and you might
also need a V6 box with identical PTF installation status, and this
particular nonstandard version of HTTPAPI.
***
Since my last email on the subject, I was able to account for the
difference in the length of the debugging trace.
The first time I call my application, I get 208 lines, starting with this:
HTTPAPI Ver 1.24 released 2012-01-23
OS/400 Ver V6R1M0
New iconv() objects set, PostRem=819. PostLoc=0. ProtRem=819. ProtLoc=0
http_persist_open(): entered
. . . and ending with what I reported for successful calls in my
previous post.
The second time I call my application, I get 207 lines. The "New iconv()
objects set, PostRem=819." line is not present, but the "successful"
ending is.
The third time, I get the same 202 lines as before, no "New iconv()"
line near the top, and ending at the "recvdoc parms" line.
If I do it a fourth time, it's back to the 208-line version.
*****
While I was doing this, I had the debugger active, and when the
exception was thrown, the debugger jumped to the source of the
HTTPUTILR4 module, with an unmonitored exception, giving me:
D xdealloc PI
D ptr *
/if defined(TERASPACE)
/else
C dealloc ptr
/endif
C eval ptr = *null
P E
Looking at the job's call stack from another terminal session, I see:
Program GEOLOOKUP:
_QRNP_PEP_GEOLOOKUP
3505 GEOLOOKUP
3636 GEOCODE
Service Program HTTPAPIR4:
5712 HTTP_URL_GET_RAW
6403 HTTP_PERSIST_GET
6719 HTTP_PERSIST_REQ
4179 DO_OPER
6916 PARSE_RESP_CHAIN
3738 HEADER_PARSE
3807 HEADER_CLEAN
4120 XDEALLOC
Does any of this tell us anything we don't already know?
--
JHHL
midrange.com
