function exceeds workspace
Posted 06 September 2012 - 11:10 AM
We're using 5.5 Windows version and are having problems with a function.
It's a report and is quite large with 62 characteristics and various files, logics etc.
We frequently experience "function exceeds workspace" when running it.
The metrics as it currently stands are:
Global Logics: 6598
Symbol Table: 80104
Over the years we've tried, on a trial and error basis, several things - reducing the number of file variables with alternate definitions, defining all scratch vars, reducing the number of scratch vars etc.
But every time it happens we scratch our heads because we never really know where to hurt it.
Does anybody understand the metrics or can anybody offer any advice please?
Posted 06 September 2012 - 12:05 PM
In my experience the 'function exceeds workspace' doesn't have much to do with it's size more likely to be a fault somewhere. It is a very big function though.
I have seen this error on very small functions as well as larger ones. It's much less common in version 7 I have to say.
Posted 07 September 2012 - 09:08 AM
Over the years we have had this error and at times I thought it was due to function size but we had it on functions a fraction the size of yours.
It usually seemed to be due to the function doing something inefficient with e.g. an array or large record.
With reports we tended to create an update to write the selection to temp files and then create a report to just read the temp files.
I imagine you don't fancy rewriting your report....
Posted 07 September 2012 - 12:58 PM
...and search for topic 720287. It makes reference to two environment variables called DATABUFFERSIZE and SPECSIZE. Try tuning these and see if that resolves your issue.
If anyone has a set of 5.5. manuals, they may be able to confirm this. As Steve suggested, a lot of work was conducted in version 6 and 7 of PROIV on workspace and the only time we ever get it now is if we write bad code e.g. a file read on a screen read erroring onto the same read field (looping) or recursive loops to a cycle
Posted 08 September 2012 - 12:31 PM
There are two kinds of workspace issues that are not linked but give the same message. There are Gen time workspace issues - this is where the size of the genned Function, or the intermediate buffers in the gen process become full. This can be affected by reducing logic complexity, removing unused scratch variables or arrays. One thing we have discovered in 5.5 is that it fixes an issue with previous versions where a single large logic (or Global logic) - say more than around 850 lines of code could trigger a gen time workspace issue even though the function is tiny. Anyway, there are the issues where the statistics Steve mentions are relevant.
However, in the second type of Workspace issue - the one Steve is experiencing, these figures and the number of files, variables etc is not the issue. A "FUNCTION EXCEEDS WORKSPACE" issue at this point is due to the run-time stack running out of space. This happens when ProIV has to "remember" the current state to return to it. The classic situation where this occurs is where there are recursive calls to a Global Logic. Consider a global logic with a series of local variables which makes a call to itself - the state of those variables before the call needs to be stored, then the global logic is called from itself and new values are used. The global logic then exits back to itself and the original values are restored. So any Global Logics calling other global logics need to use this space to store the state of local variables - so look at recursive or deeply nested global logics. In certain circumstances you might be calling to a greater depth. Other calls can use up this space (just to handle the return point) but tend to only occur if something is wrong - for example you can LSCALL an LS from within itself (or from a chain of LS) until all the stack space is used up (or a CALL within logic) - you can easily show this in a simple function, just have the logic LSCALL(1) in the Default logic of LS1. It might be worth just checking if there is a situation where the are a set of LSCALL statements that there is not a situation that can occur where they never return - for example in your 64 characteristics you might LSCALL(4) which does an LSCALL(10) which does an LSCALL(60) which in some rare case does an LSCALL(10) - therefore setting up a loop that will run until it runs out of workspace.
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users