My job is not to develop but I have to maintain a program that does not work.
Don't be too hard on me because my technical level is far from that of an expert . I explain my problem.
Purpose of the program: connection to a remote server to retrieve stock data.
Note that the two tests described below are executed from 2 different iSeries but the connection to retrieve the data is made on the same remote server. ach iSeries is in version V7R3
When this program is run on our server, everything works correctly (duration between 30 and 40 seconds).
When this program is executed on our client's server, it is interrupted after a few seconds. the program started to recover data but very little.
HTTPAPI_Version is 1.39
You will find in attachments: the program source code, the two logs
File named “Log_http_client.txt” corresponds to the log produced on our client's iSeries. At the end, there is a return code get_chunk_size returned -1
File named “Log_http_our server.txt” corresponds to the log produced on our iSeries.
I tried to contact IBM support and I sent them a trace (TRCCNN) and the logs but they found nothing and advised me to come here on this forum.
That's a pretty old version - I believe the current version is 1.49. So first advice is to update HTTPAPI.
P.S. Might I also suggest using a regular zip file. My Mac thinks rar files are videos and I haven't the time to search for a way to unzip your source.
the 'ee7' is being sent by the server to indicate the length of the next chunk of data. Hex ee7 is the same as decimal 3815 -- so HTTPAPI's "get_chunk_size" routine has received 3815 as the length, and then it calls comm_blockread to read that data.
After all chunks of data are received, you can see this:
1G
get_chunk_size(): entered
get_chunk_size returned -1
This is telling HTTPAPI that the chunk size is 1G -- however, 1G isn't a valid hex number, so get_chunk_size can't interpret it... that's why it's returning -1 to indicate an error.
so the question is, why us "1G" being returned by the server??
eric@negsys wrote: ↑Fri Sep 15, 2023 1:46 pm
@Klement, where do you find the value 1G? I can't find it using Ctrl+F
[SNIP OUT IRRELEVANT PARTS]
get_chunk_size(): entered
get_chunk_size returned -1
http_close(): entered
lol... I just grabbed your logs again, and I agree -- there's no 1G. I must've fat-fingered that into the log earlier... sorry about that.
The -1 means it received a network error of some sort reading the length of the chunk size.
In your code, you have this, which looks like it's probably where the problem is occurring:
173 221011 c eval rc = http_url_get( %trimr(URL0): REPAPI)
174 221011 *
175 221011 c if rc <> 1
176 221108 c move 'E' cret$$
177 221011 c callp http_comp(http_error)
178 221108 c goto finstk
179 221011 c endif
Notice that on line 177, if the rc is -1, this will call http_error() to get the error that occurred, and then call http_comp() to write the error as a completion message. Can you tell us what that message says?
We have no joblog and nothing special in the log session as you can see below.
Please how can I have a joblog with a lot of detail ?
3500 - CALL PGM(IM3STKG0) /* La commande CALL contient des
paramètres */
Ouverture du membre IFDSGP00 changée en SEQONLY(*NO).
Ouverture du membre IFESGP00 changée en SEQONLY(*NO).
HTTP/1.1 200 OK
3900 - SNDDST TYPE(*LMSG)
TOINTNET(('synchronisation@vital-concept.com'))
DSTD('Alerte-IM3-Contrôle de stock') MSG('VIT - ALERTE - INFOR M3 CTL
STK IMPOSSIBLE - IM3STKP0') LONGMSG('VIT - ALERTE - INFOR M3 CTL STK
IMPOSSIBLE - IM3STKP0')
La distribution a été effectuée.
13200 - DLTOVR FILE(*ALL)
Aucune substitution au niveau indiqué.
eric@negsys wrote: ↑Tue Sep 26, 2023 1:33 pm
We have no joblog and nothing special in the log session as you can see below.
Please how can I have a joblog with a lot of detail ?
I already see all of the details in your message, so I don't need a more detailed job log.
But, for future reference, to ensure you have full details in the job log, I'd recommend setting your job settings like this (many shops have this as the default, so yours may already be this way.) Do this before running HTTPAPI:
As you can see, it isn't helpful. It just says that the request was successful... not very useful.
So what we are seeing is a problem I've never seen before, and HTTPAPI isn't generating any helpful diagnostics. In order to help you further, I would need a program that I can load/run on my system that I can use to reproduce the problem. It's important that it run on my system, and that it reproduce the exact same problem, because I'm going to have to do in-depth debugging to understand what is happening.
. I explain my problem.