I implemented the VSM changes in z/OS 1.10. The original implementation
used the new behavior by default, with an undocumented option in DIAGxx to allow a customer (under the direction of IBM support) to temporarily revert to the old behavior to bypass a latent bug in some application program or other product while waiting for a fix. One of the z/OS 1.10 ESP customers hit a latent bug in an authorized key 0 product, and the product ended up overlaying something important and crashing the system. The ESP customer was very insistent that we change the implementation to default to old behavior, with a documented option in DIAGxx to request new behavior. We (development) did not think this was the best thing to do, but we also wanted to avoid the scenario of an ESP customer giving a Share presentation about a bad z/OS 1.10 migration experience, and IBM not meeting their requirements, so we created USEZOSV1R9RULES in an APAR. The impetus for the item was very bad performance when DB2 was opening a large number of data sets at startup (I think at the time, it was taking something like 45 minutes to open 100,000 data sets), and a lot of that was due to very long DQE/FQE chains due to fragmentation caused by Getmain/Freemain activity in OPEN processing. Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Discussion List <[email protected]> wrote on 10/27/2017 11:36:02 AM: > From: Lizette Koehler <[email protected]> > To: [email protected] > Date: 10/27/2017 12:41 PM > Subject: Question on some z/OS Tuning Parms USEZOSV1R9RULES and MEMDSENQMGT > Sent by: IBM Mainframe Discussion List <[email protected]> > > Dear List - > > I have been reviewing some parms that have been around in z/OS for a few > years/decades? > > USEZOSV1R9RULES > > 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 applicationswith long > DQE/FQE chains for user-region private area subpools. > > To Display: D DIAG > > MEMDSENQMGT > > Allocation enhancement - MEMDSENQMGMT (Memory-based data set ENQ management) > - ENQs managed in private storage instead of SWA blocks. Job will be > non-restartable. > - Enable via parmlib member or MVS command: > . ALLOCxx: SYSTEM MEMDSENQMGMT(ENABLE) > . SETALLOC SYSTEM,MEMDSENQMGMT=ENABLE > - Exploit with DB2 APAR PM17542 (closed September 2010) > > To display: D ALLOC,OPTIONS > > I was wondering two things > > 1) How many are using the new algorithms these two parms brought in? > 2) When you changed to the new functions, did you see any issues? > Any products > that need TLC? > > > Are there any other that might also be helpful? > > > Thank you > > > Lizette Koehler > statistics: A precise and logical method for stating a half-truth inaccurately > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
