Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hi! When I defined the following 1

Status
Not open for further replies.

Haha

Programmer
Jul 25, 2001
3
SG
Hi!

When I defined the following in my Working-Storage section and compiled my program, I received a compilation error that says, "Table element longer than 32767 characters".

01 FILLER.
03 FILLER OCCURS 17.
05 FILLER OCCURS 40.
07 TR-LTY-AMT PIC S9(16)V99 OCCURS 50.

My question is this, is there a way to increase the maximum allowed limit from 32767 to let say 50000? The only solution I can think of to avoid hitting this maximum is to change the program to save the information to a file instead of to a table. But I cannot afford to re-engineer my three-year-old program with more than eight thousand lines of codes in it, at the moment.

Please advise.

Thanks a lot,

Haha
 
You have a multi-dimensional table whose largest element is already 34,000 bytes long. Thats 34,000 for each time the first element occurs. Too big!
Other than using an indexed file (much better!), you could divide the table into two tables. But, by the time you coded that, you might as well code the file...

Stephen J Spiro
Member, J4 COBOL Standards Committee
check it out at
and

stephenjspiro at hotmail.com
 
Haha -

I notice that your lowest level element is a number, so how about changing it to a BINARY or even a PACKED-DECIMAL number. This would decrease your highest level item to 16,000 or 20,000 characters respectively. You would even still have some room to grow later, if you should need it!

Hope this helps, Betty Scherber
Brainbench MVP for COBOL II
 
Haha,

i seriously doubt you want to hear this, but any program using such enormous internal tables does something wrong ! They haven't invented external storage for nothing !

Betty's solution gives you more room quickly; re-engineering sounds like the best solution on a longer term.
In what environment does your program run ? Do you have access to a relational database system ?

Regards,
Ronald.
 
Hi Ha,

Here's a trick I learned before they expanded the tbl limits on the MF.

Get your tbl entry size down below the limit (use Betty's tip of defining the AMT as comp-3). Use occurs 1 time (that's right 1) for the tbl entry (the 03 level). After your 07 level define an 03 level for as many bytes as you need (50000). Don't use an occurs here; just pic x(50000). If that's beyond the elementary level limit split it up into multiple 03s.

Now just fill & ref the tbl as if it had 17 entries. P.S., obviously you can't use indexes.

This could be considered breaking the law but you may not have a choice.

Regards, Jack.
 
Hi Guys,

Thank you so much for the quick reply! I will use Betty's solution.

RonaldB, I am running my program in AS/400 environment.

Haha
 
Extrememly large tables can be useful and I don't think they are automatically "wrong". Fortunately most modern compilers no longer restrict you to a 32K table size!
 
Thane,

there certainly are cases internal tables are the most efficient solution. I'd like however to see an example of a problem better solved by an "extremely large table" rather then external storage, "better" in any meaning desired.

Regards,
Ronald.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top