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.

Jon Paris wrote:

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.

. . .

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.

Wonderful. That, at least, provides a "why" to Scott's answer on the HTTPAPI list.

It also means that the lousy engineering is in the basic architecture of the ILE *SRVPGM: "call-by-position" instead of "call-by-name."

By contrast, the OPM "pseudo-*SRVPGMs" (or maybe "proto-*SRVPGMs"?) I've worked on, both in QuestView and in Wintouch, use a protocol that passes an "opcode" parameter to indicate the desired function, making them the next best thing to call-by-name.

Even if there had been some overriding reason for call-by-position instead of call-by-name, given that the OS is famous for fully transparent self-re-encapsulation of programs through the CISC-RISC and V5-V6 transitions, I would expect any sane implementation of *PRV to provide some sort of automatic conversion.

--
JHHL