Re: comm_connect call comming to grief - ever seen this condition?

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>

Hi Peter,

> Running a version of EXAMPLE4 of Scott's HTTPAPI (just downloaded), the
> comm_connect call at line 3266 in proc http_persist_open in Srvgm
> HTTPAPIR4 comes back with *ON, so a *NULL pointer is returned.

Actually, when comm_Connect() returns *ON, it means that the connection 
was made successfully. It shouldn't be returning *NULL in that case, it 
should be returning a pointer to a communications session.

Here's the code from HTTP_persist_open():

     c                   if        comm_Connect( wwComm
     c                                         : p_addr
     c                                         : wwTimeout
     c                                         ) = *OFF
     c                   return    *NULL
     c                   endif

     c                   return    wwComm

See what I'm saying?  When comm_Connect() returns *OFF, you get *NULL. 
Otherwise, you can wwComm (which is a pointer to a communications 
driver).


> Anyone know what this means: something not configured, or not started in
> the QHTTPSVR sbs - or what? Any help much appreciated,

There's no relationship whatsoever between HTTPAPI and the QHTTPSVR 
subsystem.

HTTPAPI provides a subprocedure called HTTP_error() that you can call to 
find out what the last error that occurred was.  In EXAMPLE4, the code 
looks like this:

c                   eval      rc=http_url_post(
c                                 'https://wwwcie.ups.com/ups.app'+
c                                 '/xml/Track':
c                                  %addr(data): %len(%trimr(data)):
c                                  '/httptest.html')
c                   if        rc <> 1
c                   eval      msg = http_error
c                   dsply                   msg
c                   return
c                   endif

The idea is, if it's successful, HTTP_url_post() will return the number 1. 
In any other case an error has occurred, so you call http_error() to get 
the error message.

The first place to look is to check what that error message says.

If that doesn't provide enough information, HTTPAPI has a logging feature 
to assist with troubleshooting problems.  How that feature is enabled 
depends on the version of HTTPAPI that you're running. I'm assuming that 
you're running version 1.10, since you're new to the mailing list and 
don't know about the beta versions yet :)

In version 1.10, you enable the debugging log file by editing the CONFIG_H 
source member. At the bottom, you need /define DEBUG to be set, and the 
debug file to be set to a good location (by default, I think it's 
/tmp/httpapi_debug.txt).

You'll need to re-compile HTTPAPI to enable those changes once you've 
changed the CONFIG_H member (you can do that by re-running the INSTALL 
program)

In version 1.11 (currently only beta versions exist of this) you can 
enable debugging at run-time without recompiling it.

Once the debug file has been enabled, you can re-run your program, and 
it'll put lots of debugging info in that log file. If that info doesn't 
help you figure out the problem, please post your debug file to the 
mailing list.

Thanks

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------