|
View previous topic :: View next topic
|
| Author |
Message |
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
Hello
Main Storage is no problem anymore nowadays. Usually there is plenty available. The JCL REGION parm only sets an upper limit how much virtual storage can be used. Usually if a batch-job runs ok with a REGION=xxx then it does not run faster, better if I set Region higher than xxx. Step Termination IEF374I (or IEF032I in z/OS 1.13 or higher) displays storage usage. The job-storage high-water mark usually does not depend on REGION if REGION is higher than high-water-mark.
If region is too low then S878 Abends occur.
Most of our batch-jobs use REGION=32M or 64M and run ok.
But I think there are some utilities that check available region and adapt storage allocation behaviour depending on region-size. They may run better with higher region-size (?)
Can you give me hints, which utilites have region size dependent behaviour, if any? Maybe i can optimize a few jobs... thanks. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| They may run better with higher region-size (?) |
as usually it depends,
 pushing the <thing> might result in storage overutilization |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| The JCL REGION parm only sets an upper limit how much virtual storage can be used. |
This statement is true IF AND ONLY IF the site has not implemented a JES exit to override the storage allocation; many sites use such exits. The actual upper limit on region size cannot be determined without consulting your site support group to determine what the JES exit (if any) does to the storage request. And note that the rules are different for storage allocated above the bar.
Consult the vendor documentation for recommended region sizes for their software; you do not want to be changing region sizes for vendor software without having a good, solid reason to do so. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| I once gave the PL/1 compiler REGION=0M and it seemed to go into a loop. I quickly removed it! |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
thanks, jim moores article is good. but it does not contain any hints about utility storage usage.
one thing is important. when testing a job the region should be not to high to find storage leaks. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
What is "utility storage usage"? What kind of "hints" were you hoping/looking for?
No matter what the region size, there will not be "storage leaks". The mainframe does not have the same issues as the Win-based PCs. |
|
| Back to top |
|
|
parsesource
New User
Joined: 06 Feb 2006
Posts: 97
|
|
|
|
| storage leaks do occur sometimes. in z/os, in vendor software or programs made by us. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hdello,
What you call a storage leak does not hapen in "application" programs (your own or vendor written). Why do you believe this could be due to a region being "too high"?
Suggest that the "leaks" you have seen are progamming problems. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1306
Location: Vilnius, Lithuania
|
|
|
|
| Nic Clouston wrote: |
| I once gave the PL/1 compiler REGION=0M and it seemed to go into a loop. I quickly removed it! |
Enterprise PL/I is an absolute storage hog, I always run it with REGION=0M, without any adverse consequences. The other program which seems to need a lot of storage is ADRDSSU, which also runs with a REGION=0M. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
parsesource, if all your company can find for you to do is "optimize" region sizes, then your career needs to be redirected since you are getting make-work, do-nothing assignments.
In these days of 2-gigabyte address spaces, there is almost NEVER a reason to be concerned with region size. If you give a job a region size, and you get back a storage message, increase the region size.
And unless you work for a company creating utility software, why on earth would you even care whether or not the software region size is appropriate? The vendor will tell you in their documentation how much memory to give each batch job and there should not ever be any reason to change their recommendations.
Application program memory leaks are NOT a concern -- when the program completes, the memory is freed and hence cannot be a long-term concern. Certain vendor products that run as started tasks may -- and note I said MAY, not WILL -- allocate more memory than is freed causing a gradual increase in their memory usage. If this happens, though, the vendor generally fixes the problem pretty quickly and in the meantime scheduling an IPL will recover the memory from the started tasks since they will start anew.
The bottom line: you are wanting to optimize something that doesn't really need optimizing, and wasting a lot of time (both on this forum and in your company) by bringing up issues that are not really issues. Find some real problems to work on and get off the memory optimization concept. |
|
| Back to top |
|
|
|
|
