Amazingly I was just looking at this today because our /tmp space has
gotten to where it occasionally fills up on day 13 (like today) before
our day 14 IPL (mostly from keeping two week's worth of syslogd sendmail
logging).
The manual warns that overly large TFS space without using a colony
address space can impact the kernel address space. This is because it
does use private virtual storage (above the line), which is a finite
resource. Whether this is a problem obviously depends on how large is
"large", how many TFS's are defined, and what other activities in your
shop put stress on the OMVS address space virtual storage. I think you
could direct each TFS to its own 2 GiB colony address space if virtual
storage became an issue, but you would still have to worry about the
impact on your page data sets and real storage for the working sets.
In our environment (fairly minimal end user usage of unix features),
this Friday we had about 1.5 GiB virtual storage unused above the line
in the OMVS address space, so increasing our /tmp TFS from 100 MB to 200
MB should have negligible impact. YMMV. Interestingly, our current TFS
virtual storage usage did not show up in the user extended private area
but in the Extended LSQA/System area (on z/OS 1.4).
Shmuel Metz , Seymour J. wrote:
In <[EMAIL PROTECTED]>, on 07/08/2005
at 03:19 PM, Gabriel Tully <[EMAIL PROTECTED]> said:
Is this really true.
No. It takes *virtual* storage from whatever address space (OMVS or
colony) is handling it, which means that it takes storage from your
local paging data sets.
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
