IBM Mainframe Forum Index
Log In
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register

Iterative use of a REXX script causing insufficient storage

IBM Mainframe Forums -> CLIST & REXX
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message

New User

Joined: 26 Jul 2017
Posts: 2
Location: UK

PostPosted: Fri Jul 28, 2017 12:52 pm
Reply with quote


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:

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;

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.

Thanks in advance..
Back to top
View user's profile Send private message
Robert Sample

Global Moderator

Joined: 06 Jun 2008
Posts: 8569
Location: Dubuque, Iowa, USA

PostPosted: Fri Jul 28, 2017 6:10 pm
Reply with quote

From the System Messages manual (emphasis added by me):

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.
System action

An abend will occur unless the program was loaded by a LOAD macro with the ERRET option specified.
User response

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.
Back to top
View user's profile Send private message

New User

Joined: 26 Jul 2017
Posts: 2
Location: UK

PostPosted: Fri Jul 28, 2017 6:36 pm
Reply with quote

OK, thank you. Happy to stop wasting my time searching icon_smile.gif
Back to top
View user's profile Send private message

Global Moderator

Joined: 01 Sep 2006
Posts: 2214
Location: Silicon Valley

PostPosted: Fri Jul 28, 2017 9:42 pm
Reply with quote

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)
Back to top
View user's profile Send private message

Global Moderator

Joined: 28 Aug 2007
Posts: 1689
Location: Tiruppur, India

PostPosted: Sat Jul 29, 2017 12:02 am
Reply with quote

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.

For indepth understanding of how TSO LOGON REGION size works. Look at this link talking about "Size matters" - That's what she said

– 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.

Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> CLIST & REXX


Similar Topics
Topic Forum Replies
No new posts Any examples of calling FTP from REXX? CLIST & REXX 1
No new posts SummeRx: a new framework for REXX z/OS CLIST & REXX 6
No new posts A command to change LRECL of an exist... JCL & VSAM 7
No new posts Using REXX to access SDSF; What am I ... CLIST & REXX 38
No new posts Calling Assembler from REXX PL/I & Assembler 5
Search our Forums:

Back to Top