Re: (cross-posted from Scott's HTTPAPI list) I need the SSL version [of HTTPAPIR4] to be backward-compatible with programs expecting the non-SSL version.

The only thing that adding a *PRV list can do is to ensure that the signatures will match. However, it will not change the slot/procedure association. Therefore unless the procedures in the new version have the same slot associations you may end up calling the wrong procedure. That might account for an error such as you are seeing. Without seeing both lists I can't tell.

Just to illustrate though.

Say the current version of the srvpgm has four procedures and the binder language sets them up like this:

A, B, C and D.

The pointers in the srvpgm will occupy slots 1 (A) through 4 (D).

Now suppose that the version you are using had procedures A, B and D and that you have got round the signature issue by coding them in that order as *PRV.

Signature issue is solved - but your program will reference A as in slot 1 - OK so far. B in slot 2 - still OK. And D in slot 3. Problem - D is in slot 4. Your program instead of calling D has called C.

*PRV then is only any good if any new procedures are added to the end of the list.

Simply rebinding your existing programs will be a much better (and safer) solution.


On Dec 28, 2011, at 11:50 AM, midrange-l-request@xxxxxxxxxxxx wrote:

We already have programs that depend on the non-SSL version of
HTTPAPIR4, while the new programs I'm working on (calling Google web
services) need the SSL version.

Toward this end, and following the "Binder Language" section of the ILE
Concepts book, I tried adding the STRPGMEXP block from the HTTPAPI1
member to the HTTPAPI2 member [of LIBHTTP/QSRVSRC], as a *PRV STRPGMEXP
block; I recompiled, and when the program expecting the non-SSL version
tried to use it, it got an MCH3601 at a call to "http_url_get_raw."

Any clue what could have gone wrong?

Jon Paris

www.partner400.com
www.SystemiDeveloper.com