|
View previous topic :: View next topic
|
| Author |
Message |
Mistermind
New User
Joined: 08 Feb 2008
Posts: 46
Location: Dublin
|
|
|
|
Why did IBM bring out the REGION= parameter?
As the number of files increases and GETMAINS increase (often without tidying FREEMAIN) the requirement for storage increases. In old JCL often a low REGION= is specified, resulting in an S878 dump even when the modern installation is no longer short of real storage.
If an rmode24 executable loadmodule switches to amode31 and is loaded above 16M, any attempt to execute JCL with REGION=16M or lower will abend S822. In a modern installation REGION=0M would seem to be the sensible default choice.
What would be the pros and cons of basically removing all REGION= parms or replacing them with REGION=0M? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
If you look at the history of IBM mainframes, REGION= has been around as long as JCL has. The first mainframes came with 32 or 64 K (not M) IIRC, and there were a number of facilities to deal with limited memory (for example, the REGION= in JCL as well as overlays in the linkage editor).
| Quote: |
| when the modern installation is no longer short of real storage. |
Terminology point -- your job uses virtual (central) storage, not real storage. There are differences.
| Quote: |
| If an rmode24 executable loadmodule switches to amode31 and is loaded above 16M, any attempt to execute JCL with REGION=16M or lower will abend S822. |
This is site dependent. Our site has approximately 9.2 M of free memory below the 16M line once z/OS is loaded, so asking for 12M is guaranteed to fail. Furthermore, had you read the JCL Reference manual (link at the top of the page), you would know that by default IBM allocates 32M of above the line storage to jobs that ask for 16M or less of memory.
| Quote: |
| What would be the pros and cons of basically removing all REGION= parms or replacing them with REGION=0M? |
The JCL Reference manual specifically warns that system problems may result if every job uses REGION=0M and suggests do not do this. When IBM says something like this, wise people listen.
Further, removing REGION= may have unexpected results. There are two site installatiion exits, IEFUSI and IEALIMIT, that control how much memory a batch job really gets (REGION= only works as long as it is within the values specified by these exits -- ask for more and the exit cuts the request to the limit).
Summary: talk to your site support group to find out what the IEFUSI and IEALIMIT values are. They may need adjusting but they can help. Do not code REGION=0M on everything unless you like system problems. |
|
| Back to top |
|
|
Mistermind
New User
Joined: 08 Feb 2008
Posts: 46
Location: Dublin
|
|
|
|
| Quote: |
| you look at the history of IBM mainframes, REGION= has been around as long as JCL has.? |
Was REGION= available in DOS JCL ? Did DOS use JCL? Was MVS born with IBM?
| Quote: |
| Terminology point -- your job uses virtual (central) storage, not real storage. There are differences. |
There is no point in allocating vast storage when an installation has tiny real storage, it would only end in thrashing. Do you understand the difference? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| Was MVS born with IBM? |
Yes
Yes, but not the same as os/1, os/2, mft, mvt, and mvs. * These used the DD statement for dasd dataset definitions, DOS used an ASSGN, DLBL, and an EXTENT statement.
* Added later for clarity. . . d
| Quote: |
| Was REGION= available in DOS JCL? |
I don't remember, but probably not. DOS partitions/initiators were fixed size and you used the amount of memory allocated to that partition.
| Quote: |
| Do you understand the difference? |
Rhetorical question?  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Also, keep in mind that there are major differences between the DOS that predated mvs and the current dos/vse. . .
And no, we'll not try to list the differences here.
d |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| There is no point in allocating vast storage when an installation has tiny real storage, it would only end in thrashing. Do you understand the difference? |
The current terminology is that REAL storage is non-pageable while VIRTUAL storage is pageable. Thrashing, by definition, cannot happen in REAL storage because it won't page out. So, yes, I understand the difference -- I also set up the memory allocations for each LPAR as part of the system definition process, install the IEFUSI and IEALIMIT exits where required, and work with programmers having memory issues. And z10 machines come with 4 GB minimum memory so "tiny real storage" isn't much of an issue these days. |
|
| Back to top |
|
|
Mistermind
New User
Joined: 08 Feb 2008
Posts: 46
Location: Dublin
|
|
|
|
Was MVS born with IBM?
Yes
And where did MFT and MVT come? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| MFT and MVT were both from IBM as well. |
|
| Back to top |
|
|
Bill Dennis
Active Member
Joined: 17 Aug 2007
Posts: 562
Location: Iowa, USA
|
|
|
|
In the context of the discussion, I took the reference to "real memory" by Mistermind to be the installed on the processor type not the VIRT=REAL type.
He is correct that over-allocating virtual memory when the processor has limited installed memory can cause "thrashing" in the form of PAGE dataset activity. Of course, just coding REGION=0M impacts nothing unless the program tries to obtain it. |
|
| Back to top |
|
|
Mistermind
New User
Joined: 08 Feb 2008
Posts: 46
Location: Dublin
|
|
|
|
Thank you Bill  grasping the point intelligenty.
Of practical relevance is the introduction of greatly increased I/O buffers. For sequential read/write such buffer areas would be not only allocated but referenced repeatedly. If an installation was short on real core and already with a high paging rate, then the convenience of buffers could be negated by repeated pageout and pagein to the page dataset in between references.
REGION=0M would remain OK if JCL had been proven executing a 24-bit program below the line, then the same program is converted to 31-bit above the line. But REGION=2M which previously suited 24-bit will need to be changed to suit 31-bit. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
REGION=0M would remain OK if JCL had been proven executing a 24-bit program below the line, then the same program is converted to 31-bit above the line. But REGION=2M which previously suited 24-bit will need to be changed to suit 31-bit.
|
Sigh ... did you not read my earlier post? IBM by default for REGION=2M automatically acquires 32M of above the line storage (which you are, incorrectly, referring to as 31-bit) so changing a 24-bit program to run 31-bit would not require any REGION= change unless your site has implemented something other than the IBM standard.
As far as your other point, system programmers do monitor system paging rate. We are aware of the potential impact. We are also aware of how many gigabytes of memory are assigned to each LPAR, so excessive paging is investigated both from the system as well as application viewpoint. We are also aware that buffers are high-activity memory pages so it is rare for them to be paged out since system paging works on LRU (least recently used) principles.
If you have any questions about your system performance, you need to contact your site support group. It is very likely that they are already aware of the issue and have plans for dealing with it, or can explain why some higher-priority function prevents them from addressing your concerns. |
|
| Back to top |
|
|
|
|
