I misspoke

["Peter Myers" <pjmyers@xxxxxxxxxxxxx>]

Sender: "Peter Myers" <pjmyers@xxxxxxxxxxxxx>

Dear Scott,

I'm sorry, I misspoke in the email, but my debugging session was
accurate. This function returned *OFF, not *ON as I incorrectly said in
the post.

Therefore a *NULL value was returned, and the code in the caller
dictated that efforts come to a halt. There was no specific error msg,
but I'm telling you this is where things broke down.

I will try to grasp what you've said below (instructions for creating
the log), but I've not much to add - this is where the code essentially
"dies" in my case.

Thanks,
Peter

-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Monday, May 02, 2005 8:35 PM
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: comm_connect call comming to grief - ever seen this
condition?

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


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