Like most tools , there is more than one way to use the ITM PARMGEN configuration tool. Over the past few months I’ve been working with it and have come up with a few ways to get the best out of it. The following are based on my experiences using it.
Keep PARMGEN up to date.
PARMGEN is a constantly evolving tool. APARs are currently being released on a regular basis to update its capabilities.
The technote lists currently available service and other important information and is here http://www-01.ibm.com/support/docview.wss?uid=swg21417935
You can subscribe to the technote and get notified when changes are available.
Do not make changes outside of PARMGEN
So far as is possible I would recommend that you do NOT make direct changes to run time components such as start up parameters in run time data sets. If you do make such changes, the next time you make a change via PARMGEN and deploy the modified environment, you will lose your external changes. If you have to make such external changes I would recommend you make a note of the change as a comment in the PARMGEN Run Time environment (RTE) parameter deck to remind you to redo the change after a PARMGEN change.
Make all Changes via PARMGEN
If something in the run time environment is not working, in general it’s because something is not correctly configured in the PARMGEN parameter members for the environment. The correct way to fix the issue it to go back to PARMGEN, update the run time’s parameter deck, then regen and redeploy the environment.
Put a z/OS hub in its own Run Time Environment
If you run your ITM hub TEMS on z/OS then you have two choices. A hub that is configured to run on a single LPAR, or what is known as a High Availability (HA) hub than can run on any configured LPAR in a Sysplex.
The disadvantage of configuring your hub to run on a single LPAR is that if the LPAR becomes unavailable you lose your entire ITM monitoring environment. With an HA hub, you can move it to another LPAR and have everything back up and running very quickly without any reconfiguration being required.
One of the requirements of configuring an HA hub in PARMGEN is that there must be no other agents configured in that run time environment.This is so that it can move from LPAR to LPAR. If you running a single LPAR hub now but think that you might want to convert to an HA hub later on, that task will be much easier if you setup the run time environments in PARMGEN now to anticipate that eventuality by creating a run time environment in PARMGEN that only has the hub component in it.
One RTE equals one LPAR
There is no hard and fast rule as to which agents and components you define to run within any given RTE but in general I have found that using a policy of one RTE equals one LPAR works best. There are a number of reasons for this:
- There’s far less work to run the jobs to gen everything in a single system.
- Since everything for the LPAR is in single parameter deck it’s much easier to be consistent with changes that affect all components in the environment, especially if you use system variables.
- You’ll use less disk space for run time data sets since many can now be shared by everything in the environment.
Use System Variables
Instead of hard coding the value everything in an RTE parameter deck, you can use symbolic name such as &SYSNAME. and &SYSCLONE. in many of the parameters. When you do this, run time parameter members and JCL decks are created with symbolic names that are resolved at execution time from the values defined on the run time system. The benefits of this are:
- Reduced maintenance. You can use a single common JCL deck for an address space in a common (to the Sysplex) JCL proclib. Data set names and parameters will resolve to values that are unique to the system the address space is executing on.
- You can use PARMGEN to create a copy (clone) of an RTE to run on another LPAR very easily and with minimal changes, thus reducing the time it takes to get an new RTE up and running and also improving reliability since fewer changes are required to the new RTE to configure it for the new LPAR.
Create a Model RTE
One of the powerful features of PARMGEN is the ability copy or clone an existing RTE into a new one. This saves you the effort of creating each RTE from scratch. When the mix of agents in each RTE differs from LPAR to LPAR then I have found it useful to create a minimal RTE that I use as the model for other RTEs. In my model RTE I have a remote TEMS, the base z/OS OMEGAMON components (product code OB) and the OMEGAMON XE on z/OS product. I also use system variables.
The best way to create model like this is to create an actual RTE with just those components in it and then gen and deploy it. Once you have it all working, connecting to the hub and data from the z/OS agent in the TEP and the E3270 User Interface, clone it into the model RTE. That way you know that any RTE you create from this model is based on a working example and should require minimal changes (especially if you are using system variables) to get it up and running.
To create a new RTE, I clone the model, add in any new agents and configure then in the RTE parameter deck. Then I gen the new RTE and deploy it. Using this technique, I have been able to create a complete working RTE with additional agents in it very quickly.
Build up an RTE in stages
Using the model approach described above, I have found the simplest way to create a working RTE with additional agents in it is to add them one at a time. Adding a new agent such as OMEGAMON XE for CICS on z/OS, configuring it, then generating, deploying and testing it can be done very quickly. This makes it much easier to diagnose and correct any problems with the new configuration and, since you are only adding one agent at a time you can concentrate on ensuring that it works correctly when deployed and that the existing elements continue to work as normal. It also has the benefit of allowing you to concentrate on each agent in turn as you add it which reduces the amount of information you need to research in order to set parameters.
Deploy Procs etc to ‘staging’ libraries
By default, PARMGEN is configured to write JCL procedures, VTAM node definitions and other components that need to be in ‘system’ libraries to the default system libraries such as SYS1.PROCLIB and SYS1.VTAMLST.
You probably do not want to do this. Instead I configure PARMGEN (via the $GBL$USR member in WCONFIG) to place these elements in my own ‘staging’ libraries. That way:
- I am not going to overwrite a ‘live’ element.
- I don’t need RACF authority to write to system libraries.
- I can check everything before copying it into the actual live libraries.