Re: Class Notes for a PL/I Course.

One more error:

"It is possible to pass structures, but then you will get real trouble
with structure aggregates."

should read:

"It is possible to pass structures, but then you will get real trouble
with structure DESCRIPTORS."

Sorry again. Time for a little afternoon rest ...

Kind regards

Bernd



Am 03.10.2019 um 13:19 schrieb Bernd Oppolzer:
>
> One minor error:
>
> "that is, only parameters are passed."
>
> should read:
>
> "that is, only POINTERS are passed."
>
> Sorry
>
> Bernd
>
>
> Am 03.10.2019 um 13:16 schrieb Bernd Oppolzer:
>> Am 03.10.2019 um 12:42 schrieb Giuseppe Vitillaro 
>> giuseppe-yuD/ahkh7LvrZ44/[email protected] [H390-MVS]:
>>>
>>> On Thu, 3 Oct 2019, Bernd Oppolzer berndoppolzer-/[email protected] 
>>> [H390-MVS] wrote:
>>> >
>>> > Kind regards
>>> >
>>>
>>> I guess declaring this way a variable in the main program:
>>>
>>> DECLARE ZAZA CHARACTER(10) STATIC EXTERNAL INITIAL ( 'GIGIO' );
>>>
>>> and using it in an external procedure in this way:
>>>
>>> ZZ: PROCEDURE;
>>> DECLARE ZAZA CHARACTER(10) EXTERNAL;
>>> PUT FILE(SYSPRINT) SKIP EDIT ('ZAZA=', ZAZA ) (2(A));
>>> RETURN;
>>> END ZZ;
>>>
>>> it is the best which can be done in PL/I(F) to get something
>>> which looks like a global C variable?
>>>
>>
>> The short answer is: yes, this is the best.
>>
>> The long answer is: this does not really help you, if you want to
>> do some sort of dynamic linking, because you need the linker to
>> resolve those external references.
>>
>> BTW: STATIC in the main program is not needed or even forbidded,
>> because EXTERNAL variables are STATIC by default.
>>
>>
>>>
>>> Another thing I'm looking for is something like
>>> the C typedef syntax.
>>>
>>> The "LIKE" syntax looks to do something similar,
>>> but for an already "allocated" variable, if
>>> the variable is not actually a pointer.
>>>
>>> Anything better can be done with PL/I (F)?
>>>
>>> Peppe.
>>>
>>>
>>
>> This is somehow related to the question above.
>>
>> If you want parameters to be passed between external functions,
>> they may be structures - in the general case.
>>
>> The C way to do this would be
>>
>> - have a typedef of the struct in an include file
>> - then use this include file on both sides
>> - pass pointers of this struct between caller and called function
>>
>> This way the called function can read and write values from and
>> to the parameter structure.
>>
>> In traditional PL/1, there is no typedef. There is simply no concept
>> of type. See the funny assignment of structures (called aggregates),
>> where it is only needed that the layout of the structures are
>> congruent in a certain way, but the types of the components may differ.
>>
>> Or the second variant: BY NAME.
>>
>> This is all very different from what other languages do.
>>
>> So what is done "in real word" is often the following:
>>
>> we use %INCLUDE files, too. This works in PL/1, even if you don't
>> use the preprocessor (which is another very interesting topic;
>> the PL/1 preprocessor is much more powerful than the C macro processor,
>> for example).
>>
>> in these %INCLUDE files, we define PL/1 structures (or aggregates)
>> without the structure header, that is, without the DCL and the level 1
>> definition. Only level 3 or 5 ...
>>
>> these structure bodies are used at both sides (caller and callee).
>>
>> But the caller declares:
>>
>> DCL 1 PARM_STRUCT AUTO,
>> %INCLUDE (PARMINC);;
>>
>> and the callee declares:
>>
>> DCL 1 PARM_STRUCT BASED (PARM_PTR),
>> %INCLUDE (PARMINC);;
>>
>> and the call looks like this:
>>
>> CALL CALLEE (ADDR (PARM_STRUCT));
>>
>> that is, only parameters are passed.
>>
>> It is possible to pass structures, but then you will get real trouble
>> with structure aggregates.
>>
>> Passing pointers to structures will work well, when calling other
>> languages, too. There will be some issues with component alignment
>> (the PL/1 methods differ from that of other languages), but that
>> can be solved.
>>
>> This is not typedef, but it works a little bit like typedef :-)
>> == COBOL copybooks :-)
>>
>> HTH,
>> kind regards
>>
>> Bernd
>>
>>