Hi John,
Everyone else has focused on how the user might have been able to
allocate more than the expected amount of storage my consideration is
that as long as the user is doing something related to the business the
resources need to be provided. Several years ago I implemented an
IEFUSI exit that makes the REGION on the TSO LOGON PROC screen
meaningless. Everyone gets all the available below the line storage
less a cushion for recovery and a generous allocation about the line (1G
in many cases) with very similar processing for batch workloads. You
might find that the right number for your site is smaller (32M, 100M,
256M). I finally got the site standards manuals changed to reflect
this. Why should users have some interactive process in APL2 or some
other tool fail for lack of virtual storage below? I don't want users
to constrain the SORT product or other tools I prefer to do that
globally only as needed.
If you add in lots of real storage, generous defaults and prevent bad
JCL or LOGON settings from users artificially limiting themselves or
programs in silly ways to settings that made sense in 1978, define lots
of page space, reasonable controls in LE, SORT, etc. you won't have to
have work rerun because users ran out of "virtual" storage. Really
does it make sense to have to rerun a quarterly accounting job because
it has had REGION=512K coded for 10 years and business volumes increased
or an LE upgrade required more virtual storage for service routines?
People are expensive.
Reruns are expensive.
Paging can be expensive not having enough paging space can be more
expensive don't short yourself.
I/O is expensive and slow.
Real memory is cheap.
Virtual memory is cheap till you come close to running out (EPVT, ECSA,
PVT, doesn't matter not having enough usually leaves a mark).
Do your best not to run out of real or virtual storage needed to run
work successfully and as efficiently as possible.
My suggestion is to make sure that almost no one but yourself ever has
to think about "REGION". It seems fair after all we don't have to
program in COBOL:-) An IEFUSI exit really is a great tool for you to
use here. It allows you to raise what users request to prevent abends
and run work more efficiently or to control it in almost any way you
need.
As an aside the running joke between the DB2 Systems programmer and
myself usually involves a jib to get a quote for more virtual storage
from our IBM rep. Managing virtual storage in 2GB address space above
and below is still a very real challenge in large DB2 V8 subsystems and
even a few CICS regions:-(
Best Regards,
Sam Knutson, GEICO
Performance and Availability Management
mailto:[EMAIL PROTECTED]
(office) 301.986.3574
"Think big, act bold, start simple, grow fast..."
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Chase, John
Sent: Friday, January 26, 2007 11:41 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: TSO Storage Usage, Limits, etc.
Hi, All,
Just rolling out z/OS 1.7 and are looking to "modernize" some things,
including TSO storage allocations and limits. Currently using
"XA-period" limitations like REGION=6144K in the logon proc,
MAXSIZE=6144 in the TSO segment of the users' RACF profiles, etc.
What would be "reasonable" limits for a z/OS 1.7 image running on a
z9-BC with 4GiB central storage, averaging around 75 - 90 TSO users
(mostly COBOL programmers) daily?
Also, our current limitations notwithstanding, a snippet of a TASID
display of TSO address spaces shows this (jobname and procname have been
"anonymized"):
======================================================
Jobname | Procname Stepname CPU Time Storage
------------------------------------------------------
UTSO001 ... TPROC001 ... EXEC ... 21:53.34 90.2M
======================================================
How is it that this user has apparently been able to allocate and use
90.2M storage, considering:
1. We have JES2 JOBCLASS(TSU) REGION=4M, 2. TPROC001 specifies
REGION=6144K on the EXEC card, 3. The user's TSO segment in RACF
specifies MAXSIZE(6144), and 4. We have NO installation-written IEFUxx
exits in use?
TIA,
-jc-
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
----------------------------------------------------------------------
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
