On Mon, Jan 19, 2015 at 9:18 AM, Bernd Oppolzer <[email protected]> wrote:
> Am 19.01.2015 um 13:32 schrieb Peter Relson: > >> 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. >> >> Peter Relson >> 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. > I have seen this sort of thing done. A type 2 SVC (r/w nucleus) did something like (from personal memory): L R5,INTERNAL_GLOBAL_POINTER LTR R5,R5 BNZ AROUND ALREADY INITIALIZED! GETMAIN R,LV=SOME_LENGTH,SP=??? CS R5,R1,INTERNAL_GLOBAL_POINTER BE AROUND POINTER UPDATED * SOMEBODY GOT IN FRONT OF ME, RELEASE WORK AREA FREEMAIN R,LV=SOME_LENGTH,A=(1) AROUND DS 0H > > 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. > I now use a global NAME/TOKEN to store the address of my global (system wide) work areas. For an address space, there is an address space level NAME/TOKEN, and a 3rd level for TCB level NAME/TOKEN ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A9B0/15.0 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2A6A1/18.0 Before use of NAME/TOKEN, I recall a "perversion" of ENQ control blocks where it had a NODE similar to: PRODUCT.<ASID IN HEX>.<ADDRESS IN HEX>. The application code would scan the ENQ control blocks looking for a match to the prefix: PRODUCT.<ASID IN HEX> (or just PRODUCT for a system level), and then take the <ADDRESS IN HEX> portion as the printable encoding of the memory pointer. > > Kind regards > > Bernd > > -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
