What does specifying an 8 Meg (8192K) TSO Logon Region Size mean?
It does Not mean you get an 8 Meg region size. Nice guess, and a funny idea, but no. For that matter, REGION=8M in JCL doesn't get you 8 Meg there, either. Hasn't done so for decades (despite what you may have heard or read elsewhere. If you have trouble believing this, feel free to skip down a few paragraphs, where you can find a link to some IBM doc on the matter.)
No, your region size defaults to at least 32 Meg, regardless of what you specify.
Despite the omnipresent threat that the people who set up your own particular z/OS system might have changed the IBM defaults there, or (who knows) might even have vindictively limited your own personal userid — For this discussion, we're assuming you're using a more or less intact z/OS system with the IBM defaults in effect.
So, you ask, What happens when you specify Size 8192 at Logon?
Size ===> 8192
When specifying Size=8192, you will be allowed to use up to 32 Meg of 31-bit addressable memory. This is the ordinary kind of memory that most programs use. You will get this for any value you enter for Size until you get up to asking for something greater than 32 Meg. Above 32 Meg, the Size will be interpreted differently.
If you enter a number greater than 32 Meg (Size ===> 32768), that will be interpreted in the way you would expect – as the region size for ordinary 31-bit memory.
You have to specify a number bigger than 32768 to increase your actual region size.
Just wanted to make sure you saw that. It's not a subtitle.
Notice by the way that region size is not a chunk of memory that is automatically allocated for you, it's just a limit. It means your programs can keep asking for memory until they get to the limit available, and above that they'll be refused.
So, what does the 8192 mean, then? When specifying Size=8192, you will be allowed to use up to 8 Meg of 24-bit addressable memory. (In this context, 8192 means 8192K, and 8192K = 8M.)
This is why trying to specify a number slightly bigger than 8 Meg, say 9 or 10 Meg, is likely to fail your logon with a "not available" message. The request for 9 or 10 Meg is interpreted as a request for that amount of 24-bit memory, and most systems don't have that amount of 24-bit memory available, even though there is loads of 31-bit memory. So asking for 9 Meg might fail with a "not available" message, but if you skip over all those small numbers and specify a number >32Meg then the system can probably give you that, and your logon would then work.
How did this strange situation arise, and what is the difference anyway?
Here starts the explanation of the different types of addresses.
Feel free to skip ahead if you don't care about the math, you just want the practical points.
24-bit addresses are smaller than 31-bit addresses. Each address — Let's say each saved pointer to memory within the 24-bit-addressable range — requires only 3 bytes (instead of the usual 4 bytes).
24-bit memory addresses are any addresses lower than 16 Meg.
There is an imaginary line at 16 Meg. 24-bit addresses are called "Below the Line" and 31-bit addresses are called "Above the Line".
More-Technical-details-than-usual digression here. Addresses start at address zero. The 3-byte range goes up to hex’FFFFFF’ (each byte is represented as two hex digits. Yes, F is a digit in the hex way of looking at things. The digits in hex are counted 0123456789ABCDEF). There are 8 bits in a byte (on IBM mainframes using hexadecimal representation for addressing). So 3 bytes is 24 bits. Hence, 3-byte addresses, 24-bit addressing. Before you notice that 4 times 8 is actually 32, not 31, you may as well know that the leftmost bit in the leftmost byte in a 4-byte address is reserved, and not considered part of the address. Hence, 31-bit addressing.
Decades ago the 24-bit scheme was the standard type of memory, and some old programs, including some parts of the operating system, still need to use the smaller addresses. Why? Because there were a lot of structures that people set up where they only allowed a 3-character field for each pointer. When the operating system was changed to use 4-byte addresses, some of the existing tables were not easy to change — mainly because the tables were used by so many programs that also would have needed to be changed, and, crucially, not all of those programs belonged to IBM. Customers had programs with the same dependency. Lots of customers. So even today a program can run in “24-bit addressing mode” and still use the old style when it needs to do that.
Most programs run in “31-bit addressing mode”. So they are dependent on the amount of 31-bit memory available. By this day and age, another upgrade is in progress. It allows the use of 64-bit addresses. The current standard is still 31-bit addressing, and it will be that way for a good while yet. However, 64-bit addressing is used extensively by programs that need to have a lot of data in memory at the same time, such as editor programs that allow you to edit ginormous data sets.
When specifying Size=8192, you will be allowed to use up to 2Gig of 64-bit memory, as long as your system is at least at level z/OS 1.10, or any higher level. (2 Gig is the maximum addressable by 64 bits, if you wonder.) Prior to z/OS 1.10, the default limit for 64-bit memory was zero. In JCL you can change this with the MEMLIMIT parameter, but there is no way for you to specify an amount for 64-bit memory on the TSO Logon screen.
There is an imaginary bar at 2 Gig, since the word "line" had already been used for the imaginary line at 16 Meg. Addresses above 2 Gig, that is, 64-bit addresses, are called "Above the Bar". Addresses lower than that are called "Below the Bar".
Here ends the explanation of the different types of addresses.
Maybe you wonder what happens for various values you might specify other than 8192 aka 8 Meg. So now we'll discuss the three possibilities:
– You specify less than 16 Meg
– you specify more than 32 Meg
– you specify between 16 Meg and 32 Meg (boring)
Specifying less than 16 Meg
Any user-specified logon SIZE value less than 16 Meg just controls the amount of 24-bit memory you can use.
The limit on how much you can get for 24-bit memory will vary depending on how much your own particular system has reserved for its own use (such as the z/OS "nucleus" and what not), and for the system to use for you on your behalf, for example for building tables in memory from the DD statements in your JCL. (Yes, you have JCL when you are logged onto TSO, you just don't see it unless you look for it. The Logon screen has a field for a logon proc, remember that? It's a JCL proc.)Any 24-bit memory the system doesn’t reserve for itself to use, you can get. This is called private area storage (subpools 229 and 230).
Typical mistake: A user who thinks he has an 8 Meg region size may try to increase it to 9 Meg by typing in 9216 for size. The LOGON attempt may fail. It may fail because there is not nine Meg of leftover 24-bit storage that the system isn’t using. Such a user might easily but mistakenly conclude that it is not possible for him to increase the region size above what he had before. Ha ha wrong, you say to yourself (possibly with a little smile). Because you now know that they have to specify a number bigger than 32768 — that is, more than 32 Meg.
Specifying more than 32 Meg
To increase the actual Region size, of course, as you now know, the user needs to specify a number bigger than 32 Meg (bigger than SIZE==>32768). When you specify a value above 32Meg, it governs how much 31-bit storage you get. The maximum that can be specified is 2096128 (2 Gigabytes).
Specifying any value above 32 Meg ALSO causes the user to get all available 24-bit memory (below the 16mb line). This has the potential to cause problems related to use of 24-bit memory (subpools 229/230). This could happen if the program you’re running uses a lot of 24-bit memory and then requests the system to give it some resource that makes the system need to allocate more 24-bit memory, but it can’t, because you already took it all. The request fails. The program abends, flops, falls over or hangs. This happens extremely rarely, but it can happen, so it’s something for you to know as a possibility.
Specifying between 16 Meg and 32 Meg
What happens if you specify a number bigger than 16 Meg but smaller than 32 Meg? You still get the 32 Meg region size, of course. You also get all the 24-bit storage available — The 24-bit memory is allocated in the same way as it would have been if you had specified a number above 32 Meg. So asking for 17 Meg or 31 Meg has EXACTLY the same identical effect: It increases the request for 24-bit storage to the maximum available, but it leaves the overall region size at the default of 32 Meg. Having this ability must be of use to someone in some real world situation I suppose, or why would IBM have bothered to provide it? but imagining such a situation evades the grasp of my own personal imagination.
THE IBM DOC
If you want to see the IBM documentation on this — and who would blame you, it’s a bizarre setup — check out page 365 of "z/OS MVS JCL Reference" (SA23-1385-01) at http://publibz.boulder.ibm.com/epubs/pdf/iea3b601.pdf
Caveats and addendums
The IBM-supplied defaults can be changed in a site-specific way. Mostly the systems people at your site can do this by using an IEALIMIT or IEFUSI exit, which they write and maintain themselves. Also IBM is free to change the defaults in future, as they did in z/OS 1.10 for the default for 64-bit memory.
If you want to know whether there is a way to find out what your real limits are in case the systems programmers at your site might have changed the defaults, yes there is a way, but it involves looking at addresses in memory (not as hard as it sounds) and is too long to describe in this same article.
Yes, this is a break from our usual recent thread on TSO Profiles and ISPF settings. We'll probably go straight back to that next. The widespread misunderstanding of REGION and Logon SIZE comes up over and over again, and it happened to come up again recently here. There is a tie-in with TSO, though, which you may as well know, since we're here. A lot of problems in TSO are caused by people logging on with region sizes that aren't big enough for the work they want to do under TSO. The programs that fail don't usually give you a neat error message asking you to logon with a larger region size — mostly they just fall over in the middle of whatever they happen to be doing at the time, leaving you to guess as to the reason. Free advice: If you have a problem in TSO and it doesn't make much sense, it's worth a try just to logon with SIZE===>2096128 and see what happens. Oftentimes just logging off and logging on again clears up the problem for much the same reason: Some program (who knows which one) has obtained a lot of storage and then failed to release it, so there isn't much storage left for use by other programs you try to run. Logging off frees the storage, and you start over when you logon again. Batch JCL corollary: If you get inexplicable abends in a batch job, especially 0C4 abends, try increasing the REGION size on the EXEC statement. Go ahead, laugh, but try it anyway. It's an unfailing source of amusement over the years to see problems "fixed" by increasing either the JCL REGION size or the TSO Logon Region size. All the bizarre rules shown above work the same for batch JCL REGION as for TSO LOGON Region Size, except for 64-bit memory, which can be changed using the MEMLIMIT parameter in JCL but cannot be changed on the TSO Logon screen. Remember, you have to go higher than 32M to increase your actual region size!
You need to specify a value bigger than 32 Meg to increase your actual (31-bit) TSO Region size (or JCL Region size).