Oppolzer - Informatik / Blog

I would like to add:

the RETURN facility in PL/1 is somehow different from C and maybe other
languages.

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
COBOL.

(maybe there are options in PL/1 to change this behaviour, but I didn't want to
use them so far)

Kind regards

Bernd




Am 24.02.2014 09:17, schrieb Bernd Oppolzer:
> First:
>
> 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.
>
> Then:
>
> 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.
>
> Kind regards
>
> Bernd
>
>
>
>
> 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
>>            end-call
>>
>> where all -ptr are defined as USAGE POINTER and RE is defined as:
>> 01 RE                        USAGE POINTER VALUE NULL.
>>
>>
>