New to BMC TrueSight Middleware and Transaction Monitor 8.0.00 is the concept that each object has a state. The states are ADDED, CONFIRMED, NOT-FOUND, DEPRECATED, and DELETED.
The addition of an object state is the result of the discovery features added to the product for the WebSphere MQ extension. During each monitoring cycle the WebSphere MQ extension is able to determine which MQ objects have been added or removed. When an object is discovered it is said to be confirmed. Each object also maintains the time when it was first discovered, when it was last confirmed to exist, and when the state last changed. When a discovery sweep occurs the object may be re-confirmed by updating the time when last confirmed. See another post by me that discusses when you would use a discovery sweep.
There are two ways an object may change to a deleted state. Consider the scenario that a MQ queue is registered for monitoring as it is required for use by the MQ applications. Infrastructure changes are underway and the MQ administrator needs to reconfigure MQ. An MQ administrator knows the queue is going away so they use the Object Repository to select the queue in the tree, right click and select "Deprecate Object". The deprecate state is sticky in that once an object is deprecated, even if the object is re-confirmed it remains deprecated. The intention is that this state informs users this object is going away and to avoid it or learn why. The object remains in that state until "Undo Deprecate Object" is used or an extension says the object no longer exists at which time the object is now in a deleted state.
The other scenario is that the extension has determined the object is actually gone. The object then goes to a not found state. Perhaps the queue was simply removed by the MQ administrator but how does one know the removal wasn’t done by accident? Now an MQ administrator can come in and choose to deprecate the object if they know the removal wasn’t by accident or they can figure out why the object was removed and re-create it if necessary. Deprecating an object in a not found state causes the object to be in a deleted state.
Having said all that, the flexibility has been added where you can simply choose to mark an object deleted immediately. Simply right click and choose "Delete Object".
A few notes.
An object isn’t really gone from the object repository when in a deleted state. If you have a large number of deleted objects, the next time you schedule down time for the services you can run dbschema_sync with the -o option to permanently remove them. Please consider that any history, audit events and event journals will no longer be available for those objects once permanently removed.
When an object transitions to a not found or deleted state, the object no longer is registered for monitoring. So if the MQ administrator accidentally removes an MQ object and then later adds it back you will need to register that object for monitoring again unless you have a policy configured to do it for you. In addition to the times noted earlier, the time when monitoring was last changed is also maintained for each object. All this information can be viewed from the Object Repository tab when you select an object from the tree.