You don't have to "change" your open source library, you only code a small
wrapper function on top of it to make it easier to call it from PL/1.
There are two issues with this function. The first one are the call by value
parms, which can be easily resolved using the BYVALUE keyword of newer PL/1
compilers. The second one is the handling of the C function result.
Historically, the function results of C correspond with the PLIRETV () return
codes of PL/1, and they are limited to BIN FIXED (15) values. So we have an
issue here. I don't know if we have newer compiler features to cope with that. I
simply don't care, because at our site we always build wrapper functions to
build a PL/1 friendly interface to such functions. This is no big deal and can
be done within hours. We did this since the early 1990s.
This way, I don't even have inform the PL/1 compiler that the external function
is written in C. The C wrapper function presents a PL/1 compatible interface to
PL/1, and everything is fine.
We did this in the past even to get rid of the by value parms. All our PL/1
friendly interfaces only had (from a C perspective) int function results (that
is, return codes, suitable for PLIRETV ()), and pointers as parameters, suitable
for BYADDR parms.
If we could not convince our external partners providing C functions to provide
such interfaces to their software, we built wrapper functions ...
For example: I have a powerful XML parser (and generator) written in ANSI C, and
to make it callable from PL/1, I have a wrapper function around it that allows
us to call its different functions (xmlp_open, xml_parser, xmlp_close, ...)
using one function callable from PL/1 - with different function codes.
If you want to know more about the details, contact me offline.
Am 24.02.2014 03:36, schrieb Z.A.:
> Bernd Oppolzer wrote:
> >of course, if you want for example all parameters to be
> >passed by value - just to have the same look and feel for
> >all of them - this is perfectly simple.
> >To have all of them passed by reference, you can do this, too,
> >if the wrapper function takes care of that.
> The PCRE is an open source library (compile8 is only one of the API calls)
> and we are bound by its definitions and call conventions. Calls from COBOL
> do not have any issue and the call below works:
> call 'COMPILE8' using by value pcrews-pattern-ptr
> BY VALUE 0
> BY reference pcrews-error-ptr
> BY reference pcrews-erroffset
> BY VALUE pcrews-null-ptr
> RETURNING RE
> where all -ptr are defined as USAGE POINTER and RE is defined as:
> 01 RE USAGE POINTER VALUE NULL.