Re: Maintaining Service Program signatures

On 2/19/13 12:44 PM, Scott Mildenberger wrote:

Or, there have been many discussions here that are in the archives.
Just have a hard-coded signature that never changes. ALWAYS add new
procedures to the end of the binder source, NEVER insert between
existing ones.

What he said.

We have had to create a fork of Scott Klement's HTTPAPI, to (as I
recall) move all the SSL calls to the end, and make the non-SSL portion
match the non-SSL version, and we set it up in such a way that any
caller looking for a non-SSL HTTPAPI would work unaltered, but anything
looking for a standard (rather than customized) SSL HTTPAPI would throw
a signature violation. You can set things up so that any old signatures
your service program supports will still work, but anything it doesn't
support will be rejected. For example, our customized HTTPAPIR4 has a
signature of "HTTPAPISSLWINTOU," but also supports the standard non-SSL
signature of "HTTPAPI001." It does *not* support the standard SSL
HTTPAPI signature of "HTTPAPI002," however, and that is by design, as
the exports are in the wrong sequence for that signature.

--
JHHL

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.