Hi,

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:
Logics:38006
Global Logics: 6598
Formats: 2
Fields: 4284
Base: 0
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?
Thanks!

Steve

Hi Steve

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.

Regards
Steve Houghton

Thanks Steve,

I don't think there's a fault in the function because (as an example) the function was giving us the error and by defining some scratch vars it worked again.


Steve

Steve,

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....

Rory

As I recall there are environment variables that can be set that control the spec size and data buffer size that a PROIV function uses and these are available is version 5.5. I have looked at the version 6 manuals and I think I have found them. Go to

http://support.proiv...cumentation.htm

...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

We have lots of experience with workspace issues and have done quite a bit of work understanding them.

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.