On 19 November 2015 at 10:14, Gary Weinhold <weinh...@dkl.com> wrote: > But you have a valid concern about vendors' assembler code. We should be > asked whether we know about this.
When these changes were first brought up by IBM quite a few years ago now, every even marginally competent ISV reviewed its use of GETMAINed storage, and made corrections if necessary. In my view this was a good exercise whether or not changes were needed. > Note that it says that the behaviour is > not changed, which means this exposure has existed before z/OS 1.10. The > availability of the CHECKZERO option means that users of GETMAIN/STORAGE may > not always have to zero the storage they obtained to ensure that it is > initialized to zeroes. While there was no change to the documented/guaranteed behaviour of GETMAIN, what changed as a result of the under-the-covers algorithm changes was the customary behaviour under certain circumstances. Some programs doubtless relied -- implicitly or explicitly -- on certain storage being zeroed even though the GETMAIN rules never suggested that there was any such guaranty. What also changed because of the under-the-covers algorithm changes, and was discussed at some length on this list and elsewhere, is the way fragmentation may occur. Overall it seems that fragmentation is less likely with the new algorithms, but there are doubtless cases where it increases, and therefore certain jobs will require more storage than they did under the old regime. 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. Tony H.
