Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

How to increase the space in working storage memory

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
Venkata Ramayya

New User


Joined: 03 Dec 2007
Posts: 39
Location: United States

PostPosted: Tue Jan 15, 2008 12:17 am    Post subject: How to increase the space in working storage memory
Reply with quote

Hi,

I am using 3 dynamic tables (with the expected occurrences more than 30,000 times) . Due to this I am getting an error by saying that " Insufficient storage was available to satisfy a get storage (CEECZST) request." Please advise me the way to increase the working storage memory space.

Thanks
Venkat
Back to top
View user's profile Send private message

mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Tue Jan 15, 2008 12:59 am    Post subject:
Reply with quote

Venkat,

Use the "manuals" tab at the top of this panel and croll down to the msgs and codes manuals. Then use the msg# of your msg. They usually tell you what has to be done.
Back to top
View user's profile Send private message
stodolas

Active Member


Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin

PostPosted: Tue Jan 15, 2008 1:04 am    Post subject:
Reply with quote

Either way though, those are kinda large tables. Is there really a need to have 90,000 rows of tables in memory for just 3 tables?
Back to top
View user's profile Send private message
stodolas

Active Member


Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin

PostPosted: Tue Jan 15, 2008 1:04 am    Post subject:
Reply with quote

Amendment: They are large especially if they have a large width.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Tue Jan 15, 2008 1:57 am    Post subject:
Reply with quote

Here's what he has to live with, according to the Compiler Limits Appendix in the Enterprise COBOL Reference.

OCCURS integer
16,777,215

Total number of ODOs
4,194,303 (1)

Table size
16,777,215 bytes

Table element size
8,388,607 bytes

ASC/DES KEY ... (per OCCURS clause)
12 KEYS

Total length
256 bytes

INDEXED BY ... (index names) (per OCCURS clause)
12

Total num of indexes (index names)
65,535

Size of relative index
32,765
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Tue Jan 15, 2008 7:57 pm    Post subject:
Reply with quote

Here's something on WS total size limits:

Working-storage and local-storage sections

Items without the external attribute
134,217,727 bytes

Items with the external attribute
134,217,727 bytes

If you're asking for more than that, you won't get it.
Back to top
View user's profile Send private message
stodolas

Active Member


Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin

PostPosted: Tue Jan 15, 2008 7:58 pm    Post subject:
Reply with quote

That limit is within a LUW right? So calling subprograms won't help?
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jan 16, 2008 1:16 am    Post subject:
Reply with quote

The only LUW (Logical Unit of Work) I'm familiar with is a CICS concept. Is that what you had in mind?

Anyway, I think Venkat's solution lies (lays?) with Dick Scherrer's stickey in this forum. Drop the table idea and do a file match.
Back to top
View user's profile Send private message
stodolas

Active Member


Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin

PostPosted: Wed Jan 16, 2008 1:19 am    Post subject:
Reply with quote

More like run environment if a program running (batch or CICS) calls another program is the limitation applied per program or is it applied to the series of programs as a whole.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jan 16, 2008 5:02 am    Post subject:
Reply with quote

Steve,

The limit applies to any data defined after a WORKING-STORAGE SECTION label in a COBOL pgm main/sub or otherwise.
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Wed Jan 16, 2008 8:55 pm    Post subject:
Reply with quote

The OCCURS value is important BUT you also have to look at how big each table element is.

OCCURS 30000 PIC X(1)
OCCURS 30000 PIC X(100)

Big difference here

Start off by examining the datatypes of each field defined in your table. Are you using the most efficient datatypes? For example, you should be using COMP and/or COMP-3. Your PIC X(26) DB2 timestamps (if you have any defined) can be compressed into a PIC X(10) field.

Consider using dynamic allocation using CEEGTST. Check the LE reference manuals for more about that.
Back to top
View user's profile Send private message
mmwife

Super Moderator


Joined: 30 May 2003
Posts: 1592

PostPosted: Wed Jan 16, 2008 9:57 pm    Post subject:
Reply with quote

You're right TG. All he has to do is compute the size of the 3 tables and compare that to the WS limit.

If the "dynamic alloc" you mention is similar to a get main, or he needs the Linkage Sect. to access the data, he faces the same limit.
Back to top
View user's profile Send private message
TG Murphy

Active User


Joined: 23 Mar 2007
Posts: 149
Location: Ottawa Canada

PostPosted: Mon Jan 21, 2008 8:22 pm    Post subject:
Reply with quote

mmwife correctly notes the following:

Quote:
If the "dynamic alloc" you mention is similar to a get main, or he needs the Linkage Sect. to access the data, he faces the same limit.


What I failed to expand on here is how the use of CEEGTST could help. Let me try...

The big program with COBOL tables is that you must size them to accommodate the worst-case scenario. For example, the vast majority of data may only require OCCURS 100 but you may have a few that require OCCURS 10000. Because of this odd duck you must go with OCCURS 10000 knowing that 99% of the time you will be wasting 99% of this storage.

The idea is to only get what you think you will need. And only when you need more than that will you go get more. Of course you still run the risk of running out of memory but the chance of this happening is reduced.
Back to top
View user's profile Send private message
Venkata Ramayya

New User


Joined: 03 Dec 2007
Posts: 39
Location: United States

PostPosted: Mon Jan 28, 2008 1:47 am    Post subject:
Reply with quote

Hi All,

Sorry I could not reply to your answers since I was on vacation. I will try to implement as you all suggested. Thanks to everybody for your replies.

Venkat
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts Not enough virtual memory is availabl... Vinay Pushpala IBM Tools 16 Tue Sep 13, 2016 4:37 pm
No new posts Increase the screen size after split mistah kurtz TSO/ISPF 2 Fri Sep 02, 2016 6:39 pm
No new posts SCRNAME not working on my mainframe? mrsidhu12 TSO/ISPF 7 Thu Sep 01, 2016 2:17 pm
No new posts 2 same CLIST pgm but with different n... boyti ko CLIST & REXX 5 Fri Jun 03, 2016 4:55 pm
No new posts REXX Screen not working due to LINKED... sundarkudos CLIST & REXX 1 Mon May 09, 2016 1:44 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us