[Ftpapi] Problems with http_persist_req in HTTPAPIR4 (after upgrade to version 1.40 ?) # 2

Hello!

(I posted this some time ago without any luck. I try one more time )

We use HTTPAPIR4 http_persist_req with the DELETE method to delete items from a remote database, and it has been working fine for more than a year.

Lately, however, the routine has failed with a ‘Pointer not sent for location referenced’-error.

Job log:

Commitment definition *N not valid for open of GENZAL5.

Commitment definition *N not valid for open of PLSD9L1.

Commitment definition *N not valid for open of PLGD0L1.

Commitment definition *N not valid for open of GENZAL5.

Commitment definition *N not valid for open of PLSD9L1.

Open of member S1SSPECP was changed to SEQONLY(*NO).

File MTPW01P created in library QTEMP.

Member MTPW01P added to file MTPW01P in QTEMP.

Objekt MTPW01P i QTEMP type *FILE ble slettet.

Pointer not set for location referenced.

Funksjonsfeil. MCH3601 uovervåket av HTTPAPIR4 i setningen 0000005558,

instruksjonen X'0000'.

The call to FOSSJK_Sle ended in error (C G D F).

(Line 3 and 4 from the bottom is Norwegian and reads something like ‘Functional error. MCH3601 unmonitored by HTTPAPIR4 in statement …’, and line 6 from the bottom is something like ‘Object MTPW01P in QTEMP type *FILE was deleted’)

This happens only if the item we want to delete is present in the database. If not, we get the ‘404 not found’-response as usual.

Note that the actual delete operation is performed OK, the only problem is that instead of a response indicating success, the job ends with this error message.

After some debugging, I found out that the problem seems to be related to the PESAVEPROC parameter; we pass *null here normally:

statusKode = http_persist_req('DELETE': wPointer : wurl : 0 : *null: *null : 0 : 60 : *null);

I made a dummy procedure and passed that as PESAVEPROC instead:

statusKode = http_persist_req('DELETE': wPointer : wurl : 0 : *null: *null : 0 : 60 : WDummyPointer);

Now I get ‘saveproc: Not all data was written’ in response, which I guess has a reasonable explanation. (We do not need any response other than some way of knowing that the delete was successful)

It seems that this problem occurred after we upgraded LIBHTTP from version 1.33 to 1.40, but I am not 100 % certain. I have tried to find anything about *null value is not valid for the PESAVEPROC parameter anymore, but I havn’t found anything.

Does anyone have any suggestions on how to avoid this problem? (preferably in a more elegant way than my work-around with the Dummy procedure)

Thanks in advance!

Regards,

Ola Lid

IT-consultant

Kjerneløsninger/NICE utvikling

+47 917 48 222

Fremtind Forsikring AS | Vi er eid av SpareBank 1 og DNB

Hammersborggata 2, PB 778 Sentrum, 0106 Oslo