Overlays

You can call one QA Build program from another; for details see Calling QA Build Programs . When you do this, the called program is called an overlay. Overlays are useful in the following situations:

• The two programs combined into one are too big to compile
• The combined program is not too big to compile, but compilation takes a long time and you are still at a development stage where a lot of changes are being made. The run time penalty of switching overlays is trivial in comparison
• The combined program is not too big to compile, but it is too big to be run with the debugging option

Only in the first case should the final version retain the overlays, so it is only there that you need consider how most efficiently to divide the procedures between the two programs.

Select a natural break wherever possible – that is, a point in the program that is not often traversed, for example, after completing some initialisation or before entering a repeat loop constituting the main part of the program.

After executing an overlay with %call, control returns to the calling program which has to be re loaded. So, if the program logic allows a choice:

SMALL1 LARGE2
| is better than | 

LARGE1 SMALL2 

and

If you use the command tail %overlay, the values of all variables and table.roles which are processed in both the calling program and in the overlay will be passed between them. However, you must not use the value in a formula before it is declared it. Consequently you must name the table in your Table processing or the local field in your Field processing.

Remember also that there must be no gap in the chain that passes values from one program to another.

It is good practice to put all the necessary declarations into the root procedure, especially if the overlay structure is only temporary, and to refrain from putting anything else in that procedure. This makes it a simple matter to re assemble the parts into a single program: