MainView for MQ policies
This section provides details of the supplied MainView for MQ policies to enable you to customize them for your specific environment.
If you simply want to get started using the policy as quickly as possible (with no customization), see Getting started with policies. In order to gain a better understanding of policies, see Policy architecture.
It is important to note that these policies apply to data brought into TrueSight Middleware and Transaction Monitor using the qpmainview extension. For such data, some types are published under standard WMQ types while others are under specific MVMQ types. Thus, you cannot use the WMQ policies alone, but must add the MVMQ policy to cover the MainView specific object types. However, where you have installed the QPMON extension directly on mainframe systems, these MVMQ policies will not work and you should use only the WMQ polices which do cover mainframe specific MQ objects and attributes as monitored by QPMON.
As is typical with Minimal level supplied policies, the MVMQ_Agents_Minimal Agent Policy registers very limited monitoring.
In general, you should use this policy when you wish to control your monitoring manually by selecting individual objects for monitoring. MVMQ_Agents_Minimal registers the BMM agent for history collection using the SAMPLE history template and applies the Basic BMM Extension Object Policy (see BMM (self-monitoring) policies). It then has one main Object Policy Group (MVMQ_POLICY_Minimal, as shown below).
As shown above, this Minimal Policy directly applies a Basic Object Policy to queue managers and the MQ log manager (selecting them for monitoring and registering them for history collection with the SAMPLE history template). Note that the SYSTEM Queues would be covered by the WMQ policies since those are under a WMQ object type.
The MVMQ_Agents_Basic Agent Policy applies the same actions to BMM agents and extensions and to MQ queue managers and MQ log manager as the Minimal level.
However, it adds Basic level Object Policies for Applications, Buffer Pools, Channel Initiators, Coupling Facilties, Queue Sharing Groups, and Queue Stats. For each of these, it selects the Non-System objects for monitoring and registers them for history using the SAMPLE history template. You should use this policy when you want to ensure that all of your objects are monitored, but you want to configure events on your own. Note that Channels, Topics, and Local Queues are covered under the WMQ Policies.
The Standard level of monitoring is, as always, the general recommendation for normal systems. Because the Standard level does Events as well as selection for monitoring and history, you need to choose the variant that matches the target (TrueSight Operations=BEM, EMail, or LogToFile) that you want to receive your events. Note that some configuration is necessary to connect to your Event Manager, email server, or log file.
As is normal for Standard level policies, the MVMQ_Agents_Standard_EventTarget policies apply the Standard level of monitoring against the BMM agents and extensions (see BMM (self-monitoring) policies and then provide a single main Object Policy Group (MVMQ_POLICY_Standard_EventTarget) with nested object Polices (see below).
As you can see, MVMQ_POLICY_Standard_EventTarget directly applies Object Policies to all Applications, Buffer Pools, Channel Initiators, Coupling Facilties, Log Info Objects, Log Managers, Queue Managers, Queue Sharing Groups, and (hidden off the page) Queue Stats objects. Note that there are no events to be supplied for Buffer Pools and Queue Managers since these are MainView MQ specific types, but all key metrics for eventing are covered under the WMQ policies. For all of the other types, MVMQ specific events are added. It is beyond the scope of this section to describe all of the event actions applied on these individual objects.
The MVMQ_Agents_ALL_EventTarget Agent Policy registers a large number of additional events for the Application, Channel Initiator, LogManager, and QueueSharingGroupDB2 object types. In addition, it registers events (e.g. Put Disabled) against Alias and Remote queues. This policy is intended to illustrate the scope of what is possible. It is strongly recommended that you do not enable this policy directly in a production environment. Instead, you can enable it in a well-controlled testing environment to experiment with policies and to select the event templates that are relevant to your specific environment before creating a customized policy that removes the associations that you do not want.