The only thing that has changed is the wording, before 2.3 (i.e. 2.2) it stated:
The IEASYSxx LFAREA parameter specifies the amount of real storage to be made available for 1 MB and 2 GB large pages. after 2.3 (i.e. 2.3 and 2.4) it now says: The IEASYSxx LFAREA parameter specifies the maximum amount of real storage that can be used to satisfy fixed 1 MB and 2 GB page requests. It was always a maximum number, and it was always (and still is) available for regular 4K pages if needed. Whether or not it's a good idea to give it away to large pages will depend how much memory you have available to your LPAR and if you have something that can take advantage of it. If you have nothing that needs large pages (lots of things do now), then having them allocated just wastes some initial space (remember, you can use them for 4k pages if necessary), but if you need them then it's not a waste at all. You should be able to tell if you need them or if you need more (or I guess it is better stated that if you could USE more). The command to check is MODIFY AXR,IAXDMEM . The best time ti check is when the system is pretty busy. I always go by the saying "needing and NOT having is far worse than having and NOT needing". Especially in this case where having them means you can still use them for other stuff. Again, if you have sufficient memory and aren't paging at all then it's totally your choice whether to allocate some or not. If you check and see that you are wildly over-allocated, then reduce it, if you are under-allocated and can afford the memory, then increase it. It's a fairly simple thing to figure out. Brian On Fri, 26 Mar 2021 21:00:01 +0000, Crawford, Robert C. <robert.crawf...@usaa.com> wrote: >According to the documentation, after z/OS 2.3 the LFAREA parameter no longer >reserves real memory for large frames at IPL. Instead, it's a limit on the >number of fixed 1M frames. > >Since it's now a limit is there any harm in leaving LFAREA too high as long as >you keep an eye on large fixed frame usage and paging? > >I'm asking because we have some LPAR's with wildly underused LFAREA's and few >opportunities to exploit them. The lazy systems programmer in me would rather >leave LFAREA alone rather than try to pick a target value that needs to be >closely managed. > >Robert Crawford >Mainframe Management >United Services Automobile Association >(210) 913-3822 > >� Des clochards comme nous, b�b� nous sommes n�s pour courir � - Voltaire >Please send requests to mainframe management through our front door at >go/mfmfrontdoor<https://onc.jira.usaacloud.com/secure/Dashboard.jspa?selectPageId=15466> > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
