If you add BNDRY=PAGE to every obtain regardless of size you likely waste storage. VSM would not be able to satisfy multiple requests from the same page, for example. Wasting storage can translate to worse performance in a lot of ways.
I seem to recall that MVCLE is not a good performance choice in general, so should be avoided unless there is reason to think that the needed length could exceed 16M. That recollection might be wrong. Your thought process behind adding BNDRY=PAGE seems somewhat flawed. I'm not sure exactly what you're referring to with "ADM" (since in at least some cases ADM refers to devices, not simply storage, and z/Architecture does not include the asynchronous data mover of ESA/390). If you are manipulating storage via MVCL, the main machine optimization for MVCL involves full pages on a full page boundary so would never come into play. If it's exactly a page, you ought to determine whether you're going to reference the target soon or not, and consider using XC's/MVC's if you are, since one of the MVCL optimization avoids bringing the storage into L1 cache. If your storage exceeds a page, then in most cases you'll land with a full page on a page boundary being part of the area (whether at the beginning or the end), so the number of full pages on page boundary in your area might not depend on your use of BNDRY=PAGE. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
