Is there a size limit for Working-Storage section?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

I wonder if there is a size limit for WORKING-STORAGE SECTION.

If there is, how much will it be ? can it hold data for over 3M？

Robert Sample · Posted: Thu Aug 23, 2012 6:44 am

The Enterprise COBOL Language Reference manual (link at the top of the page) has all compiler limits in Appendix B Compiler Limits. WORKING-STORAGE has a limit larger than 3M (assuming you mean 3 megabytes here and not the company that makes tape and other products); I've compiled and executed programs using a 10 million byte variable for an XML process.

Bill Woodger · Posted: Thu Aug 23, 2012 6:52 am

Either as a whole, or as a group item, or as an elementary item, 3M, taking the same guess as Robert, will be nowhere near a problem.

Everytime you wonder about something, just check the manual first.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

My bad, but I indeed had looked up <COBOL programming guide> and <COBOL programming reference> for answer before I raise this question, but I never expected the Appendix would give me the answer.

Now , I've got the answer: Working Storage Section can hold up to 128M.

Bill O'Boyle · Posted: Thu Aug 23, 2012 9:07 am

Are you defining a very large table in WS? If so, consider moving it to LINKAGE as an OCCURS DEPENDING ON and only acquire the storage-amount needed, using LE Callable Service routine "CEEGTST".

An OCCURS DEPENDING ON table defined to WS will always be allocated to its maximum-size.

dick scherrer · Posted: Thu Aug 23, 2012 9:13 am

Hello,

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

hi, dick,

I'm implementing multi-row fetch for DB2 table inquiry, and when I declared the row-set, I had a concern whether the dimention size would impact on the performance or execution of COBOL program.

According to the consultant from HP, " if the large size of rowset causes the data division size exceeds 64K, overlap error might occur when execution" . -->this is their experience, but I have no idea why this would happen, I also did not find any relative information from COBOL manuals.

Robert Sample · Posted: Fri Aug 24, 2012 7:33 am

The consultant from HP might be talking about HP COBOL and not Enterprise COBOL.

dick scherrer · Posted: Fri Aug 24, 2012 7:38 am

Hello,

If one who knows recommends limiting the size to 64k, it might be a good idea to do so. . .

After everything runs perfectly at 64k, it might be ok to experiment with something larger, but be aware that the over 64k problem may not happen often enough to work on - just enough to bring the system down periodically . . .

Why is 64k not sufficient?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

hi, dick,
I don't understand why 64k not sufficient. they just told their experience.

they say, if row-set size leads data division too large, there is possibility for program crash, and usually this kind of abend is very very hard to find out.

dbzTHEdinosauer · Posted: Fri Aug 24, 2012 10:56 am

Bill Woodger · Posted: Fri Aug 24, 2012 1:03 pm

If 64k is some "problem" it sounds like there is a two-byte unsigned binary field involved.

Why would an HP consultant, per se, know much in detail about DB2 [Edit, whch I can't even spell]? Can you ask specifically, or does that cost too much?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

dick scherrer · Posted: Fri Aug 24, 2012 9:19 pm

Hello,

With or without DB2, Bill's observation should still be considered.

Actually, you are the one who mentioned DB2 . . .

If, indeed, there is something in the application that uses some kind of 2-byte binary field for length/displacement/whatever, the 64k may still be an issue. . .

Why not just use the 64k . . .

Bill Woodger · Posted: Fri Aug 24, 2012 9:32 pm

Perhaps the HP Consultant was talking through his ear when it comes to Enterprise Cobol, as Robert suggested? OK, you've paid (HP) for it, so go with Dick's suggestion. Get it working with the 64k, then move on to your 3M or whatever you feel you actually need.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

dick scherrer · Posted: Fri Aug 24, 2012 10:06 pm

Hello,

Once again, you have gotten completely lost. . .

There is no connection between A 2-byte binary and a 64k size of data division. . . The 2-byte binary can hold a maximum value of 64k which has nothing to do with the total size of the data division.

The "why" is because someone who knows the product said so . . .

Bill Woodger · Posted: Fri Aug 24, 2012 10:08 pm

Calculate the value that can be held by an unsigned two-bytes. Or what is FFFF in decimal?

I have never used an IBM Cobol compiler with a Working-Storage limit of less than 1M. If there is a "limit" to something, something is imposing that limit. If there is a limit to something of 64k, then it is likely to be to do with something held in an unsigned binary half-word (two bytes) as the maximum value that that can hold is what you have just discovered. If a limit is 32k, then you'll probably trace it to a signed half-word somewhere along the way.

When you see numbers in decimal, put them into hex. Often helps.