Note, only fully trusted applications can specify a stack size greater than that specified in the executable’s header.
Of course, the above snippet makes the assumption that the application is not using excessive stack space in the first place, but what about reducing the amount required? Consider the following procedural COBOL code:
At first glance this looks to be reasonably well structured with isolated perform sections, but in reality there is an error which will not have an obvious impact on the execution of the code but will have a considerable impact on the code generated by the compiler. If we compile and debug through this, we’ll see a call stack something like this:
The call stack shows that the execution has become recursive and using the technique described earlier to calculate the stack size for this particular example gives a stack allocation of 1300 bytes. The issue is triggered by an ‘exit’ statement out of the perform range in ‘sect00‘. This may well have been triggered by a coding error; we can catch this by recompiling using the ‘RESTRICT-GOTO’ directive. This now produces an error:
The error is caused by an exit out of a perform section. The code in sect00 should have been ‘go to exit00’. Now, if we change this, rebuild and step into the debugger we get:
Not only does the call stack become much more representative of the program, the stack allocation has also reduced. In the example above this was 676 bytes. What has essentially happened is that the compiler previously had to generate a single method for the performed section, whereas now it can produce much simpler, smarter code.
Other issues can be diagnosed by compiling the code with warnings or informational messages enabled. Examining these warnings can highlight other areas where code can be improved leading to better code generated by the compiler.