Oppolzer - Informatik / Blog


Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

IBM-MAIN - Ändern von statischen Bereichen trotz RENT

Subject:

Re: PL/1 modules linked RENT, compiled NORENT (was: Re: abend S602-0 when in AMODE 64)

From:

Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>

Reply-To:

IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>

Date:

2015.01.19 16:18:00


Am 19.01.2015 um 13:32 schrieb P.R:
>> Even a non-authorized program which is linked RENT
>> can write into its STATIC CSECT.
> But only if the program is not fetched from an APF-authorized
> concatenation (and maybe that's a requirement for PL/I programs with this
> characteristic).
>
> In that case, the program can write into the program itself too.
>
> For the static csect, does PL/I do something to keep track of CSECT
> mappings and obtain storage for the static csect in user-key storage?
> That's the only way that writing into that csect could "overcome" APF
> authorization rules.
>
> P.R.
> z/OS Core Technology Design

I'm talking about simple user programs that are fetched from normal
not APF-authorized libraries. The STATIC CSECT (with compile option
NORENT) is part of the load module, so with normal MVS LOAD, it is
fetched together with the program text, in user-key storage.

I don't really get the problem with this RENT / read only discussion.

Of course, normally a program linked as RENT should not change its
static stroage, but:

even a program that is linked as RENT may in certain circumstances
need to store some information in static storage. Think of a routine
that is establishing a cache memory for a table access that is valid
for ALL parallel running threads or subtasks. Then there should be ONE
cache, and of course, the anchor information for this cache has to be
in static storage, and when establishing the cache or accessing (or
changing) the cache (which resides in dynamic storage, of course), the
anchor has to be written into the static storage.

These cache accesses have to be protected by semaphors etc, of course
(or maschine instructions like compare & swap).

This was present before WSA was invented. If now with new releases of
the OpSys, all modules linked as RENT will be read only, we all are
forced to use WSA even with "classical" languages like PL/1, COBOL and
C (without ++); I don't like this ... for performance reasons. And
this even will not help, because WSA exists once for every parallel
task ... if I want ONE cache for all parallel tasks, as in my example,
I have to find another solution. With "true static", I knew where to
put the anchor of that cache.

Kind regards

Bernd

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie