How the Test Application Is Built: Procedures
On most systems, as a default, the Go operation runs an application interpretively. This does not include host-language procedures, which are maintained in compiled form and linked into the test application.
If no host-language procedures are defined for the application, the Go operation runs the application using a special interpreter which it places in a file in the Ingres system binary directory, named:
Windows: %II_SYSTEM%\Ingres\bin\iiinterp 
UNIX: $II_SYSTEM/ingres/bin/iiinterp 
VMS: II_SYSTEM:[INGRES.BIN] iiinterp.exe 
If host-language procedures are defined for the application, the Go operation runs the application using a separate interpreter that it creates and places in the application's object code directory. This interpreter file is called:
Windows: iiinterp 
UNIX: iiinterp 
VMS: iiinterp.exe 
How ABF Handles Dependencies
ABF handles dependencies among frames and other application components by performing several types of checking as you develop an application. Based on this checking, ABF determines whether to automatically recompile a frame the next time the application is built.
In the first type of checking, ABF keeps track of the components on which a frame depends. If any component changes, ABF automatically recompiles the frame at the next application build. This happens in the following four types of dependencies:
• A frame calls another frame and gets a return value from that frame. If the return type of the second frame changes, the first frame is recompiled.
• A frame uses a global variable. If the global variable changes, ABF recompiles the frame.
• A frame has a variable of a record type. If the definition of the record type changes, ABF recompiles the frame.
• A frame uses variables of a type of form or type of table. If the underlying form or table changes, ABF recompiles the frame.
ABF does not compile all called frames or procedures. In the following cases, ABF cannot tell the name of the called frame or procedure at compilation time so the called frame or procedure cannot be compiled:
• When you use a variable to represent a called frame or procedure in a callframe or callproc statement. For example, the frame represented by the variable nextframe is not compiled:
callframe :nextframe
• When a called SQL procedure calls a 4GL frame or procedure using an exec 4GL statement. For example, the procedure "procname" is not compiled:
exec 4GL procname
In the second type of checking, ABF allows you to modify global or record attributes of a record type used in an application, but does not allow you to delete or rename the record type. ABF notices if you have modified the record type and automatically recompiles frames that use the record type.
In the third type of checking, ABF does not allow a record type to contain an attribute of its own type. This is not allowed even if there are steps in between. For example, if record type A includes an attribute of type C, C cannot contain an attribute of record type A.
The fourth type of checking concerns the Go operation. The Go operation involves the frame from which you choose Go (the start frame for the test build) and all of its children. Two types of components must be error-free, the start frame and any 3GL procedures you have written. When you choose Go from a frame that is not the application start frame, ABF checks this frame and all of its children to see if they need recompiling. It does not check anything outside of this line of dependencies.
For example, frame A calls frame B, B calls C. If you run B by selecting Go, you cannot call A. You can go only to children of B, not to the parent frame A. When ABF checks that frames must be recompiled, it checks B and all of B's descendants.
For more information on callframe and writing 4GL specifications, see the 4GL section of this guide.
Last modified date: 01/30/2023