http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IEA2E2B0/31.6 <quote> | *VSM* *USEZOSV1R9RULES(NO|YES)* | YES causes GETMAIN and STORAGE OBTAIN behavior to be unchanged from | its historic behavior. NO causes GETMAIN and STORAGE OBTAIN behavior | for user-region private area subpools that are both below and above | the line to be implemented. Thus DQEs can be merged where possible. | The default is YES to provide a seamless migration. However, IBM | recommends that you specify USEZOSV1R9RULES(NO) to obtain a | performance benefit for applications with long DQE/FQE chains for | user-region private area subpools. </quote>
On Mon, Feb 24, 2014 at 11:46 AM, Chase, John <[email protected]> wrote: > > -----Original Message----- > > From: IBM Mainframe Discussion List On Behalf Of Jim Mulder > > > > > We'd still like to know why loading the program from a PDSE apparently > > > changed how (and more importantly, where) the system passed the PARM= > > > string. > > > > PDSEs are 4K page oriented, so when loaded, they are generally going > to start at a 4K boundary. > > When loading from a PDS, fetch processing simply does a GETMAIN for the > storage. If the size of the > > module is at least 2 pages, but not a page multiple, the Getmained > storage (and thus the load module) > > will be aligned to end on a 4K boundary if D DIAG shows VSM > USEZOSV1R9RULES(YES) or it will be aligned > > to start on a 4K boundary if you have VSM USEZOSV1R9RULES(NO) > > > > Your results suggest that you are using the default of VSM > USEZOSV1R9RULES(YES). > > Correct. So that suggests that, when the program was loaded from a PDS, > it got loaded at whatever doubleword-aligned address the GETMAIN happened > to acquire, which was not necessarily on a page boundary. In fact, the > load module is more than two pages in length but less than three pages, so > it appears it was "just lucky" that the "insertion" of the flag byte at the > end of the PARM string didn't cause (even) a S0C4. > > I think we discussed changing to VSM USEZOSV1R9RULES(NO) when we migrated > from 1.9 to 1.11, but apparently it "got lost in the shuffle". And now > we're preparing for z/OS 2.1 (or its follow-on), from 1.13. > > > I would expect the location of the PARM= string to be the same, > regardless of PDS vs. PDSE. However, > > I would expect that changing the setting for VSM USEZOSV1R9RULES will > change the location of the PARM= > > string. > > I think I've lost the link I had to documentation on USEZOSV1R9RULES; can > you provide a current one, please? > > Thanks, > > -jc- > > ********************************************************************** > Information contained in this e-mail message and in any attachments > thereto is confidential. If you are not the intended recipient, please > destroy this message, delete any copies held on your systems, notify the > sender immediately, and refrain from using or disclosing all or any part of > its content to any other person. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
