Objects can be selected by querying the locked property using the selection criteria “l”. All objects that are locked (i.e., have had the locked property set by the user) are selected. For example, in the following command, all objects that are locked are selected for use by the ZOMLIST service:
ZOMList +p l
In the next example, all objects that are not locked are selected:
ZOMList +p l!
Objects can be selected by querying the datasave property using the selection criteria “ds”. All EntitySet and data relationship objects that are datasave (i.e., have had the datasave property set by the user) are selected. (Objects that have the datasave property have their data records automatically preserved when the object definition is changed using a ZOM service.) For example, in the following command, all datasave objects are selected for use by the ZOMLIST service:
ZOMList +p ds
In the next example, all objects that are not datasave objects are selected:
ZOMList +p ds!
Objects that were selected by the last ZOM service used can be selected again by using the selection criteria “.”. All objects that were previously selected are selected. For example, ZOMSet is used below to process the same set of objects selected by the ZOMList service. In this case, ZOMSet removes the keyword “User_Interface” for these objects.
ZOMList +k User_Interface
ZOMSet +. ;k User_Interface !
The Previously Selected criteria (“.”) is very useful for processing the same set of objects over and over again. It is also convenient for re-selecting a set of objects that you first previewed using ZOMList, as shown above.
Objects can be selected by querying the exists property using the selection criteria “e”. All objects that exist (i.e., have been created in the application) are selected. For example, in the following command, all existing objects are selected for use by the ZOMLIST service:
ZOMList +p e
In the next example, all objects that do not exist are selected:
ZOMList +p e!
You can also select objects that exist but are considered to be corrupt (i.e., out-of-date). An object is considered corrupt if it depends on another object which has been erased or moved to another directory. In the next example, all corrupt objects are selected:
ZOMList +p ec
Objects can be selected by querying the compilable property using the selection criteria “c”. All objects that are compilable (i.e., document objects that have had the compilable property set by the user) are selected. For example, in the following command, all compilable objects are selected for use by the ZOMLIST service:
ZOMList +p c
In the next example, all objects that are not compilable are selected:
ZOMList +p c!
This example finds all objects which have been declared by the user as macros (a variation on the compilable property):
ZOMList +p cm
This next example finds all objects which have been declared by the user as compilable/ignore warnings (a variation on the compilable property):
ZOMList +p ci
Objects can be selected by querying the active property using the selection criteria “a”. All objects that are active (i.e., have had the active property set) are selected. (By default, objects are considered active.) For example, in the following command, all objects which are active are selected for use by the ZOMLIST service:
ZOMList +p a
Normally, objects that are considered inactive (i.e., do not have the active property set) are not processed by the ZOM services. However, you can explicitly make inactive objects available for processing by using the special processing option ;i. For example, in the following command all active and inactive objects are selected for use by the ZOMLIST service:
ZOMList * ;i
In the next example, only the inactive objects are selected:
ZOMList +p a! ;i
In this case, ;i makes inactive objects available for processing and +p a! selects only the not active objects. Note that without ;i, the above command would select no objects at all since the normal behavior is to ignore inactive objects entirely.
Objects can be selected by querying the compilestatus property using the selection criteria “ca”. All compiled objects (i.e. document objects that have been compiled) are selected. For example, in the following command, all compiled objects are selected for use by the ZOMLIST service:
ZOMList +p ca
In the next example, only those compiled objects that encountered errors during their most recent compilation are selected:
ZOMList +p ce
The ” e” here implies Errors.
Objects can be selected by querying the compilestatus property to determine if the object needs to be recompiled. All document objects that are considered to be in need of recompilation (e.g., program source is more recent than compiled program, object definitions have changed, and so on) are selected. For example, in the following command, all objects in need of recompilation are selected for use by the ZOMLIST service:
ZOMList +p cn
The ” n” here implies that the objects need recompiling.
Objects have various properties which record the status of the object. You can select objects based on these status properties using the selection operator “p”. Since there are many properties available, you identify the desired property explicitly. Each status property has its own symbol that is used for both selecting and setting the property.
For example in the following command, all objects that have the locked property are selected for use by the ZOMLIST service:
ZOMList +p l
Here the selection criteria “p” indicates property and the argument “l” indicates the property to match is the locked property.
You can also select objects by specifying those that do not have a specific property. The next example selects all object that are not locked:
ZOMList +p l!
The exclamation point (!) negates the specified property. In other words, the “!” selects those object that do not have the specified property.
The following subsections describe how to select objects by each of the various status properties.
Objects can be selected by keyword using the selection criteria “k” followed by the keyword (s) to match. All objects that have been assigned the given keyword (s) are selected. For example, in the following command, all objects that have been assigned the keyword “User_Interface” are selected for use by the ZOMLIST service:
ZOMList +k User_Interface
The keyword criteria performs an keyword match against a specified keyword, and finds all objects which have been assigned that keyword.
The keyword can also be specified as a character string pattern. For example, the following command lists all objects that have been assigned keywords that begin with “Version2”:
ZOMList +k Version2*
The rules for specifying keyword patterns are the same as for selecting by name.
If more than one keyword is used with the same selection criteria, you can use commas to separate the keywords. The following examples both select all objects assigned the keywords “Version1”, “Version2” or “Version3”:
ZOMList +k Version1 +k Version2 +k Version3
ZOMList +k Version1,Version2,Version3
In the latter case, we have combined the three selection items into a single selection by separating the three keywords by commas (‘,’).
Objects can be selected based on whether or not they are referenced by another object by using the selection operator “u”. An unreferenced object is an object that is not depended on by any other object; e.g., a variable which is not used in a program, relationship, role condition, or a virtual field is ” unreferenced”. For example, in the following command, all unreferenced objects are selected for use by the ZOMLIST service:
ZOMList +p u
Generally, unreferenced objects are unused by a program, but this is not always so. For example, the main menu of a program can be unreferenced, because it is, by definition, the starting point of the application. Similarly, object references hidden in Zim macros are not detectable. Nevertheless, the unreferenced criteria is a great assistant in identifying objects that are no longer needed in an application, and helps the process of clean up.
An example of how to effectively use the unreferenced criteria is shown below. Upon reviewing the results of the ZOMList command above, we determined that all unreferenced objects but ” pMainMenu” are no longer needed. Instead of destroying these objects, they are assigned the keyword “Garbage”. Then the “Garbage” objects are erased. Erase is a better choice than destroy because you can test the application and recover any needed objects. If a problem arises because some of the “Garbage” objects are actually needed, those objects can be created since ZOMErase does not remove the description from the Object Dictionary.
ZOMSet + pu – n pMainMenu ; k Garbage
ZOMErase + k Garbage
Once the application has been tested following the erase, the final act of cleanup is to destroy the key-worded objects. The destroy operation removes both the object and its Object Dictionary description.
ZOMDestroy + k Garbage
Portuguese 
English