Next steps

Now that you have set up your first, basic runtime environment (RTE), you can begin to modify and expand your monitoring system to meet your specific site requirements.

Complete any or all of the following tasks as you deploy monitoring in your production environment:

FTU task 6: (Optional) Set up a hub monitoring server on another OS

FTU task 4 had you set up a hub monitoring server on z/OS®. However, you might prefer to run your hub on a different operating system such as Linux on Z, Windows, UNIX, or Linux. You can set up another hub, then convert the z/OS hub that you previously created to a remote, and configure it to connect to the hub on a distributed system. Skip this task if you intend to run the hub monitoring server on z/OS.

FTU task 7: Configure additional monitoring agents

You configured an RTE with a single monitoring agent. Now you might want to configure other monitoring agents that you already installed via SMP/E in this particular RTE. For example, you may want to monitor Db2 on this LPAR. If so, configure that monitoring agent. You can configure as many agents as you want all at the same time in this task.

FTU task 8: Configure historical data collection

Historical data collection is an optional feature that is enabled through the Tivoli Enterprise Portal or the OMEGAMON enhanced 3270 user interface. The tasks required to enable historical reporting can be performed at any time after you have verified your installation. If you enable historical data collection, monitoring agents are instructed to take data samples at a specified interval and store it. The collected data can be displayed in workspaces in either interface, warehoused for in-depth analyses and long-term data reporting, and exported to third-party tools for reporting and analysis. (Note that not all historical data that is displayed in the Tivoli Enterprise Portal can be displayed in the Enhanced 3270UI, and not all the near-term history displayed in the Enhanced 3270UI can be displayed in the Tivoli Enterprise Portal.)
Notes:
  • The Enhanced 3270 user interface cannot display data from the Tivoli Data Warehouse, and you cannot configure the Warehouse Proxy agent or the Summarization and Pruning agent from the enhanced 3270UI.
  • Using the Tivoli Data Warehouse is optional for the OMEGAMON for Db2 Performance Expert monitoring agent. The agent offers other long-term storage options.
  • The z/OS persistent data store data sets, where some of the historical data is stored on z/OS, should have been configured earlier during “FTU Task 4” and “FTU Task 7”.
For more information on configuring the persistent data store, see Allocate data sets and configure maintenance for historical data, (Optional) Configure historical data collection, and the product-specific Planning and Configuration Guides.

Note that near-term historical data for OMEGAMON for z/OS for the OMEGAMON enhanced 3270 user interface can be collected from RMF. The RACF ID that is defined for the address spaces where OMEGAMON for z/OS agents run must be authorized to access RMF.

FTU task 9: (Optional best practice) Implement system and user variables

Implementing system and user variables in the RTE is a best practice because it allows the RTE to be cloned and automatically pick up the values of the new system. Using variables also makes it easier to handle any system changes that might be made along the way.

To quickly implement system and best-practice user symbols in the RTE, complete the instructions in How to: Merge predefined variables into configuration profiles.

FTU task 10: (Optional best practice) Create a high-availability hub monitoring server

A high-availability (HA) hub monitoring server is available only when the hub resides on z/OS. On distributed systems and Linux on Z, you create a “hot standby” rather than an HA hub. Skip this task if your hub monitoring server does not reside on z/OS.

To create an HA hub and convert the current static hub monitoring server to a remote, follow the instructions in How to: Convert an existing static hub monitoring environment to a high-availability hub environment.

FTU task 11: Install maintenance and update the RTE

At some point, you will need to apply maintenance to your RTEs.

Apply SMP/E maintenance for products and components, then start the configuration procedures. Check the PSP and Upgrade information in the Recommended Maintenance Service Levels for OMEGAMON products in the ITM V6.x technote for recommended maintenance. If recommended maintenance is available, obtain and apply the maintenance via SMP/E.

To update the RTE with the recommended maintenance, follow the instructions in SMP/E maintenance and upgrade scenarios. Select the scenario appropriate to what you are trying to achieve and to the actions from the HOLD++ data in the SMP/E maintenance.

FTU task 12: Convert the RTE type for production use

A best practice for a production RTE is to use a set of static base libraries instead of concatenating SMP/E libraries that are updated each time SMP/E maintenance is applied. This approach provides more control and increases stability of your production environment. Rather than create a new sharing-with-base RTE from scratch, you can convert the sharing-with-SMP/E environment that was created in previous steps into a sharing-with-base RTE.

To convert the existing RTE to share with a static base, complete the instructions in How to: Convert a sharing-with-SMP/E RTE to sharing-with-base.

FTU task 13: Clone the RTE to other systems

After you configure an RTE that reflects your requirements and best practices, you can use PARMGEN to replicate that RTE to other z/OS images. As you replicate, you can remove various applications from the cloned environment or add new applications to the clone, change the RTE type, or change the type of monitoring server.

For instructions on how to clone the RTE to another system or LPAR, see Cloning an existing PARMGEN runtime environment. For background information on cloning and moving an RTE, read Replicating configured runtime environments. This information is particularly important when you are cloning an RTE that will be moved to another system.

FTU task 14: Consider security issues

The monitoring framework (Tivoli Management Services) and the OMEGAMON monitoring products offer a number of security options, including logon security for the various interfaces, secure communication between monitoring components, and password encryption. In addition, monitoring components, started tasks, and address spaces require authorization to perform various tasks such as communicating with monitored subsystems, issuing Take Action commands, and accessing certain data.

You have already implemented the minimum security required for the basic RTE you configured (authorization for the Tivoli Enterprise Monitoring Server to access the z/OS UNIX System Services file system to store data for self-describing agents). But before you begin to deploy other RTEs, you need to evaluate other security options and requirements in the light of your site standards. For more information about security options, see What security options to enable.