Category: White Papers

Deploying a Zim application running in Zim 9 means making the application available for general use by one or more users. In other words, it means “transporting” a Zim application system that is in the development environment to the production environment.

A deployed application is different from an application under development because users don’t create new objects, nor change or remove existing ones. Usually, all Zim programs are compiled and accesses to data are restricted to programs functionality. Also, development tools, special files and specific portions of the database might not be needed under normal usage conditions.

Since Zim 9 is much simpler to use, there are only two alternatives to deploy a Zim application:

1) Deploy the application as it is in the development environment with little or no concern for what is going to be visible by users. In essence, the deployed application is just a “copy” of the development environment (with no data, of course). Zim programs can compiled or not compiled. Zim Data Dictionary files are also present;

2) Deploy only the portions of the database required for production. All programs are compiled. The following chart describes what is going to be deployed:

The optional portions, above, have some exceptions:

• If the application system will have ODBC Driver access from thirty party tools, then the Data Dictionary files must also be included because the ODBC Driver inquiries the existence of entity sets and relationships at connection time;
• If the application can suffer modifications (like program modifications or data dictionary modifications) then both the Data Dictionary and source code must be present. Zim 9 allows data dictionary modifications while users are running, thus requiring these files as well (see the command SET DATABASE ACCESS).

In either way and regardless the above discussion, a Zim application is run with Zim Server running and:

• on Unix, users run the application using the ZIM executable;
• on Windows, users run the application using the ZIMTC executable.

On Windows, Zim stores basic information in the Registry, like environment variables, options, etc.

The ZIM and SQLCPI environment variables

The ZIM and SQLCPI environment variables are located in the registry at

/HKEY_LOCAL_MACHINE/SOFTWARE/Zim Corporation/Zim//Zim

where version number is the version of Zim that you are currently running.

The ZIM environment variable tells where the Zim software and its components are installed.

The SQLCPI environment variable tells where the Server Access Modules are installed. Normally, its address is the same as ZIM.

Special options for the user

Zim accepts some configuration options passed via the zimconfig.zim configuration file that are valid for all users connected to a particular database application.

However, sometimes is needed to specifically set some options only valid for the current user logged in a particular machine. These options are stored in

/HKEY_CURRENT_USER/SOFTWARE/Zim Corporation/Zim//Zim/ZIM

Zim, at start up, reads these options and uses them during the session. These options can be read or changed using the functions $GetProperty and $SetProperty with the REG option.

The currently available options of importance to users are described below. Some options present in the above location are set dynamically by Zim components and should not be changed manually.

Backscreen Menu

With the following entry in the registry

Backscreen Menu = 0

the backscreen menu does not display. The default value for Backscreen Menu is 1.

Editor

The EDITOR option describes the default editor for the Zim session. An example of an editor setting might be

Editor c:myEditor.exe

TUI Simulation Font
TUI Simulation Fontsize

Describe the font and the size of the font used to simulate text applications.

The default TUI Simulation font is “courier new bold” size 10.

TUI Simulation font=Courier
TUI Simulation fontsize=8

A font can be bolded by adding the case sensitive keyword Bold to the fontname, as shown in the following examples:

TUI Simulation font=Courier Bold

or

TUI Simulation font=Bold Courier

The simulation font is used for all controls.

The FixedSys font is used by TUI applications on Microsoft Windows. However it usually comes in only one size so that all controls use the same size font. This restriction can  result in it being clipped in comboboxes and pushbuttons.

Large Toolbuttons

Describes the size of the buttons to be displayed in the tool bars. the font and the size of the font used to simulate text applications.

Example:

Large Toolbuttons 0

3D

It describes the 3-dimensional appearance of Zim widgets.

Example:

3D 2

Enhanced Testing & Debugging

Benefit:

• Efficiency: By capturing and replaying form inputs, developers can automate repetitive testing tasks, saving time and reducing manual effort.
• Accuracy: Replaying captured inputs ensures consistent test conditions, helping to identify and resolve issues more reliably.
• Comprehensive Coverage: Developers can create detailed test scripts that cover various scenarios, improving the overall quality of the application.

Technical Expansion:

• FORM SET SAVE ON: This command initiates the capture of keystrokes during FORM INPUT. All keystrokes, including characters, numbers, transmit keys, and control characters, are stored in a script file called zfmkeys.
• FORM SET SAVE OFF: This command terminates the capture process and closes the script file. The captured keystrokes can then be reviewed and analyzed.
• FORM SET INPUT ON: This command starts replaying the captured keystrokes from the zfmkeys script file. Zim reads the keystrokes from the script file instead of the keyboard, simulating the exact input sequence.
• FORM SET INPUT OFF: This command stops the replay process, allowing developers to control the duration and scope of the test.

Engaging Product Demonstrations

Benefit:

• Interactive Demos: By replaying captured form inputs, developers can create dynamic demonstrations that showcase the application’s functionality in a realistic and engaging manner.
• Consistency: Replaying inputs ensures that each demonstration is consistent, highlighting the application’s features without variation.
• Ease of Use: Developers can easily set up and execute demonstrations, making it simpler to present the application to potential users and stakeholders.

Technical Expansion:

• Script File Management: The zfmkeys script file can be copied and managed using operating system commands, allowing developers to create multiple scripts for different demonstration scenarios.
• Terminal Independence: The script file format is independent of the terminal used to create it, enabling demonstrations on various terminal types without compatibility issues.
• Platform Considerations: While the script file format is dependent on the platform, developers can manage and replay scripts within the same platform environment, ensuring smooth demonstrations.

Example Workflow

1. Capture Input:
   • Execute FORM SET SAVE ON before starting the application to initiate capturing.
   • Proceed with the application, capturing all keystrokes during FORM INPUT.
   • Execute FORM SET SAVE OFF after the application terminates to close the script file.
2. Replay Input:
   • Execute FORM SET INPUT ON to start replaying the captured keystrokes.
   • Watch the application simulate the input sequence, demonstrating its functionality.
   • Execute FORM SET INPUT OFF to stop the replay.

Caveats

• Avoid Overlapping Commands: Ensure that capturing and replaying commands are not executed simultaneously to prevent conflicts and data loss.
• End Replay Appropriately: Always terminate the replay process once the script file has been exhausted to maintain control over the demonstration.

By leveraging these features, Zim application developers can enhance their testing and debugging processes, create engaging product demonstrations, and ultimately deliver higher-quality applications.

Permissions

A permission mask is assigned to all application directories, to all EntitySets and relationships, and to all fields in EntitySets and relationships. The permission mask indicates the type of access that particular user IDs are to have to the object.

The possible permissions for EntitySets and for relationships are READ, ADD, CHANGE, and DELETE. ADD, CHANGE, and DELETE automatically enable you to READ the data.

The possible permissions for directories and for fields are READ and UPDATE. UPDATE automatically enables you to READ the data.

Ownership

The creator of each directory, EntitySet, or relationship is the owner of that object and of the fields in it. The owner of the Object Dictionary EntitySets, created when the new application database is initialized, is any user whose UserID is 0.

Owners can set and change the permission mask for the objects they own. Individual permission masks can be set for

For example, the owner of an EntitySet can grant permission for all users in his or her group to ADD data to an EntitySet, but might restrict other users (not part of the group) to READ only. In addition, the owner can restrict access to certain fields in the EntitySet: for example, by assigning READ access for users in the group and no access for other users.

Permission Checking

Each time that a user tries to access the data in a directory, an entity set, a relationship, or a particular field, the permission mask that is in force for the object is checked against the system variables $ZUserID and $ZGroupID.

First $ZUserID is checked to see if the user is the owner of the object. If the user is the owner, the object’s owner permission mask is used to determine if the user can perform the requested operation. If the user is not the owner but is in the owner’s group, the object’s group permission mask is used to determine if the user can perform the requested operation. Otherwise, the object’s others permission mask is used to determine the user’s access.

Effects on Commands

The applicable permission mask has an effect on command execution. You must have READ or UPDATE permission to access an application directory. You must have UPDATE permission to CREATE, ERASE, or RENAME objects in an application directory.

For example, if you enter

access EmployData update
change NewEmps1 from Employees
add NewEmps2 from Employees
create index NewEmps2.FirstName

you must have at least READ permission in order to access the directory EmployData. To make changes to the definitions of the objects in that directory, you need UPDATE permission.

You must have READ permission for the two commands involving the Employees EntitySet. In addition, you must have CHANGE permission for NewEmps2 and ADD permission for NewEmps2. You must also have READ permission for any fields in Employees that you are using, and UPDATE permission for the fields in NewEmps1 and NewEmps2 whose values you are adding to or changing.

When you create an index for NewEmps2.FirstName, you must have UPDATE permission for the directory EmployData (assuming that NewEmps2 is defined in that directory).

If you enter

delete all Employees where LName = Smith

you must have DELETE permission for Employees.

If you lack a required permission at the directory, EntitySet, or relationship level, the command does not execute; an error message is issued. If, at the field level, you attempt to read data from a field for which you do not have READ permission, the result you obtain is $Null; if you attempt to assign a value to a field for which you do not have update permission, the assignment is not made. No error messages are issued.

Changing Default or Established Permissions

When an object (other than a directory) is created, it has all possible permission for the owner, READ permission for the owner’s group, and no permission for all others. By default, newly created directories give READ and UPDATE permission to all users.

To change the permission masks, the owner (or the super user) uses the PERMISSION command. The permissions mentioned in the PERMISSION command are always added to the existing permission mask for that object.

In the following example

permission Employees other read add
permission WorkOn group read add change delete
permission Projects other
permission LName group update
permission Salary group other
permission ENum owner read

Employees and Projects are EntitySets, WorkOn is a relationship, and LName, Salary, and ENum are fields. Note that you can leave permissions blank; the affected users cannot access the objects at all.

Object permissions

There are two types of permissions – object permissions (EntitySets, relationships, and directories) and field-level permissions. Field level permissions take precedence over object permissions. The permissions are set as follows:

The following chart summarizes the permissions needed in order to successfully execute a given form of data manipulation on an object where permissions are currently in place. Definitions are as follows:

• Owner refers to the user who created an object.
• Group refers to any user who shares a common group ID with the object’s owner.
• Other refers to any user who does not share a common group ID with the object’s owner.

Note: Any user with a GroupID equal to 0 is considered to be a superuser. Superusers are not governed by permissions currently in place on objects, fields, or both. Thus, an object is created by a person logged in as superuser, then permissions applied to the Group are ignored since every user in the creator’s group is a super user. It is not advisable to create objects while logged in as a superuser, in order to take full advantage of Zim’s security features. Different permissions can be assigned to objects, fields, or both for users inside the owner’s group (Group) and to users outside the objects’ owner group (Other).

where R = read, A = Add, C = Change, and D = Delete

(1) Null values for all fields with no update permission

An ASN is simply defined by letting the Reqd attribute of a field to be “Seq” and having the corresponding Entity-Set or Relationships with fields created (or recreated). To ensure proper handling of the existing data, it’s strongly recommended to use DC to perform this operation.

The next step is to set the initial value for this ASN like in these examples:

SET SEQUENCENUMBER MyEnt 1

SET SEQUENCENUMBER AnotherEnt 1000

SET SEQUENCENUMBER Customers 5000001

See the documentation of the command SET SEQUENCENUMBER for details.

The Automatic Sequence Numbers (ASN) is a ZIM feature that allows a field from Entity-Sets or Relationships with fields objects to get its value automatically incremented by one every time a record is added to this object. Usually, such sequential fields are used in these objects to supply a primary key, wherever one is missing. In particular, ASN can be very useful when ZIM is operating in Client/Server mode, where a primary key is required for the correct operation of sets.

An ASN is a positive number ranging from 1 up to a 15-digit number. Any Entity-Sets or Relationships with fields can have one of such ASN. To start its normal operation, each ASN must be initialized with a proper value.

This field is defined as “Seq” in the Required attribute and can have any type and length, indexed or not, provided that the field attributes can hold the ASN (for example an Int of 5 can only hold an ASN up to 32767). Normally, an ASN is defined as a VastInt type with the length of 15 and zero decimals.

ASN can have its value reset at any time and can be disabled and enabled every time needed (for instance, when downloading and uploading existing data to a such object, the ASN must be disabled in order not to let new sequence numbers to be assigned to existing records).

Although ASN can be easily defined manually, it is recommended to use DC to perform this operation since existing data can be handled properly.

Once defined, adding records to objects containing ASN will increment the corresponding field by one, starting from the initialized value. In fact, the first record added in this way will have the initialized value, the second this value plus one, and so on.

An ASN field is always required. By default, all ASN are enabled. However, they can be disabled and enabled again any time using the command SET SEQUENCENUMBER. In such a way, the field containing the ASN is treated this way:

• if ASN is enabled, the corresponding value of the field will always contain the ASN, even if direct or indirect assignments are provided for this field. The last value used in any ASN can be retrieved using the function $ZIMSeqNum;
• if ASN is disabled, its field has all normal properties defined by ZIM. The Required attribute, however, remains “yes”. Default value and direct or indirect assignments are applied according to ZIM rules. During the time the ASN is disabled, the automatic sequencing is not accomplished and, as soon as it is enabled again, the sequencing resumes from the point where it has stopped.

The ASN are implemented via a special file called “sequence.zim” in the database path. This file should not be touched unless using DC or the command SET SEQUENCENUMBER.

During normal operation, the execution of an ADD command over an object that contains an ASN will always return the ASN itself or the $Null value whenever an error is detected (these errors are always caused by the corresponding file handling). ASN never raise a deadlock condition. However, if in the course of the ADD processing or in the course of the transaction processing where the ADD is located a deadlock or an error condition is raised which causes the transaction to be terminated, the acquired ASNs are lost. Upon restarting the transaction, new ASN will be taken.