>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
