http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.e0zm100/chbeget.htm
SYS1.PARMLIB(DIAGxx) value VSM USEZOSV1R9RULES(NO) is old allocation method, YES is new allocation method. Yes is default for z/OS 1.9 only. Quote: Enable changed GETMAIN and STORAGE OBTAIN behavior z/OS V1R11.0 Migration - All supported migration paths z/OS V1R11.0 GA22-7499-16 Description: z/OS V1R10 provides a new statement in parmlib member DIAGxx that allows an installation to choose the allocation method used by the GETMAIN and STORAGE OBTAIN macros to obtain user-region private area subpools. The new DIAGxx statement (introduced by APAR OA27291) is "VSM USEZOSV1R9RULES(YES|NO)". In z/OS V1R10 |(and later), the default setting is YES, which keeps the GETMAIN and STORAGE OBTAIN behavior the same as in previous releases. Some applications, such as DB2, have experienced performance problems because descriptor queue element (DQE) and free queue element (FQE) chains have become extremely long for certain user-region private area subpools. These applications can benefit from the new z/OS V1R10 |(and later) GETMAIN and STORAGE OBTAIN behavior, which merges adjacent DQEs, when possible, and thus results in shorter DQE chains. You can enable the new behavior by specifying "VSM USEZOSV1R9RULES(NO)". The new behavior could give the perception in some cases that storage is not being cleared to zero as it previously was. Storage is cleared by the system no differently in z/OS V1R10 |and later than it was previously. The reason for the apparent difference is because storage requests can now be satisfied partly from an FQE on a page adjacent to a newly obtained DQE. If the storage represented by that FQE had previously been obtained and then freed, the residual data remains. Programs that assume that storage will be cleared by the system even for cases where there is no guarantee of it could be affected. Depending on the contents of the uncleared storage and how it is used, this might result in ABEND0Cx, overlay of storage, or other problems. (See APAR OA27291 for examples and more information.) Restoring to the old behavior might be necessary if programs in the installation are making unwarranted assumptions about internal VSM behavior. In this case, specify "VSM USEZOSV1R9RULES(YES)" until the applications causing problems can be corrected. On Sun, Oct 30, 2011 at 6:15 PM, glen herrmannsfeldt <[email protected]> wrote: > Continuing, DC generates object code TXT data, and DS doesn't. > That requires a new card for each change. If you write: > > X CSECT > DC X'1' > DS X > DC X'1' > DS X > DC X'1' > DS X > DC X'1' > DS X > DC X'1' > DS X > DC X'1' > DS X > DC X'1' > END > > Then the assembler should generate seven records (cards) for the > object program, with only one byte of data on each of them. > > When the linkage editor processes this, it can either write out > separate records for each, or 'fill in the holes' and combine > it all into one record. That latter is more efficient, and, as > I understand it, is what the linkage editor does and always did. > (or maybe not always.) The holes can be filled with a specific > value, or whatever was left in the buffer. > > When loaded by program fetch, each load module record is loaded > at the appropriate address, possibly with holes between the records. > The holes between load module records at program fetch can keep what > was previously stored there, possibly from a previous job, or > a previous step in the same job, or cleared prior to reading in > the load module. > > Has this changed from OS/360 version 1 up until current z/OS? > > -- glen > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
