I would like to add:
the RETURN facility in PL/1 is somehow different from C and maybe other
In C, the return values are limited to values that fit into a register, AFAIK.
So the pointer, that is returned in your case, is technically returned (at the
mainframe) in the same way as the return code, that is, Register 15.
In PL/1, if you use RETURN, it is implemented as an additional parameter,
following the other parameters. If you RETURN a value in PL/1, you can still use
PLIRETC / PLIRETV, because these are different techniques.
X = FUNC (A,B C);
in the PL/1 mainframe implementation is the same as
CALL FUNC (A,B,C,X)
leaving room for using PLIRETC / PLIRETV in both cases.
This is not compatible with C function results.
Your COBOL coding, which obviously works, shows that things must be different in
(maybe there are options in PL/1 to change this behaviour, but I didn't want to
use them so far)
Am 24.02.2014 09:17, schrieb Bernd Oppolzer:
> 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
> 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.
> Kind regards
> 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.