|
View previous topic :: View next topic
|
| Author |
Message |
Venkata Ramayya
New User
Joined: 03 Dec 2007
Posts: 49
Location: United States
|
|
|
|
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 |
|
 |
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
stodolas
Active Member
Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin
|
|
|
|
| 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 |
|
|
stodolas
Active Member
Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin
|
|
|
|
| Amendment: They are large especially if they have a large width. |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
stodolas
Active Member
Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin
|
|
|
|
| That limit is within a LUW right? So calling subprograms won't help? |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
stodolas
Active Member
Joined: 13 Jun 2007
Posts: 632
Location: Wisconsin
|
|
|
|
| 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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
TG Murphy
Active User
Joined: 23 Mar 2007
Posts: 148
Location: Ottawa Canada
|
|
|
|
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 |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
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 |
|
|
TG Murphy
Active User
Joined: 23 Mar 2007
Posts: 148
Location: Ottawa Canada
|
|
|
|
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 |
|
|
Venkata Ramayya
New User
Joined: 03 Dec 2007
Posts: 49
Location: United States
|
|
|
|
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 |
|
|
|
|
