For an LPAR, you should have enough dasd to back real memory. To take a system dump, you need to copy the memory and the paging. So you need 3X the amount of real memory. If paging on any LPAR is over 30%, you should be reducing usage or adding space. On Tue, Nov 20, 2018 at 6:02 AM Peter Hunkeler <[email protected]> wrote: > > > > >Peter: I'm still trying to fully assimilate what you've said - very > detailed & complete. Where did you get all this from? Is it documented > somewhere, or is it something you've 'soaked up through your fingertips' > over the years? > > > I pasted one section which is one part of the „documented somewhere“. There > is probably more parts that are documents, but I was too lazy to seek them > all. So it‘s comes to „soaked up through your fingertips“, or better > „discussing on fora“ and soaking up though the eyes :-) > > > I‘ve been following and teaching z/OS UNIX for a couple of years when it came > out in 1994. A lot has been discussed, and tested back then. That is why I > wrote 2fading memory“. I haven‘t been following changes to z/OS UNIX as close > as I used to. > > > > > >Given that (probably poorly-informed) stance, then REGION and MEMLIMIT > limits become pretty much meaningless. Don't they? > > > > > I‘m can agree regarding REGION; I do not regarding MEMLIMIT. I‘m convinced a > program going wild using 64bit memory can bring the system down in no time, > if it is *not* limited to a reason amount. > > > Remember: Even though a z13, or a z14 can have up to 10TiB, or 32TiB of real > memory installed, z/OS V2.2, and V2.3 can only support up to 4TiB. 4TiB is > nothing compared to 16EiB (the full 64bit addressing range). Storage finally > needs to be backed by real storage. And, real storage needs to be backed by > paging storage (virtual flash memory or paging DASD). Given the fact that the > largest supported DASD EAV volume is 1TiB now, you would need 16.8 Million > 1TiB paging devices to be able to back one single 64bit address space. > > > From experience I know that programs *do* eventually go wild. Better protect > your system with a low MEMLIMIT, and allow larges values only sparingly. My > $0.02 only, of course. > > > — > Peter Hunkeler > > > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN
-- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
