Maximum Size of Array

Piyari · New User Joined: 19 Nov 2007 Posts: 4 Location: India

Hi,

I have the below array in one of our copybooks.

05 TBL-CLOTH PIC X(96000).
88 JOB-START VALUE LOW-VALUES, SPACES.

05 TBL-LINER REDEFINES TBL-CLOTH.
10 CS-TAB OCCURS 8000.
15 CPGN PIC X(06).
15 SRCC PIC X(06).

...and i have a requirement to change the size of CS-TAB to the maximum size cobol allows...

Could you pls assist?

Our installation uses VS COBOL II... FYI.

Thanks.

Phrzby Phil · Posted: Wed Jan 16, 2008 6:51 pm

Why not just try various values till you hit the max?

A binary search is most efficient. Try a huge number that will fail, then try half of that. If it works, try halfway up to your 1st try; if not, try halfway down. Now iterate the previous sentence.

This should take you maybe 30 minutes, rather than the several days you'll wait for an (either wrong or installation specific (and you won't even know which, if either)) answer you'll get here.

Let us know the answer please.

superk · Posted: Wed Jan 16, 2008 6:52 pm

Here's a link to the documented specifications for limits.

TG Murphy · Posted: Wed Jan 16, 2008 8:48 pm

You are asking for the biggest possible OCCURS. You really should figure out how much you need instead of asking for the biggest possible number.

If you don't know this number - then how do you know that this number will be less than what is possible? Maybe the use of a table is no longer appropriate because your volumes have grown too big. Maybe you need to store your data in a database instead of a table.

I think you should first figure out how big you need your OCCURS to be. And then figure out whether COBOL and your system can accommodate this. As well, if your program will run under CICS grabbing all the storage that you can possibly grab will surely result in the CICS performance guys paying you a nasty visit.

dick scherrer · Posted: Wed Jan 16, 2008 11:01 pm

Hello,

Piyari · New User Joined: 19 Nov 2007 Posts: 4 Location: India

Hi Kevin,

Thanks for the link. This is exactly what i was looking for.

Phil,

Why reinvent the wheel - especially if its just a spec that comes in a manual?

Murphy & Dick,

I am well aware of the storage and performance implications on doing this change, even before i posted this question here.

My customer is stubborn on this change for some reason. I got to prove him wrong....May be with a pinch of strobe and Omegamon stats in test region

Anyway thank you all for your time!

Phrzby Phil · Posted: Thu Jan 17, 2008 6:20 pm

Specs change, manuals get old. If you want to really know for sure, you cannot rely on everything you read.

stodolas · Posted: Thu Jan 17, 2008 6:21 pm

Our TECH support for the mainframe would kill this app everytime it ran for being a memory hog. I had one app I was trying to write for maximum flexibility and they said if I put it into production they would disable it because it used too much memory. Using that much memory killed the CICS region I was testing in.

TG Murphy · Posted: Mon Jan 21, 2008 8:07 pm

Piyari,

Very important for to know whether you need to run your program under CICS or batch. If batch only, then I would suggest you just experiment to see what works at your shop.

Last time I checked we had a batch program that defined a table that was 30,000,000 bytes long. So I checked again and this time I found a program that had several 20,000,000 byte tables and this program's total working storage was 76,000,000 bytes. This is huge and is not typical.

Keep in mind - the group that owns these programs was very careful in getting approval to do this. Just to the same so that your ass is covered.

Good luck..