Categoria: Programs and Utilities

Objects can be selected based on the dependency of other objects on them by using the selection criteria “i”. The dependency implosion criteria uses the set of objects selected so far to select the objects depending on those objects. It takes the set of currently selected objects and performs the implosion operation on that set of objects. The nature and extent of the implosion is determined by attaching further criteria qualifiers. If no qualifier is attached, all objects that the object depends on are added to the set of objects selected. If a “p” is attached, this indicates a program dependency implosion. If followed by a “t”, this indicates an object creation dependency implosion. The “h” option indicates a Hollow implosion process, which results in only the set of imploded objects without the original objects.

Note: Dependencies between objects and dependency implosions are explained in Object Dependencies.

The following command finds all objects depended on by the object “Customers,” and includes the original object as well.

ZOMList Customers +i

Since the dependency implosion depends on having previously selected some objects, the “i” selection operator should never be used as the first selection criteria.

In a hollow dependency implosion, the original set of objects is excluded from the result. The following command finds all objects depended on by objects named “Customers” but excludes the “Customers” objects:

ZOMList Customers +i h

The following command finds all objects depended on by the object “Customers,” and all objects on which they depend, and recurses until no further dependent objects are found. Program references are omitted from the dependency tree imploded.

ZOMList Customers +i t

The following command finds all objects depended on by the object “pMainMenu,” and all objects on which they depend, and recurses until no further dependent objects are found. Program references are used rather than object creation dependencies when the dependency tree is imploded.

ZOMList pMainMenu +i p

Objects can be selected based on their dependency on other objects by using the selection criteria “x”. The dependency explosion criteria uses the set of objects selected so far to select the objects that depend on those objects. It takes the set of currently selected objects and performs a dependency explosion operation on that set of objects. The nature and extent of the explosion is determined by attaching further criteria qualifiers. If no qualifier is attached, all objects that depend on the object are added to the set of objects selected. If a “p” is attached, this indicates a program dependency explosion. If followed by a “t”, this indicates an object creation dependency explosion. The “h” option indicates a Hollow explosion process, which results only in the set of exploded objects without the original objects.

In the following example, all objects named “Customers” are selected along with all other objects that depend on the “Customers” objects:

ZOMList Customers +x

Since the dependency explosion depends on having previously selected some objects, the “x” selection operator should never be used as the first selection criteria.

In a hollow dependency explosion, the original set of objects is excluded from the result. The following command finds all objects which depend on objects named “Customers” but excludes the “Customers” objects:

ZOMList Customers +x h

The following command finds all objects which depend on the object “Customers” and all objects depending on them, and recurses until no further depending objects are found. Program references are omitted from the dependency tree exploded.

ZOMList Customers +x t

The following command finds all objects that depend on the object “pMainMenu” and all objects that depending on them, and recurses until no further depending objects are found. Program references are used rather than object creation dependencies when the dependency tree is exploded.

ZOMList pMainMenu +x p

Note: Dependencies between objects and dependency explosions are explained in Object Dependencies.

Objects can be selected by name using the selection criteria “n” followed by the object name(s) to match. All objects matching the given name are selected. For example, in the following command all objects named “Customers” are selected for use by the ZOMLIST service:

ZOMList +n Customers

The name can be specified as a character string pattern. For example, the following command lists all objects whose object name begins with “Cust”

ZOMList +n Cust*

In specifying a name to match, certain characters have special meaning:

The next example selects all objects whose name begins with “Cust”, followed by any character, followed by “XXX”, followed by any number of characters:

ZOMList +n Cust?XXX*

This pattern would match object names such as “Cust1XXX” and “CustaXXXabc”.

If more than one name is used with the same selection criteria, you can use commas to separate the names. The following examples both select all objects named “Customers”, “Employees” or “SalesPeople”:

ZOMList +n Customers +n Employees +n SalesPeople
 

ZOMList +n Customers,Employees,SalesPeople

In the latter case, we have combined the three selection items into a single selection by separating the three name patterns by commas (‘,’).

The next example shows the use of the minus set operator (‘-‘) to select all objects that do not have the name “Customers”, “Employees” or “SalesPeople”.

ZOMList +n * -n Customers,Employees,SalesPeople

Here the first selection item “+n *” selects all objects, then the minus item (“-n”) that follows excludes all objects with the “Customers”, “Employees” or “SalesPeople”.

Objects can also be selected by specifying the owning directory. For example, the next command lists all objects named “Customers” belonging to the directory “SalesSystem”:

ZOMList +n SalesSystem.Customers

The period (‘.’) separating the literals “SalesSystem” and “Customers” in this example indicates that SalesSystem is the owning directory and Customers is the object contained in this directory.

You can also use the pattern matching feature with directory names. For example, the following command selects all objects belonging to the Test directory:

ZOMList +n Test.*

The next example selects all objects whose name begins with “Cust” and belong to the Test directory:

ZOMList +n Test.Cust*

The next example selects all objects whose name begins with “Custs” and belong to any directory whose name ends with “Test”:

ZOMList +n *Test.Cust*

As a convenience, you do not have to specify “+n” if the first selection is by name. In this case, “+n” is assumed. For example, the following two commands are equivalent:

ZOMList +n Customers, Satellites
ZOMList Customers, Satellites

There are several different criteria for selecting objects. You can select objects by name, by type, by keyword, by interdependencies on other objects and by various properties. Each of these selection criteria is represented by a different letter:

All ZOM services use a common mechanism for selecting objects on which to operate. This  mechanism consists of a series of one or more selection items that specify a set of objects to be processed by the service. This section provides an overview of object selection using a number of examples. Following sections contain detailed descriptions of all selection options that are possible.

Note: Keywording is described in Keywording Objects.

The following example contains a single selection criteria that indicates all objects of type EntitySet:

ZOMList +t Ent

The +t indicates selection by Type and Ent indicates only objects of type EntitySet are to be considered. In English, this example would literally read:

List the set of objects of type EntitySet.

The t in +t is the selection criteria; t meaning type. There are several different criteria you can use to select objects. In specifying the objects to process, each selection criteria you use must be prefixed with a set operator which is one of

The first selection item establishes an initial set of objects and this set is further refined by any subsequent selections. The first selection item should always use a union operation (+) to establish an initial object set with which to work. This can seem overly mathematical, but the model of taking sets and operating on them becomes very useful as more complex selections are made.

For example, if you wanted to list the objects that are EntitySets as well as the objects that are Relationships, enter

ZOMList +t Ent +t Rel

This example selects the set of objects of type EntitySet and unions this set with the set of objects of type Relationship, then lists the objects in the resulting set.

Because both selections in the preceding example are by the same criteria (i.e., Type), you can express the selection in a simpler way:

ZOMList +t Ent, Rel

Here you have combined the two selection items “+t Ent” and “+t Rel” into a single selection by separating the two arguments by a comma (‘,’).

Continuing with this example, if there was an object named “Customers” which you want to exclude from the listing, enter

ZOMList +t Ent, Rel -n Customers

The minus (-) operator causes the set operation “minus” to be applied. The selection criteria “n” means “name”. The result of “-n Customers” is to remove objects with the name “Customers” from the set of objects selected so far. Since selection items are processed left to right, this example selects all objects of type EntitySet or Relationship, and then removes all objects named “Customers” from this set.

Alternately, you could select only those EntitySet or Relationship objects which also have been assigned the keyword “Sales_System”:

ZOMList +t Ent, Rel ^k Sales_System

The caret (^) operator causes the set operation “intersection” to be applied. The selection criteria k means keyword. The result of “^k Sales_System” is to select only objects that have been assigned (by the user) the keyword “Sales_System” from the set of objects selected so far. Since selection items are processed left to right, this example selects all objects of type EntitySet or Relationship, and then selects all objects keyworded by “Sales_System” from this set.

Complex selections often cannot be done in a single ZOM command. If this occurs, use ZOM’s keywording capability to first identify the objects on which to operate and then invoke the desired service using the keywords to select the desired objects. The next example uses keywording (and other techniques that have not been introduced yet) to select a particular set of objects. Although you might not be familiar with the specific syntax, this example gives you a flavor of how ZOM can handle arbitrarily complex object selections.

ZOMSet +n Cust* +itp ;k Used_By_Cust

ZOMSet +n Inv* +itp ;k Used_By_Inv

ZOMList +k Used_By_Cust ^k Used_By_Inv

This example has the effect of listing all objects that are used by objects whose names begin with “Cust” and are used by objects whose names begin with “Inv.” (The first ZOMSet command assigns the keyword “Used_By_Cust” to all objects used by objects whose names begin with “Cust”. The second ZOMSet command assigns the keyword “Used_By_Inv” to all objects used by objects whose names begin with “Inv”. The ZOMSet service and the selection criteria and processing options used here are all explained in the following subsections.)

The power of the various selection criteria becomes much more potent in the context of these composite selections. However, there is a danger in this power. With ZOM, you can very easily select large numbers of objects for a ZOM service to process. Therefore, you should be very careful that only the desired objects are selected.

Until you become familiar with the use of these selection criteria, it is recommended you preview your selections by using the ZOMList service before using any ZOM service that performs update operations on the object involved.

The subsections below describe each of the various selection criteria available for selecting objects to be processed by a ZOM 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

ZOM provides services and features to support multi-person development teams. These capabilities can be used to identify and track changes, control changes, exchange changes between environments, and merge developments from one environment into another.

ZOM supports various development methodologies. Some of these are described in the following topics; however, ZOM can be applied in many ways to support other methodologies including customized approaches.

All objects must be assigned valid directory names in your Object Dictionary to be accessible in ZOM. In other words, the directory name (i.e., DirName) attributes in your Object Dictionary must be assigned and cannot be left blank or null.

If you have objects defined in multiple directories, you must complete the DirName and FormDirName fields in the Object Dictionary (if they are blank or null) prior to using ZOM. If you do not, the ZOM services automatically assign a default directory name.

Note: You can select a default directory by using the ZOM configuration facility, ZOMConfig. Initially, the default directory is “Zim”.

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.