Comparison with PARMGEN

IBM Z® Monitoring Configuration Manager evolved from PARMGEN. If you understand PARMGEN, then a comparison can help you to quickly understand Monitoring Configuration Manager.

You can use either Monitoring Configuration Manager or PARMGEN to configure runtime environments for the supported OMEGAMON agents. Monitoring Configuration Manager and PARMGEN use mainly the same parameters. However, Monitoring Configuration Manager radically simplifies the process of configuring runtime environments from those parameters.

You must decide whether to use Monitoring Configuration Manager or PARMGEN

You can use Monitoring Configuration Manager to generate runtime members for some runtime environments, PARMGEN for others, and run them in the same monitoring topology, communicating with the same hub monitoring server. In that sense, you can use Monitoring Configuration Manager and PARMGEN alongside each other.

However, you cannot use Monitoring Configuration Manager and PARMGEN interchangeably to generate runtime members for a runtime environment from the same set of parameters. For each runtime environment, you must decide whether to use Monitoring Configuration Manager or PARMGEN.

Note: You can move PARMGEN data to Configuration Manager using the MIGRATE action.

Overview

The following table provides an overview of the differences between Monitoring Configuration Manager and PARMGEN.

Table 1. Monitoring Configuration Manager versus PARMGEN: overview
Monitoring Configuration Manager	PARMGEN
Batch-only interface.	Combination of ISPF user interface and batch. You navigate ISPF panels to select which job to submit.
The same simple, concise JCL for all actions.	Different jobs for different actions. Complex, long JCL. JCL members tailored for each runtime environment must be created, stored, and potentially recreated, depending on the situation.
To generate runtime members from parameters, you submit one job.	To generate runtime members from parameters, you use ISPF panels to submit a series of jobs. Some jobs submit other jobs. You need to check the output from each job, and then return to the ISPF panels to submit the next job in the series.
To generate runtime members, you submit the same job in all situations. Enhancements introduced by Monitoring Configuration Manager, including performance improvements and the streamlining of previously separate stages into a single job, removes the need for users to decide which stages to run in different situations.	You need to understand which job, or series of jobs, to submit in different situations. For example, you need to understand which jobs to run to update a runtime environment after applying SMP/E maintenance to your OMEGAMON agents.
You only need to know about the input parameters and the output runtime members. Monitoring Configuration Manager insulates you from the underlying complexity.	In addition to understanding the inputs and outputs, you also need to understand the details of the process that generates runtime members. For example, you need to understand the difference between interim staging (IK) libraries, work (WK) libraries, and the final output runtime (RK*) libraries. You also need to understand which stages of the process, and which jobs, affect each of those libraries.
Sparse configuration profiles containing only the parameters you need. The initial configuration profile members contain only a few dozen parameters. This is all you need to use basic functions if you are content with default parameter values.	Comprehensive configuration profiles containing all parameters for all agents. You edit a configuration profile member containing hundreds of parameters interspersed with multiline comments.
Integrated subsystem discovery.	Requires IBM Discovery Library Adapter for z/OS® (DLA).
Available for all agents of the IBM Z Monitoring Suite and the IBM Z NetView Enterprise Management Agent, as well as for IBM OMEGAMON for z/OS version 5.5.0 or later, IBM OMEGAMON for Networks on z/OS V5.5.0 or later, and IBM Z OMEGAMON Integration Monitor V5.5.0 or later. In addition, support is provided for all agents that are part of the IBM Z Service Management Suite. This includes the same list of agents as above, except for Integration Monitor. Point product installations are also supported for the aforementioned agents/products.	Available with IBM Z Monitoring Suite and other products.

Details

The following table describes some differences in the implementation details between Monitoring Configuration Manager and PARMGEN.

For a comprehensive list of parameters that have different default values in Monitoring Configuration Manager and PARMGEN, see Parameters with different default values than PARMGEN.

Text in italics represents a parameter value. For example, rte_plib_hilev represents the value of the RTE_PLIB_HILEV parameter.

Table 2. Monitoring Configuration Manager versus PARMGEN: details
Monitoring Configuration Manager	PARMGEN
Stores parameters and variables in: `rte_plib_hilev`.RTEDEF Each RTEDEF library can contain definitions for multiple runtime environments, customized to run on multiple LPARs. Note: The Configuration Manager GENERATE action creates an `rte_plib_hilev`.`rte_name`.WCONFIG(`rte_name`) member that is similar to the member created by PARMGEN, with one key difference: the member created by Configuration Manager contains default parameter values; it does not reflect the values in your RTEDEF library members. The WCONFIG data sets created by Configuration Manager, as a whole, should be considered a black box.	Stores parameters in: `rte_plib_hilev`.`rte_name`.WCONFIG Each WCONFIG library contains the definition for a single runtime environment, with limited flexibility to customize that definition to run on multiple LPARs. Stores variables in: `gbl_user_jcl`
Organizes parameters into members according to their prefix and whether they apply to all LPARs or only to a specific LPAR. Provides a well-defined member naming convention so you know which parameters to store where and which parameters take precedence. Similarly, Monitoring Configuration Manager organizes variables into members that enable different values for each LPAR. You can configure a runtime environment using a combination of parameters that are common to all LPARs and parameters that apply only to a specific LPAR.	Mixes runtime environment (RTE_) parameters and product-specific (Kpp_) parameters in a single large member, WCONFIG(`rte_name`). You can divide this monolithic member into smaller members, but you need to manage this yourself for each runtime environment. You need to define your own member naming convention, and then edit the WCONFIG($SYSIN) member to include the members in PARMGEN processing and define their order of precedence. No built-in support for LPAR-specific parameter values beyond using variables, such as `SYSNAME`, that have LPAR-specific values.
Enables you to define LPAR-specific parameter values without using variables.	Uses variables to customize configuration profiles for different LPARs.
Uses the parameters in the first row of a table as the defaults for subsequent rows. If you omit a parameter from a subsequent row, that row uses the value from the first row. This enables you to define more concise sparse parameter tables with less duplication of values.	You must specify parameter values for each row in a table of parameters.
By default, writes system library members to the same high-level qualifiers as other non-VSAM runtime members: `rte_hilev`.SYS1.* where * is the system library low-level qualifier: PROCLIB, VTAMLIB, or VTAMLST	By default, writes system library members directly to: SYS1.*
Writes concise started tasks with minimal comments. Tip: Monitoring Configuration Manager writes concise started tasks to: `rte_hilev`.SYS1.PROCLIB and versions with verbose comments to the same location used by PARMGEN: `rte_plib_hilev`.`rte_name`.RKANSAMU `rte_plib_hilev`.`rte_name`.RKD2SAM (for Db2®)	Writes started tasks with verbose comments.
Sets the default value of the RTE_USS_DIR parameter to /var/rtehome.	Sets the default value of the RTE_USS_DIR parameter to /rtehome, a subdirectory of the root directory. Creating a new subdirectory of the root directory is bad practice.
In the z/OS UNIX System Services file system, by default writes only to `rte_uss_dir`/`rte_name`	By default, writes to various z/OS UNIX directories.
Sets the default value of the RTE_TYPE parameter to `SHARING` and RTE_SHARE to `SMP`. By default, runtime environments refer to some runtime members, such as load modules, in the SMP/E installation target library, rather than creating a full copy of those members in the runtime environment's own runtime libraries.	Sets the default value of the RTE_TYPE parameter to `FULL`. By default, the runtime environment runtime members include a full copy of all members required from the SMP/E installation target library.
Provides the ability to create one or more copies of SMP/E target libraries from which you can create or update your runtime environments. Sharing with an SMP/E target in reality is sharing with an SMP/E target copy. The Configuration Manager target copy feature copies only the data sets needed for products that are selected for configuration into the target copy libraries. For RTE_SHARE, you can only specify `SMP` for a sharing runtime environment. Configuration Manager does not use base runtime environments (as in PARMGEN).	Provides the ability to use a set of static base libraries in a base runtime environment from which a sharing-with-base runtime environment obtains read-only runtime libraries. For RTE_SHARE, you can specify the name of base or full runtime environment from where a sharing runtime environment obtains its base library information, or you can specify `SMP` to share SMP/E target libraries.