Category: ZIM 4GL Language Reference

You can use one of the following methods to determine if a program has been compiled:

• Use the $compilestatus function to check the compilation status of the program.
• Run the Object Browser ( ZXLISTER) administrative utility. Any application document containing a compiled program shows a “-c” suffix following the file name.
• Attempt to use the EDIT command to edit the program from within Zim. If the program has been compiled, a warning message is issued.
• Issue a SET FLOW ON command. With FLOW set to ON, any call to a procedure produces a message indicating if the calling procedure is a compiled program.
• Uncompile the program using the UNCOMPILE command. If the program was not compiled, an error message is issued.

You can recompile an application program at any time. Recompiling replaces the existing compiled version of the program with a new compiled version. Recompiling is necessary if a compiled program becomes invalid for one of the following reasons:

• The source version of the program has been updated.

Changes to the source program are not automatically reflected in the compiled version. Re-compile the program after making the changes. (The software issues a warning about this situation when you execute an EDIT command involving an application document that contains a source program.)

• Objects have been changed.

Changes to objects (through the CREATE and ERASE commands) invalidate all compiled programs that use the affected objects. Ensure that all such “out-of-date” programs are re-compiled.

Zim provides mechanisms for automatically storing dependency information (e.g., a program’s references to objects). (For more information, see the DEPENDENCY command).

Source and compiled programs sometimes behave in different ways, particularly in how they treat certain objects. Special considerations apply both to permanent objects and to temporary objects (i.e., temporary result sets).

Within programs that are to be compiled, references to result sets (created by set-processing commands) require special care.

References to result sets can create problems, because the order in which the Compiler processes a program could be different from the order of execution. Problems can be avoided by creating permanent result sets (set objects) in the application database and ensuring that SET CHECKSETS enforces the consistency of temporary result sets.

Most problems with references to named sets can be alleviated by adhering to the following guidelines:

• Qualify set operations by explicitly giving the set name where possible (e.g., next set1, top set1) rather than letting the software implicitly assume the current set.

• Declare set objects in the database, forcing the software to check the structure of result sets that employ a particular name.

• Always give a set an explicit name.

• Never use the same name for sets whose component structures are different (see Example 4 and Example 5). With SET CHECKSETS ON, the software enforces this recommendation.

• Use the SET CURRENTSET command to specify the result set that is to be the current set in a particular situation.

The Compiler works from top to bottom through a program, reading every command line and disregarding programming structures and the flow-of-control commands (such as IF&ldots;ENDIF, WHILE&ldots;ENDWHILE, BREAT, CONTINUE, RETURN, STOP, and BYE). During compilation, the software creates a result set for every set-processing command that implicitly or explicitly produces a result set.

For example, compilation of the command

find Employees WorkOn Projects where DeptNum = ‘D01″ -> EmpSet

results in the creation of a result set called EmpSet. The components of EmpSet are Employees, WorkOn, and Projects, in that order.

When the Compiler creates the result set, it is concerned only with the structure of the set (i.e., the components and their order). If EmpSet is a set object, its structure (as defined in the Object Dictionary) must match the structure used in the application program statement.

Two situations exist in which problems can arise when references to result sets are compiled:

• Implicit references to the current set.

In certain commands (e.g., LET, IF), a reference to a database field implicitly means that field in the current result set.

When a program is executed interpretively, the current result set is the set produced by the most recently executed FIND or SET CURRENTSET command.

When a program is being compiled, the current result set is the set produced by the most recently encountered FIND or SET CURRENTSET command.

Because the Compiler works top-to-bottom through a program, at some point in the body of the program, the current set last encountered can differ from the current set that would have been last produced were the program being executed interpretively.

• Re-use of the name of a temporary result set.

All temporary result sets are created in the session directory.

When a program is executed interpretively and a result set name is re-used, the new version of that result set – produced by the most recently executed set-producing command – replaces the original version.

When a program is being compiled and a result set name is re-used, the new version of that result set – produced by the most recently encountered set-producing command – replaces the original version.

Because the Compiler works top-to-bottom through a program, at some point in the body of the program a particular set name can refer to a set whose structure differs from that of the set that would be in effect were the program being executed interpretively.

This situation can be eliminated by having the software check that the structure of a temporary result set never changes during an application session (SET CHECKSETS ON), or by using a set name for which a structure has been permanently defined (set object).

In the context of compiled programs, the term permanent object refers to any object that, once created in the application database (based on a definition in the Object Dictionary), persists until erased. Permanent objects include EntitySets, relationships, roles, application documents, application directories, windows, menus, displays, forms, constants, variables, and permanent result sets (set objects).

Application programs are compiled in the context of the permanent objects that are available at the time of compilation; that is, all objects in the application directories that are accessed at the time that the COMPILE command is executed.

Within the program being compiled, ACCESS or RELEASE commands – which affect the application directories that are available, and, by extension, the permanent objects that are available – are ignored.

References to permanent objects are compiled into explicit references to specific objects in specific application directories. As a result, at execution time, the compiled program is independent of the currently accessed directories; all permanent object references have already been resolved.

One exception to this rule occurs when a compiled program calls another program. Zim seeks the called program in the currently accessed application directories. If the software finds the called program there, it determines if the program has been compiled and executes the compiled or source version accordingly. If the software fails to find the called program within the currently accessed application directories, it attempts to execute the compiled version of the called program (if a compiled version exists).

With a few exceptions, all Zim application programs can be compiled. Compiling one or more programs in an application carries several benefits, including security, speed of execution, and minimized resource use.

This section discusses the compiler, prerequisites for compiling programs, adjustments to be made to application programs before compiling, and the commands used to compile or uncompile programs.

For more information refer to the following sections:

The Compiler

Available Commands

Using Compile Programs

The Correct Use of Objects in a Compiled Program

Deploying an Application

A compiled program is called in the same manner as any other application program. For example, if you have compiled a procedure program called RunTest, call it as follows

RunTest ()

Appropriate expressions would be entered within the parentheses (if required).
If it is necessary to run a program disregarding its compilation, the command:

SET RUNTIME ON/OFF

temporarily enables or disables the execution of compiled programs.

Normally RUNTIME is ON, and, when a compiled version of an application program is available, the compiled version is executed.

When RUNTIME is set OFF, the compiled versions of all affected application programs are ignored. RUNTIME can affect all application programs subsequently executed, or only those called from the current procedure.

The disk location of compiled programs is pertinent only if you are copying the application database to another location, managing disk space, or building a fully compiled application.

Each compiled program is stored in a separate file with the same name as the source code file in a directory of the operating system that corresponds to the physical file of the Zim directory that the compiled document belongs. For instance, if a Zim program belongs to ZIM directory, than the corresponding compiled code will be store in the operating system directory called “zim0001.ws” because ZIM directory is stored in file zim0001. In the same way, if the application has a Zim directory called Sales stored in file zim0102, then all compiled files belonging to this Zim directory will be store in the operating system directory zim0102.ws.