You can rename an object using the ZOMReName command. The new object name is specified using the target indicator “>”. The following example renames “Customers” to “Custs”.
ZOMReName Customers > Custs
You can rename an object using the ZOMReName command. The new object name is specified using the target indicator “>”. The following example renames “Customers” to “Custs”.
ZOMReName Customers > Custs
Deleting an object can be accomplished by using the ZOMDelete command. The following example deletes the object “Customers”, causing its description to be removed from the Object Dictionary:
ZOMDelete Customers
Destroying an object using the ZOMDestroy command. The following example destroys the object “Customers”, removing all knowledge of the object:
ZOMDestroy Customers
ZOMDestroy is executed when deleting objects in DC.
You can copy an object using the ZOMCopy command. ZOMCopy is similar to ZOMReName, with the target referring to the new object name. The following example copies “Customers” to “TestCusts”.
ZOMCopy Customers > TestCusts
You can move an object from one directory to another using the ZOMMove command. A set of objects can be moved at once. The destination directory is specified using the target indicator “>”. The following example moves all objects named “Customers” (from the directories to which each belongs) to the directory NewDir:
ZOMMove Customers > NewDir
ZOM also provides a service, ZOMReCreate, for re-creating objects whose definition has changed. Recreating the object Employees would be executed as follows:
ZOMReCreate Employees
A common situation is dealing with “out-of-date” or “corrupt” objects. An object is considered corrupt if it depends on objects which have been erased or moved. Corrupt object must be recreated. You can recreate all corrupt objects using ZOMReCreate, as shown in the following example:
ZOMReCreate +p ec
With ZOM, it is important to differentiate between erasing an object, deleting an object, and destroying an object:
Erasing | Removes the object such that it cannot be referenced in the application. The object’s description in the Object Dictionary is unaffected. |
Deleting | Removes the object’s description from the Object Dictionary. Your ability to reference the object in your application is unaffected. |
Destroying | Erases and deletes the object, as well as removing the object’s registration from ZOM’s database. |
Note an object can be both erased and deleted without being destroyed. This happens if ZOMErase and ZOMDelete are used separately, rather than using ZOMDestroy, leaving the object registered in ZOM’s database.
Erasing an object can be accomplished using the ZOMErase command. The following command erases the objects named “Customers”:
ZOMErase Customers
Routine tasks performed by every Zim developer are creating, erasing, recreating, moving, and copying objects. Collectively, these tasks are called Object Maintenance. ZOM provides considerable assistance to the developer in this area.
ZOM is designed to process sets of objects and maintain knowledge of object dependencies. ZOM operates on sets of objects, rather than one object at a time. The knowledge of interdependencies enables the ZOM services to intelligently manage a set of objects and sequence operations properly.
When moving a set of objects from one directory to another, ZOM examines the list of objects specified and determines the correct order in which to move them, based on the interdependencies among the objects. The objects are then moved one at a time in the correct sequence.
The following subsections describe how ZOM services can be used to perform common object maintenance tasks. Although the examples tend to be simple, all services described support the various selection criteria and options.
All the ZOM object maintenance services also deal automatically with dependent objects affected by the processes you initiate. For example, dependent objects that become “out-of-date” because of a change to a dependent object are automatically updated. You can control how much work ZOM does to maintain dependent objects by customizing the ZOM configuration. For more information, see ZOMConfig.
The ZOM configuration can be called and altered at any time by invoking the ZOMConfig command.
The configuration options control various aspects of ZOM’s operation:
With this option on, status information is displayed when any ZOM service is executing. The status information indicates what objects are being processed, what processing is being done, and other useful information. You can choose between windowed output, serial line-at-a-time output (default – this is the recommended setting), and no output.
With this option on, ZOM maintains an activity log. The activity log tracks the processing done by the ZOM services and also includes any error messages encountered. The activity log can be viewed by invoking the ZOMViewLog command.
Setting error logging on can slow ZOM services if the log file grows large. In this case, you can turn the option off or periodically clear the Zim error log file “errors.trc” by executing the commands:
set output errtrace
set output terminal
ZOM maintains an online cross-reference of the dependencies between the objects in your application that enables many of the powerful features of ZOM. With dependency tracing on, the default, ZOM automatically maintains the dependency database as you use the ZOM services. However, this can slow the performance of the ZOM services in some situations. In this case, you can turn the dependency tracing option off to speed up the ZOM services. This disables explosion and implosion operations, and the display of cross reference information.
Note: The Dependency Trace switches off the Dependency Explosion (no explosion) therefore dependant objects are not recreated, because the dependency is not traced. As dependency information is out dated every time an object is recreated, update this information using ZOMTouch at regular times, i.e. at the end of the day. Switch Dependency Tracing on before executing ZOMTouch.
ZOM insists that all objects be assigned an explicit directory name indicating the directory to which the object belongs. Any unassigned directory names (i.e., blank or null) discovered in the Object Dictionary are automatically assigned to the default Zim directory. By default, default Zim directory is set to “zim”.
With conventions on, ZOM automatically sets the DataSave and Compilable object properties on your behalf. The DataSave property is set for any EntitySet or relationship with fields objects registered. The Compilable property is set for any document object that is compiled. With conventions off, you must set these properties explicitly.
Explosion level determines the extent of actions ZOM undertakes automatically on your behalf on objects that depend on objects you directly manipulate. For example, if you destroy the EntitySet Employees, what should ZOM do to the Relationships and Roles which depend on Employees for their existence?
Explode level can be set to either 0 or 1. Explosion level 0 causes ZOM to ignore any dependencies. Explosion level 1 causes ZOM to “touch” any objects that depend on an object that is recreated, renamed, moved, erased or destroyed. Touching an object resets its properties and the dependency database to reflect the current situation.
The dependency tracing option should be on for explode levels greater than 0.
New keyword is a special keyword that is automatically assigned to all newly registered objects. It is a convenient way to keep track of objects are new to your environment over a period of time. By default, new keyword is set to “$new” as shown in the following example:
ZOMList +k $new
If you would like to reset objects assigned this keyword so no objects are flagged as new, issue the command
ZOMSet +k $new ;k $new!
Changed keyword is a special keyword that is automatically assigned to all objects that are changed (i.e., created, re-created, renames, moved, erased, deleted, compiled, and uncompiled) by a ZOM service. It is a convenient way to keep track of which objects have been altered in your environment over a period of time. By default, changed keyword is set to “$changed”.
ZOMList +k $changed
To reset objects assigned this keyword, so no objects are flagged as changed, issue the command
ZOMSet +k $changed ;k $changed!
Environment code is used to co-ordinate developments occurring in multiple environments and ensure the objects are registered with unique object keys across all development environments. If you set environment code, ensure that it is different for each development environment.
If you do not assign an environment code, ZOM generates a random environment code for you. The randomization is designed to make duplicate environment codes unlikely.
Operations such as ZOMExport can operate in either a set oriented fashion (express mode is on) or a record-at-a-time fashion. In the former, the command usually performs more quickly. However, you do not see a separate status displayed for each object as it is processed nor is a separate log entry be made for each object. This information is available when express mode is off.
Within the ZOM Configuration Interface the process order can be selected. The default is blank, but a ZIM developer can set the Process Sort Order by means of a combo box containing object fields. The sort order is used to sort objects that are processed by ZOM, e.g. in the ZOMList command. It is a standard ZIM sort clause and can contain any valid sort criteria.
The debug option, Log Object Modifications, permits the enabling/disabling of logging modifications to the DefinitionsLog EntitySet. This entity set records all modifications such as creating an object. Access the Debug view form in the Debug Options Interface. This option can also be set at the command line by entering the statement set logdefinitions on/off.
To aid client-server development, an additional debug option to add tracing for SQL statements is provided. Access the Trace view form in the Debug Options Interface.
View the activity and error log file.
ZOMViewLog
Enables you to browse through the list of progress and error messages produced by the ZOM services you have been using.
To review the results of the previous ZOM command, enter
ZOMViewLog