Am 18.01.2015 um 17:19 schrieb P.R.:
>> Storage for static variables, i.e. variables declared with
>> the STATIC keyword, is "allocated" in the so called static
>> CSECT that becomes part of the object module. Note that
>> this *is* read/write storage, so in PL/I STATIC does not
>> mean constant.
> If it's truly part of a "CSECT" that is part of a load module, then this
> statement is wrong (or needs to be fine-tuned). All z/OS storage is
> read/write if you're in the right key (unless z/OS has page-protected it).
> So if you're trying to say that a non-key-0 program can write into it, in
> z/OS that will depend on the APF authorization of the load library
> concatenation and the reentrancy of the module.
>
>
Even a non-authorized program which is linked RENT can write into its
STATIC CSECT. We did this all the time in our PL/1 modules that are
compiled using the NORENT option (or compiled with old releases of
PL/1, before the RENT option was available).
There are two use cases (at our site) to do that:
a) to store the entry point of modules that are dynamically loaded, so
that only at the first call a LOAD macro is needed ... at the
subsequent calls the entry point is non-zero, so it can be used
immediately
b) to store results of expensive computations (and the arguments, that
leaded to this results), in case that the following call is done with
the same arguments
In the second case, you have to take care that there will be no damage
due to the parallel use of the module from different tasks ... there
are ways to do this. In the first case, you dont have such a problem
... the only damage that can occur is that you do the LOAD too often.
BTW: our PL/1 modules (no DLLs, simple LOAD modules) call each other
using ASSEMBLER interfaces, doing MVS LOAD ... we don't normally use
LE services for that (this is an old technique from the early 1980s).
But it works until today, and the rest is all LE compliant. We use the
new EP PL/1 compilers.
Same goes for C ... no difference at all.
Kind regards
Bernd
|
