Thanks for the responses, gents Carmen: yes - that is what I see in the manual Jim: Thanks for the update - it would appear that the manual requires an update 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 have to say that even after 40 years on mainframes I still don't fully understand this kind of memory-associated stuff I can understand that it's rooted in the past when 'memory' was expensive so it had to be protected from over-commitment. These days, though, I find it next to impossible to justify insufficient physical memory; it's so cheap (comparatively speaking), there's just no excuse. Even if your environment is thus limited then paging to/from disks on a RAID array removes most of any remaining constraints. Given that (probably poorly-informed) stance, then REGION and MEMLIMIT limits become pretty much meaningless. Don't they? Regards Sean On Tue, 20 Nov 2018 at 07:49, Peter Hunkeler <[email protected]> wrote: > > > From fading memory, so things might have change slightly, but I think most > of this still applies. > > > The REGION and MEMLIMIT values that apply to z/OS UNIX processes depend on > how and where the process is running: > > > a) BATCH jobs, started tasks, TSO user sessions > A program run as batch job, started task, or in a TSO session gets its > REGION and MEMLIMIT via JCL, which may be changed by IEFUSI (and IEFLIMIT). > When this program makes use of z/OS UNIX services, it will become dubbed, > i.e. it becomes a UINX process. It still runs in the same address space. > Nothing changes with respect to REGION or MEMLIMT. > > > When this process spawn()s (non-local spawn) or fork()s a new process, > that new process will be in a BPXAS address space. REGION and MEMLIMT will > be inherited from the originating batch job address space. None of the z/OS > UNIX settings apply. > > > IEFUSI will gin control in the BPXAS address space before the UNIX process > gets control. OMVS set REGION to the magic value 54M. This has not meaning > and will later be replaced by the values from the originating batch job. (I > don‘t know why 54M was chosen as the indicator value.) > > > b) If a z/OS UNIX process is a daemon, such as FTPD, otelnetd, etc. which > listens for incoming session calls, then authenticates the new user, and > spawn()s / fork()s a new process for this new user, then REGION and > MEMLIMIT will be set from the z/OS UNIX parameters (ASSIZEMAX/MAXASSIZE, > etc). It is not useful to inherit those values from the parent process in > these cases. The parent is the server, the childs are the unser sessions. > They serve different means. > > > So, your IEFUSI should not touch the REGION and MEMLIMIT field when it is > called for OMVS address spaces (see flags as described in the IEFUSI > description). And, for the putty sessions, the MAXASSIZE or ASSIZEMAX value > should apply. Try to run Mark Zelden‘s REXXSTOR in a TSO session, after TSO > OMVS, and in a putty session to see the differences > > > From the „z/OS MVs Installation Exits“ manual: > Additional Considerations for z/OS UNIX Applications: > When running z/OS UNIX applications you need to consider that fork and > spawn are issued to create new address spaces. The default processing on > fork and spawn is for the z/OS UNIX kernel to propagate the region size > from the parent to the child. Because the region size in the parent process > has already passed through IEFUSI and has an approved region size, IBM > recommends that you bypass normal IEFUSI processing when the subsystem > (Word 8) is OMVS. > > > At the time of IEFUSI processing, the kernel has not yet propagated the > parent's region size to the child, so IEFUSI has nothing to work with. If > IEFUSI modifies the region size of the child process, the kernel will honor > that region size and not propagate the region size from parent to child. > This can result in failure of a fork if the region size is insufficient in > the child to capture the parent's storage. > > > -- > Peter Hunkeler > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
