On 2015-11-19, at 11:03, Elardus Engelbrecht wrote: > Tony Harminc wrote: > >> One slighly related point: It has been the case from day 1 of MVS (OS/VS2 >> R2) that even though GETMAIN can give out non-zeroed storage, that storage >> will never contain data left over from another address space, or from a >> fetch protected subpool in the current or common space. This would be a >> violation of the MVS statement of system integrity, and if found would be >> fixed very quickly. > > As an Assembler programmer I know it is very true, but where is that > documented these days? Just give me a link, book name or search argument so I > can research my Principle of Operations, Bookmanager shelves, IBM Knowledge > Centre, etc. > I suspect it's implicit. Does the SoI not guarantee that no user's data will ever be disclosed to another user? Doesn't that cover this?
On 2015-11-19, at 09:35, Tom Marchant wrote: > ... > APAR OA27291 describes the change in GETMAIN that was introduced in > z/OS 2.1. It results in better performance of GETMAIN. A side effect is that > is > that there is somewhat more chance that a request will be satisfied from a > location that had been previously obtained and then freed. > Is it "more chance", or simply that the hazard is shifted to a different sequence of GETMAINs? Why does the option for "dirty" GETMAIN (I forget the correct name) remain undocumented, despite its value for testing? Why is that option system-wide rather than being available with JOB scope (option on the JOB statement) or job step scope (option on the EXEC statment)? I'd use it for testing if it were available to me. -- gil
