Chris Pepper

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.

Enjoy the trip! Sounds like a lot of fun.

OK - re-reading the manual suggests that SUPPRESS_RETRY() may only work on a secondary read.

Try setting up the update as:

Primary File XXXX L
02 XXXX D

(i.e. have the file in twice with the Primary in L mode, then as the second file in D mode (with the SUPPRESS_RETRY Lock logic on File 2).

In the Lock Logic (in the Update) you need to put the code:

SUPPRESS_RETRY()

This tells the Function to stop waiting on the lock on this record.

Thanks for all the advice.

Just to note that we have been distributing all our Oracle and DB2 code under 4.6 and 5.5 for ages (more than 10 years) now, so we have no problems with variable naming that were not fixed a long time ago. It's just our development environment that we are moving to 5.5. We have very sophisticated mechanisms for translating the native isam code into Oracle compliant code as part of the automatic gen process before delivery. Now that most of the installed base is Oracle it makes sense to develop directly in an Oracle environment.
The changes are primarily in the interface with our code repository - when a developer checks out code in the new system we have to recognise that it was last saved from Isam then apply the code conversion as the source code is loaded into the development environment. Primarily this is because some of the alternate File Definitions had key structures that were not Oracle compliant (different numbers of key parts) so the code is automatically rewritten. Also any embedded SQL must be written as comments in the Isam code, then uncommented in the Oracle code.

I've had a couple of issues with 5.5, mainly where the Import/Export was applying tags to the code - but I only needed it to bootstrap the routines to interface with the code repository. Now I have them loaded and working I don't need Import/Export so tags are no longer an issue. Fortunately we're not using the ProIV GUI so I don't need to support any of the GUI features which seem to have lots of additional options.