Category: Commands

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.

Once you have developed an application system, you have four alternative approaches to using it.

1. You can choose not to compile any part of the application.

You can compile the programs at any time during the development of your application. We recommend, however, that you test and debug all programs fully before compiling them, as testing and debugging are most easily undertaken when executing interpretively.

2. You can choose to compile only certain critical programs.

If you choose to compile only those application programs that are used frequently or that require considerable processing time, the performance of your application improves.  You can still modify the application easily –  non-compiled programs can be modified without being re-compiled. The resulting application could be run on the Development system or the Professional Runtime system.

3. You can choose to compile the entire application.

This alternative gives you better system performance than alternative two. It also prevents unauthorized alteration of the programs that control the application. Application users are still able to formulate ad hoc queries and reports. Application users with a Development system can add their own documents (including additional programs), entity sets, relationships, and so on, to the application, because all application development features are present (see Deploying a Zim Application for further details on which files you can make available to users).

The Zim Compiler is used to compile application programs.

The Compiler reads the programs that you have written (source code) and produces object code. The compiled code is placed into a disk file separate from the disk file that contains the source code.

The compiled version of an application program is semantically equivalent to the source program, but can be executed more efficiently, because syntactic and semantic analysis is no longer required.

Compiled programs are encrypted and are therefore completely unreadable by others. You can distribute this unreadable (and un-modifiable) version of your program, thus protecting your source code from unwanted viewing and modification.

Compiled programs can be run by the Development system, the Runtime system, or the Professional Runtime system. The Runtime system is a special, concise version of Zim; it can run only fully compiled applications. The Professional Runtime system is similar to the Runtime system, but it also enables ad hoc query and report commands to be executed interpretively.

To benefit from the Compiler, you do not need to compile all of the programs in an application. Compiled programs can call uncompiled programs, and vice versa. However, if you do compile an entire application system, you can run the application using the Runtime system, which occupies much less memory than the Development system or the Professional Runtime system.

Note: The Professional Runtime system and the multi-user Runtime system are optional products that are not automatically included in the basic software package. If you wish to obtain these optional products, contact ZIM Technologies International Inc. The single-user version of the Runtime system is included in the basic software package as a “right-to-copy” package.

To be compiled, an application program must meet the following requirements:

• The program can not include commands that assign values to macros such as

let =’Employees’.

• The program cannot call local macros (i.e., <0> to <9>).

• The program can call global macros (i.e., ), but the compiled version uses the value of the macro as it existed at compile time. Later changes in the value of the macro have no effect on the compiled code.

• The program cannot include object manipulation commands (commands that define, create, or erase objects). Application objects must be defined outside of compiled programs.

Note: The CREATE INDEX and ERASE INDEX commands can be compiled.

• The program cannot include the commands COMPILE, PARSE, and GENERATE (the Compiler ignores these commands).

• The program cannot include the ACCESS and RELEASE commands (the Compiler ignores these commands).

• Care must be exercised if the program uses temporary result sets. Anomalies can occur when commands that produce temporary result sets are compiled (see The Correct Use of Objects in a Compiled Program, for more information).

You should thoroughly test and debug all programs belonging to an application before compiling them.

Furthermore, before you compile an application program, you can also use the PARSE command to assist you ensuring that the program is syntactically correct.