I have a REXX script which calls 9 sub modules (also REXX scripts) which retrieve data from DB2 tables, formats and writes the information to a file before returning control to the main calling module. This file is not huge- RL 133, perhaps 100 records max
I am able to use this module up to 5 times but on the 6th time I use it I get an abend with the following information:
NOT ENOUGH STORAGE FOR BUFFER. LOG ON WITH LARGER SIZE PARAMETER
I thought that creating and deleting a bufferpool each time the rexx was run would help and it did but only slightly- I was able to run it up to 7 times but on the 8th time I get the following message;
IEW4000I FETCH FOR MODULE xxxxxx FROM DDNAME SYS00064 FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE.
CSV031I LIBRARY ACCESS FAILED FOR MODULE xxxxxx , RETURN CODE 14, REASON CODE 6110021, DDNAME SYS00064
I've also tried creating a new stack and deleting it each time the rexx is run which didn't improve things beyond 8 tries.
I have read about other people experiencing this issue and they were advised to log off and on again which I know works but I am hoping that there is a slicker way of getting around this problem ie a way of getting back some storage via commands in the REXX script.
Any suggestions toward a solution or any help toward a better understanding of the problem would be appreciated.
Joined: 06 Jun 2008 Posts: 8165 Location: East Dubuque, Illinois, USA
From the System Messages manual (emphasis added by me):
FETCH FOR MODULE program-name FROM DDNAME ddname FAILED BECAUSE INSUFFICIENT STORAGE WAS AVAILABLE.
There was insufficient storage available to load the load module or program object. If the DDNAME is *VLF*, then this failure occurred while attempting to retrieve the module or program object from VLF rather than from a dataset.
An abend will occur unless the program was loaded by a LOAD macro with the ERRET option specified.
Rerun the job with a larger region size specified.
For a TSO session, you get a larger region size by logging off, then logging on and changing the region size on the LOGON parameters screen -- or by contacting your site support group and having them change the TSO region size for you.
The manual is telling you that this is the solution, so looking for REXX solutions is going to be pretty much a total waste of time.
Joined: 01 Sep 2006 Posts: 2086 Location: Silicon Valley
I thought any storage used by rexx would be released when the rexx program ended.
For that reason, I think it likely that your DB2 access is getting storage and not releasing it. Tell us about how you access DB2; more importantly, how cleanup is done when you end the rexx program. (I say 'us', because I am not familiar with how rexx does DB2 stuff)
I believe you need to first understand whart memory is not being freed up.
If you go by the route to increase TSO logon region size, then you have to increase to a number higher than 32768. You would face issues if you increase it slightly from say 8M to 10M.
– 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.