AIOps: Monitoring and Observability - Group home

Fixing PARMGEN configuration before migration to IBM Z® Monitoring Configuration Manager



More and more users are migrating from PARMGEN to IBM Z® Monitoring Configuration Manager. The migrating journey can be extremely simple if your PARMGEN configuration is in a good shape and there are no manual modifications to configurable members. However, if there are any, then this article might help you to prepare your PARMGEN configuration for a flawless migration.

There are six libraries within the IBM Z® OMEGAMON® runtime environment that contains configurable members:


These members can be and should be configured using PARMGEN and standard PARMGEN parameters or Embed Overrides.

Unfortunately, sometimes users are intentionally (or unintentionally) manually updating members inside runtime data sets. Such actions make it increasingly difficult to perform standard maintenance. This makes it close to impossible to upgrade products within the runtime environment or to migrate to Configuration Manager without damaging the runtime environment.

This article addresses this issue and provides a relatively easy step-by-step guide on how to synchronise your PARMGEN configuration with actual values inside configurable members. 

First step: Identify and isolate

Identify and isolate all manual changes inside the PARMGEN runtime environment members.

To do that, you can use the PARMGEN tailored JCL job KCIJPSPC to compare WK* libraries against RK* libraries (compare WKANSAMU against RKANSAMU).

Open PARMGEN utility panel, and choose option 27.

  Submit a utility job (Maintenance):                                         
                        Description                                  Job/Label
        -----------------------------------------------------------  ---------
    20. Refresh IK* templates/WCONFIG *$IBM profiles.                KCIJPUP1 
    21. Convert an ICAT RTE Batch member.                            KCIJPCNV 
    22. Merge profile from a backup LPAR RTE profile.                KCIJPMCF 
    23. Validate PARMGEN profile parameter values.                   KCIJPVAL 
    24. Back-up WK* work user libraries.                             KCIJPCPW 
    25. Back-up RK* product execution user libraries.                KCIJPCPR 
    26. Recall migrated DEMO RTE datasets.                           KCIJPHRC 
    27. Compare work and runtime user libraries.                     KCIJPSPC 
    28. Empty runtime members in RK* user libraries.                 KCIJPMTY 
    29. Copy WK*->RK* user libraries keeping EXCLUDE members.        KCIJPW1R 
    30. Restore back-up user libs. to current set.                   KCIJPB2R 
    31. Resolve system symbolics in PARMGEN jobs.                    KCIJVSRV 
    32. Collect diagnostic information for this RTE.                 KCIJPCOL 
    33. Delete RTE: DEMO                                             KCIJPDEL 

Note: Depending on your screen resolution, you might have to scroll down to see all the options on the panel. Look for the MORE+ that indicates there are additional options.

This job will compare all libraries with configurable members against working data sets and will write a result to rte_plib_hilev.rte_name.WSUPERC (TDCIT.HLQ.DEMO.WSUPERC). The following comparisons are performed:

  • RKANPARU compared with WKANPARU
  • RKANSAMU compared with WKANSAMU
  • RKANCMDU compared with WKANCMDU
  • RKD2PAR compared with WKD2PAR
  • RKD2PRF compared with WKD2PRF
  • RKD2SAM compared with WKD2SAM

Open rte_plib_hilev.rte_name.WSUPERC data set in view mode and issue the following command:

res; x all; hide x; f 'TOTAL CHANGES' all

This command filters the results and helps you to quickly identify data sets and members that are impacted. 

If you find only 0 (zeros) before ‘TOTAL CHANGES’ it means that your runtime environment is in sync with your PARMGEN parameters. Congratulations! Your migration to Configuration Manager will be flawless.

However, if there are changes (see example below), then you have to identify the data sets and  members that are impacted. 


Issue the following command to filter impacted members only:

res; x all; hide x; f R'NEW:.+([\(])' all

This command produces a list of members that most likely were manually modified and should be fixed. 



You now have a list of all members that are impacted and can start looking for parameters within PARMGEN configuration that can fix those members, as described in the next step.

Second step: Fix impacted members

In first step, you identified impacted members, and you are now ready to start fixing your PARMGEN configuration. 

Continue viewing the rte_plib_hilev.rte_name.WSUPERC data set. It contains all the information needed to identify manual changes.

Now, have to go through the list of impacted members and review the differences. Issue the following command to view differences for a specific member:


Note: The string depends on the list produced in the first step.

The following example shows the result of the previous command:

                     LISTING OUTPUT SECTION (LINE COMPARE)                                                
ID       SOURCE LINES                                                                TYPE  LEN N-LN# O-LN#
I -  HTTP:1920 USE:Y \                                     
D -  HTTP:1921 USE:Y \                                                                                    
I -  IP.PIPE PORT:1918 \                                                              
D -  IP.PIPE PORT:11918 \                                                                                 
I -  IP6.PIPE PORT:1918 \                                                            
D -  IP6.PIPE PORT:11918 \                                                                                
I - *KOE_MFSB_WUI=600                                                              
D - KOE_MFSB_WUI=600                                                                                      
I - *KOE_MFSB_MDI=18000                                                             
D - KOE_MFSB_MDI=18000                                                                                    
I - *KOE_MFSB_TBI=18000                                                          
D - KOE_MFSB_TBI=18000                                                                                    

Here you can see that there are 6 lines that do not match in the KDSENV member. To identify PARMGEN parameters that are responsible for those differences, you can simply look for the values or search in IBM Documentation.

You should tackle the differences one by one.  The following example shows the first identified difference:

I -  HTTP:1920 USE:Y \                                     
D -  HTTP:1921 USE:Y \                                                                                    

Here you can see that WKANPARU(KDSENV) member contains original value of 1920. However, the runtime member RKANPARU(KDSENV) has a different port value: 1921. To locate a parameter responsible for this line. Review your configuration as follows:  

  1. Open the rte_plib_hilev.rte_name.WCONFIG(rte_name) member
  2. Exclude all lines, and find all the occurrences of the value 1920.  It is important to search for the original value from the WK* libraries:
    x all; hide x; f '1920' all

    The result of the search will look like the following:

    KDS_TEMS_HTTP_PORT_NUM            1920     * HTTP port number

  3. You can now review IBM Documentation about this parameter to ensure it is correct, and then change the value from 1920 to 1921. Don’t forget to save the member.

Good! You have successfully fixed the PARMGEN configuration for this parameter; during the next  maintenance process, the KDSENV member will use port 1921. 

Repeat these steps to rectify each of the differences for all members in the list. If you are not able to locate the value, you can search IBM Documentation or try to find part of the variable name instead. 

Embed overrides 

Sometimes differences are coming from Embed Overrides that cannot be controlled using regular parameters. 

The following example shows another difference in the KOBENV member:


The KOE_MFSB_WUI parameter cannot be located inside the WCONFIG(rte_name) member. 

Therefore, to understand if this parameter is controlled by Embed Override members you have to open the WKANPARU(KOBENV) member directly and look for the parameter there.

Embed overrides can be easily identified. Usually those overrides are located inside the code block as shown in the following example:

* ******************************************************************
* Member: KDS$PENV   
. . . member description . . .

* *******************************************************************
* *******************************************************************

. . . overrides are here . . .

** ----------------- END   - USER SECTION: OVERRIDE ---------------- *

If you found your parameter within this code block, it means that you can control it using embed override members located in the rte_plib_hilev.rte_name.WCONFIG data set. 

The required member name in this example is KDS$PENV. Alternatively, to find the required member name you can simply do a SRCHFOR against the WCONFIG data set.

For example:

srchfor KOE_MFSB_WUI

The result is the same:

  Menu  Functions  Confirm  Utilities  Help                                    
VIEW              TDCIT.HLQ.DEMO.WCONFIG                       String(s) found 
Command ===>                                                  Scroll ===> CSR  
           Name     Prompt       Size   Created          Changed          ID   
_________ KDS$PENV *Found                                                      
_________ KDS$PSYS                                                             
_________ KDS$PTEC                                                             
_________ KDS$SDMP                                                             

You can now edit the KDS$PENV member, locate the KOE_MFSB_WUI parameter, and remove the asterisk from the first column. 

When you have reviewed all changes in all members and fixed the required parameters, you can proceed to the next (and final) step.

Third step: Regenerate WK* libraries

After you have updated all the parameters and embed override members, you can proceed with this step.

In this step, you will re-generate the following working data sets using new parameters and embed overrides:


To achieve this, simply run the PARSE step in PARMGEN. You can regenerate data sets, or you can regenerate each individually (press PF5 for individual generation).

KCIP@PR1 -------------- CREATE THE RTE MEMBERS AND JOBS -----------------------
Option ===>                                                                    
Select option 1 to SUBMIT the full $PARSE job in WCONFIG for   RTE=DEMO.       
$PARSE composite job creates product runtime members and jobs in    all the    
PARMGEN WK* work libraries.                                                    
o: Press F5 to access the library-specific $PARSE* jobs (ideal in an RTE       
   reconfiguration scenario). First-time RTE deployment must run $PARSE.       
o: Select R to submit the KCIJPUP1 job to refresh the IK* product and          
   WCONFIG *$IBM profiles before recreating the runtime members.               
Enter ns (1s-2s) for detailed job/task status.                                 
                   Description                    Job Name   Status     Date   
   ---------------------------------------------- -------- --------- ----------
R  Refresh IK* templates/WCONFIG *$IBM profiles.  KCIJPUP1  
1. Create runtime members/jobs in all WK* libs.   $PARSE    
Press F1=Help for more information.  Type U or UTIL to access utility menu.    

For this example, regenerate all libraries by submitting the $PARSE JCL job. (Option 1)

The $PARSE job regenerates working data sets only, so it will not impact any of your running started tasks or other actively used data sets. 

After this job is completed, you should go back to the first step, and compare your WK* data sets against your RK* data sets again. 

Repeat these until your WK* libraries are exactly the same as your RK* libraries.