Oppolzer - Informatik / Blog

I did some "book reading" (language reference for the EP PL/1 compiler V4.4).

If you define your external entry with option ASSEMBLER or COBOL (C doesn't
exist), you will get the effect that

"the PLIRETV() value is taken as the RETURN value of the procedure"

in both cases.

PLIRETV () is BIN FIXED (31), not BIN FIXED (15) in the meantime,

so you could in fact define the C function as ASSEMBLER function (in PL/1),
giving a BIN FIXED (31) result, and then convert the BIN FIXED (31) result
to a pointer (which it really is).

This is not very nice, but it should work, IMHO.

No need for a wrapper function, in this case.

Kind regards

Bernd



Am 24.02.2014 09:30, schrieb Bernd Oppolzer:
> 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.
>>>
>>>
>>
>>