>>Multiply by 10. Two of our larger LPARs have 640GB each. > >I didn't know that an individual instance could be that large. Without >revealing any company secrets could you tell what combination of systems can >use that much memory above the bar?
Sure, there are not country secrets here. It's *real* storage we're talking about here. There are exceptions, but generally speaking, application code knows only about *virtual* storage. This is where you talk about addressing like below and above the line or the bar. Hardware maps virtual addresses to real addresses. How much *real* storage you can install and use is mainly dependent on hardware limitations and then on the operating system portion that is responsible for hardware storage, i.e the real storage manager (RSM). The fact that hardware and RSM can handle 640GB of *real*, doesn't imply there is a lot of above the bar *virtual* storage usage. Simplified example: Say you have 640 instances of a 31bit application active in parallel, each of which is aktively using 1GB of *below* the bar (virtual) storage. That's 640GB of virtual storage which needs to be backed by real storage to hold the data. If your system has got 64GB of *real* storage, then 90% of your applications data has to be paged out at any point in time. Your system will do a lot of paging. If your system has got 640GB of *real* storage, all of the application's data can be kept in real storage at the same time. The system won't page anymore. Aside from that, DF Sort and DB2 are two "applications" that I know are heavily using above the bar (virtual) storage instead of data space or hiperspace storage. DB2 permits itself to use 4TB of above the bar virtual (by overriding any MEMLIMIT, as I only recently learned). -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
