Categoria: Advanced Topics

A keyword is a user-defined string that is associated with an object. Any number of keywords can be assigned to an object; keywords can be added and deleted at any time. You can then use the keywords to select objects to process. For more information on methods for assigning and deleting keywords, see Processing Options.

Keywords have many uses. Most often keywords are used to classify the objects in an application. For example, you can assign different keywords to identify the objects in the different subsystems of your application.

ZOMSet *Contracts* ;k Contract_System

ZOMSet *Receivables* ;k Receivable_System

You can classify your objects based on type, as shown in the example below:

ZOMSet +t Win, Form ;k UserInterface

ZOMSet +t Ent, Rel, Role ;k Database

However, keywords can also be used as a quick means of accessing a specific set of objects. For example, the following example associates the keyword “Just_ReCreated” to the objects processed by the ZOMReCreate service:

ZOMReCreate +t ent,role ;k Just_ReCreated

This gives you quick access to this set of objects for further processing,  as shown in the following example:

ZOMList +k Just_ReCreated

Keywords can be used in many other contexts; you are limited only by your imagination.

You can lock an object so that its definition cannot be changed by any ZOM service (until it is unlocked). When an object is locked, it cannot be erased, deleted, destroyed, recreated, moved, renamed, and so on. Locking an object is similar to write protecting the object.

You can set and reset the locked property for an object(s) using the ‘L’ property indicator and the ZOMSet service. For example, to lock all objects named Employees, enter

ZOMSet Employees ;p l

To unlock the same objects, use the negation indicator (!) as shown below:

ZOMSet Employees ;p l!

If you lock a Zim directory object, all the objects belonging to that directory are implicitly locked as well. Thus, the following example locks all objects in the Release3 directory:

ZOMSet Release3 ;p l

Unlocking a directory object implicitly unlocks all objects belonging to that directory that have not been explicitly locked individually.

Note: A ZOM lock locks the object only as far as the ZOM services are concerned. A ZOM lock does not prevent the object from being changed directly using the standard CREATE, ERASE, and RENAME commands. However, changes made in the Development Center, where ZOM is always enabled, respect any object locks.
Locks in ZOM are separate from locking enabled in multi-user applications to control concurrent access to a database.

ZOM provides many services and features that have been described above for inspecting and manipulating the objects in your application to resolve problems (finding dependent, depending and unreferenced objects and objects that do not exist, for example). In addition, ZOM provides two special services to help you analyze problems in your application:

ZOMDiagnose, ZOMViewLog

The ZOMDiagnose command analyzes the objects in your entire application and their interdependencies. Any inconsistencies discovered are reported to you for further action. For example, suppose an attempt to recreate an EntitySet, Employees, has failed, leaving several relationship and role objects that depended on the EntitySet in an invalid state. ZOMDiagnose discovers these problems and reports them to you. A report is presented that itemizes the objects requiring attention. A sample of this report is shown in ZOMDiagnose.

The ZOMViewLog command enables you to browse the ZOM activity log. In the log are progress reports from the ZOM services you have executed as well as any error messages encountered. You can peruse the activity log to discover why certain operations did not succeed.

For example, to find out why the EntitySet mentioned above was not recreated after executing, enter

ZOMReCreate Employees

To inspect the activity log, enter

ZOMViewLog

The error messages in the log lead you to the problem. If many objects were processed, iterate through the objects until all are processed properly.

Note: In the case of creation failures, you can also try to create all objects that do not exist (on the assumption that the create operation failed for these objects), then look at the activity log for all these objects at once. This bulk create can be accomplished by entering
ZOMCreate +pe!

ZOM tags each object with a unique key called the object key. The ObjectKey uniquely identifies an object, even in computing environments where the development tools are not live-linked by means of a network.

Some characteristics of the ObjectKey are as follows:

• ObjectKeys are hidden from the user.

• ObjectKeys are automatically generated by the tools when an object is created. Once an object is created, it keeps the same key for its entire existence.

• When an object is destroyed, its ObjectKey is never re-used.

• ObjectKeys have no semantic content. They describe nothing at all about the object they point to, but instead serve only as a unique identifying string.

• If the same object exists in more than one tool or environment, its ObjectKey is the same value in all tools that manipulate or reference the object.

Two advanced selection criteria are described for selecting objects when using the ZOM services.

SELECTING BY QUERY PROGRAM

The Query Management Services (e.g., DPSMakeQuery) can be used by advanced ZOM users to write programs that select objects for use by ZOM services. These queries must be written such that they produce a set of ObjectList entities named “InputCLObjSet”.

An example of such a query, called “Find_ZZZ” is shown below. It finds all objects starting with the string “ZZZ.” It is created using the command DPSMakeQuery.

%% Query: Find_ZZZ

all ObjectList where ObjectList.ObjectName like “ZZZ%” -> InputCLObjSet

This is then used to list the objects found as shown below:

ZOMList +q Find_ZZZ

The query option can also be used in conjunction with other criteria. The following command finds all EntitySets, except those found by the query Find_ZZZ:

ZOMList +t Ent -q Find_ZZZ

ZOM stores and manipulates information in the Zim Object Dictionary. This information is stored in fields in the Object Dictionary tables, and additional tables.

ZOM Fields in the Object Dictionary

ZOM uses the following fields in the Object Dictionary EntitySets EntitySets, Relationships, Roles, Fields, Documents, Windows, Displays, Forms, Menus, Directories, Variables, NamedSets and Constants:

The ObjectList EntitySet

The ObjectList contains the registration data for an object in ZOM. It also stores a number of status values and flags which are maintained by ZOM as it performs its actions. The fields in ObjectList are:

The Keywords EntitySet

The Keywords EntitySet records the keywords assigned to objects.

The Dependencies EntitySet

The Dependencies EntitySet records interdependent object keys, indicating that a given object depends on another object. This information is deduced at runtime by the ZOM services and should be considered read-only by all other users and processes.

The Shadow Object Dictionary

A number of EntitySets, known collectively as the Shadow Object Dictionary, implement an exact duplicate of the Zim Object Dictionary. Each table starts with “sh”, followed by the name of the Object Dictionary table it duplicates, ShEntitySets for example. The Shadow Dictionary is used by ZOM to compare different descriptions for objects (for example, in the ZOMDiff command) and as a staging area for importing and exporting object descriptions.

When ZOM services are being used from the command prompt, the general syntax is

service << selection >> << ; option >> [> target]

The selection item(s) specify which objects are to be processed by the service. If more than one selection item is specified, the criteria are applied left to right. All ZOM services are set-oriented and can operate on more than one object at a time.

The option item(s) are used to set properties and control the behavior of the service.

The target determines the new location for any objects copied or moved by the service.

Let’s examine a basic use of the ZOMList service:

ZOMList Contracts ;v

In this case, the selection is Contracts, the option is ;v, and there is no target specified. This example lists information on objects named “Contracts”. The ;v option causes a verbose listing to be produced.

Some services enable the specification of a target using the optional target specification. For example, in using the ZOMReName service to rename an object, the new object name is specified as the target of the operation, as shown below:

ZOMReName Custs > Customers

In this case, the selection is Custs, there is no option specified, and the target is Customers. This command changes the name of the object named “Custs” to “Customers”.

How to select objects is described in Select Objects for Processing, beginning with Selecting a Set of Objects. Processing options are discussed in Processing Options.

Some objects contain persistent data (i.e., EntitySets and relationships with fields). When changing the definitions of objects containing persistent data using the ZOM services, you can choose to have the data preserved or discarded. You indicate that data is to be preserved for an object by setting the datasave property.

You can set and reset the datasave property for an object(s) using the ds property indicator and the ZOMSet command. For example, to set the datasave property for all objects named Employees enter

ZOMSet Employees ;p ds

To reset the property, use the negation indicator (!) as shown below:

ZOMSet Employees ;p ds!

An object with the datasave property automatically has a datasave document associated with it. Data is always preserved by the commands ZOMReCreate, ZOMCreate, ZOMErase, and ZOMMove.

Note: ZOM automatically generates the names of datasave documents when it needs to use them so you do not need to know or remember the names. Like all objects, the datasave documents are registered in ZOM. However, they are automatically flagged as inactive so that they are not normally retrieved by ZOM commands such as ZOMList unless the i option is specified.

In particular, with the datasave property set, these commands are affected as follows:

Note: The correct saving and restoring of data depends on a datasave document existing before the object is erased. The above ZOM commands ensure that the datasave document exists. However, if an object has not been created by ZOM or if an object has been recreated outside ZOM, the datasave document does not exist or does not have the correct format and the data preservation does not function properly. The ZOMDataSave command can be used to correct this situation. For example, the following example creates datasave documents for all EntitySets or relationships with fields:

ZOMDataSave +p da ;q

ZOMDataSave and its companion command ZOMDataLoad can be used to create datasave documents with a specific name, to save data in an object or load data into an object, and to generate Zim programs that carry out saving and loading (you can include these in an application). In effect, these commands provide the data preservation operations, contained within ZOMCreate, ZOMErase, ZOMReCreate, and ZOMMove, as an independent service.

Several commands, which do not require parameters, are available. Refer to the Reference Guide for a detailed description.

• – Make
• – Touch All
• – Diagnose
• – Statistics
• – FixUp
• – Configure

Despite thorough testing, an application can experience operational problems. These problems can result from faulty coding or they can be environmental in origin (e.g., stemming from the interaction of the application and the operating system). In either case, the approach to troubleshooting an application uses the same three-step process:

1. Reproducing the Situation

A fundamental rule of problem-solving in any software system is that if you are unable to reproduce the problem, you are unable to solve it.

Some problems can be difficult to reproduce, but the following guidelines make reproduction simpler.

If a problem arises while you are running an application, make note of what was being done with the application at the time.

When you are ready to attempt to reproduce a problem, make the following preparations:

Back up all files.

Reproduce the external environment as closely as possible. If other processes were running, make sure they run during your test.

Try to carry out the same steps that you were performing when the error occurred. Remember to back up your files before each attempt to reproduce the error. Some problems are data dependent, and using the correct initial data can be crucial to successfully reproducing the error.

If you cannot cause the error to occur, the problem could also depend on commands executed earlier in the session. Try again, making sure to run through exactly the same steps that you did when the error first occurred.

During this phase, it is very important to make careful notes of all your actions; you want to be able to repeat, again and again, the exact situation that caused the problem. You should not be concerned at this point with eliminating unnecessary steps; you can deal with that question when you try to isolate the cause of the problem.

2. Isolating the Cause

Once a problem is reproducible, you can attempt to isolate its cause. Isolation involves eliminating potential causes until you have pinpointed exactly what causes the error to occur.

The following strategies can be used to determine the cause of an environmental problem:

Run the application on another computer system. This process helps to determine if hardware problems are involved.

Remove external processes from your system. If the problem does not recur, it could have been a result of system stresses created by these external processes, or the external processes could be interfering with your application.

Reduce memory requirements by changing various options in the configuration files (e.g., sort buffers,  maximum forms, etc.).

If possible, try changing your operating system configuration (e.g., system limits on resources, such as the number of files, number of locks, and so on) before running your application.

Try these strategies one at a time. If your problem disappears, you may have discovered its cause.

The object of the isolation process is to pinpoint the problem. For example, do not worry if reducing memory usage affects performance. If memory usage is causing the problem, at least you can trade some performance for correct operation.

3. Solving the Problem

Once you have isolated the problem, proceed with solving it.

If you have a hardware problem, components of your computer system can be repaired or replaced. Problems stemming from the operation of external processes can be prevented by ensuring that the external processes do not run simultaneously with the application. If the problem stems from memory usage, changes to the configuration files or memory allocation could be required.