Posts Tagged ‘OMEGAMON’

PARMGEN and System Libraries…

August 12, 2013 Leave a comment

The deployment phase (step 11 on the menu) of creating and loading an RTE with PARMGEN copies all the run time data to the run time libraries.  Some of these members need to go into system libraries such as SYS1.PROCLIB and SYS1.VTAMLST or your user versions of same.

Rather than overwrite my current live run time procedures and VTAMLST members I configure PARMGEN to write them to  ‘staging’ libraries. From there I can double check them against the current live members before committing them.

To configure PARMGEN to write to your own system data sets, edit the $GBL$USR member in WCONFIG by selecting option 8 on the main menu and then option 2 and change the highlighted lines shown in this screen shot:


You have to manually create these data sets yourself but that is easy enough using ISPF option 3,2.

After the initial deployment, most of the time you will only need to copy run time JCL from the proclib and possibly vtam list members from the vtamlst staging libraries to your actual live system data sets.



April 1, 2013 2 comments

The PARMGEN configuration tool can be a little daunting and overwhelming when you first start to use it but the reality is that it is really pretty simple to use. This article walks you through creating an initial Run Time Environment (RTE) from scratch. This example assumes the RTE being created will run on the same LPAR that you are running PARMGEN on.

It’s probably simplest to think of an RTE as all the ITM and OMEGAMON components that you want to run on a single LPAR. To keep things simple though, I suggest you only configure one agent initially, get that running and then add others in later on, one at a time. Once you have a working RTE with everything in it, it becomes simple to clone it later on to create RTEs for other LPARs.

Start PARMGEN by entering the command EX ‘hlq.TKANCUS’

Where hlq is the hilh level qualifier of the SMP/E TKANCUs install library. That will bring up this screen:


Select option 5 “Configure z/OS products with Parameter Generator Workflow (PARMGEN)”. That will bring up this screen:


PARMGEN needs some initial information to get started.

In the GBL_USER_JCL field, enter the name of a partitioned data set that PARMGEN is to use to contain various control members and JCL decks. If the data set does not exist, PARMGEN will create it for you.

In the RTE_PLIB_HILEV field, enter the high level qualifier of the work data sets that PARMGEN will need to create for each RTE. The work data set names will be of the form RTE_PLIB_HILEV.rtename.something.

Now lets go through the steps to create an initial basic RTE with just one product (I’ll use OMEGAMON XE on z/OS for this example):

Since this is the first time using PARMGEN, the RTE_NAME field will be empty so enter an name for the RTE. Typically I use the SMF ID of the lpar.

Select option 1.

This creates the work data sets needed by PARMGEN for this RTE. You will be presented with a series of screens:

On this screen(KCIP@PG1), enter any job card information but leave the rest empty and press enter:


On the next screen (KCIP@PG2) leave GBL_INST_HILEV empty (this is new RTE from scratch, not a conversion from ICAT), enter any unit/volser/etc information needed for the SMP/E install libraries (TK* data sets) and the unit type for the global work data sets, then press enter.


On the next screen (KCIP@PG3), review the prefilled fields and enter any additional ones needed  for your installation, mostly related to SMS information. Specify the TEMS type (HUB or REMOTE) at the bottom and press enter.


The next screen (KCIP@PG4) will give you a list of all the products currently installed into the SMP/E environment. Press enter to continue:


On the KCIP@PG5 panel, EXCLUDE the products components that you do not want, then change the Confirm flag from N to Y and press enter:


To create an RTE with ITM and OMEGAMON XE on z/OS in it, on the list above I would exclude everything EXCEPT KDS, KM5 and KOB. KDS is ITM and provides the framework in which everything else operates, KM5 is the OMEGAMON XE on z/OS product and KOB is base code needed by OMEGAMON XE on z/OS and also provides the enhanced 3270 User Interface.

As this is completely new RTE, skip the resultant popup by pressing enter:


Submit the KCIJPCFG JCL that is presented. This creates the work data sets needed by the rest of the PARMGEN process.

Select option 4

Submit the job JCL. This will load the work data sets with additional members.

Select option 8

Edit the $GLB$USR member

From this menu, select option 2 first (You’ll only need to do this step this one time, even if yo make changes to the RTE later on so let’s do it now):


The $GLB$USR member of the WCONFIG work data set is the user copy (I.E yours) of the IBM supplied defaults member ($GBL$IBM) of the same data set. The IBM supplied member contains default data set names for data sets required by the RTE and also the data sets that will be used to receive things like started task JCL procs.

Th entries in the $GLB$USR member re all commented out but you can uncomment them and change them you your own site specific data set names as required. Typically I do not let PARMGEN override my production SYS1.PROCLIB or VTAM libraries and so change those settings to point at my own staging libraries from where I later manually copy the members as required to my live system libraries.

Edit the RTE member

Now we get to the bulk of the configuration for the RTE. Select option 1 from the menu above and you will be placed in an edit session for the RTE member name in the RTE’s WCONFIG data set.

In spite of all the parameters in the deck, you really only have to change a few initially at least.

You may want to review the communications protocols that the RTE will use. If any are enabled, they should also be enabled at the hub TEMS. Typically I remove the SNA option but your site will have it’s own requirements.

You may also need top change the default IP ports to be used by the environment but if possible, stick to using the defaults (1918 etc).

If this RTE is NOT a hub you will need to specify the ip address (in KDS_HUB_TCP_HOST) and port (in KDS_HUB_TCP_xxxx_PORT_NUM) of the hub.

Each product is configured within its own section in the RTe member so they are easy to find. Just go though the in turn (only configuring a couple of product to start with keeps this as simple as you can get it) and set anything that needs changing. for the most part you’ll only need to change things like VTAM node names and possibly started task JCL member names.

Since this is your first RTE, it’s probably going to be for a test system so if possible turn off (do not configure) any security to keep things a simple as possible. I would also suggest NOT using system variables initially, you can always change that later on.

Once you are done, PF3 to save and exit, then pf3 back to the main PARMGEN menu.

Select option 9

When not using system variables for an RTE, I always run step 9 to validate the RTE before proceeding. submit the job JCL that is presented. When the job completes, if it has any errors, you can see the validation report in WCONFIG($VALRPT) by entering 9S on the main menu (press enter to clear the job information that is initially displayed and go to the report).

The first part lists the input data sets and numbers them.

The second part (labeled section 1) lists any errors along with the input data set number and the line number within that input deck.

Make a not of any errors, then go back to step 8 and make changes to the appropriate members (probably only $GBL$USR or the RTE member), then rerun step 9 to validate the input again.

Select Option 10

The $PARSE step takes all your input and loads the interim work data sets with everything needs for the actual generation process which is coming up next.

Select Step 11

This brings up the submit menu. While you can run the jobs individually, it’s probably simplest initially, to just select the KCIJPSUB composite job and run them all in one go.

Deploy the RTE

If you changed the $GBL$USR member to specify staging libraries for data sets such as SYS1.PROCLIb and SYS1.VTAMLST then you can review the members in the staging libraries before copying the members you your systems live libraries.

At this point you should be able to start the stated tasks and have the environment come up on this system. Remember, this example assumes you are running PARMGEN on the SAME system that the RTE will execute on.

Making Changes

Now that your RTE us up and running, to make changes do the following:

From the PARMGEN main menu, Select option 8 and then select option 1 to edit the RTE member.

Make the changes you need to the RTE parameters.

Select option 9 from the PARMGEN main menu to validate the RTE. If anything is wrong, edit the RTE again and repeat.

If no errors, select option 10 to run the $PARSE step.

Then select option 11 (submit) to build the RTE. You can safely run the composite job again or you can run individual jobs if you know what the change you made affected.

Deploy any changed members in the staging libraries if using and restart the started tasks.


While the above may seem like a lot to read, it actually takes far less time to do than it does to read and once you have the RTE up and running, making changes is just a matter of changing the parameters in the RTE deck and regenerating everything.

Categories: ITM, Mainframe Tags: , ,

Updated PARMGEN books

March 18, 2013 Leave a comment

The PARMGEN books have been updated. Information and links to the new books can be found here.

Categories: ITM Tags: , ,

SNMP Traps from IBM Tivoli Monitoring (ITM)

May 10, 2012 1 comment

You can configure IBM Tivoli Monitoring (ITM) to send SNMP trap data to an SNMP receiver application such as HP open View when ITM monitoring situations become true. This article describes how to do that for the OMEGAMON XE monitoring agents that run in a z/OS environment.

The situations you want to send as SNMP traps for each agent are defined in an xxTRAPS configuration member in one of the PDS data sets allocated to the RKANDATV DD in the agent address space. xx is typically, but not always, the same as the agent product code. For example for CICS (product code CP) the SNMP configuration member would be called CPTRAPS. But for DB2 (product code DP), the member is called D5TRAPS.

The easiest way to find out which xxTRAPS members the agents in a TEMS or TEMA address space wants to use is to to browse the output of the RKLVLOG DD in the TEMS or TEMA and look for the string “TRAPS.RKAN”.

Typically it will look something like this:

*INFO: Local SNMP Trap configuration file name <M5TRAPS.RKANDATV> in effect

You can see that in this example it is looking for the M5TRAPS member (for the z/OS agent).

If the xxTRAPS member does not exist then typically you will see the following sort of message in the RKLVLOG:

KRAX005I, Unable to open XML definition file: M5TRAPS.RKANDATV, reason: ENOSYS, Producer(XML Parser)

Followed by:

KRAS022I, SNMP trap configuration definition failed. Agent trap emitter feature disabled, Producer(SNMPTrap Emitter)

When the trap definition member for an agent is found you should see something like this:

KRAS023I, SNMP trap configuration successful. 1 SNMP trap destinations and 4 situations defined, Producer(SNMPTrap Emitter)

The xxTRAPS Member

This is a sample xxTRAPS member, in this case for a CICS agent, so the member name would be CPTRAPS:



<Situation name=”CICS_Storage_Violation” target=”SOMENAME” />
<Situation name=”CICS_SOS” target=”SOMENAME” />


The TrapDest entry tells the emitter where to send the SNMP traps to. ‘name’ is just an arbitrary name used to connect the situation entries to a destination. You can have more than one TrapDest entry and thus send SNMP trap data for different situations to different target destinations.

Stat=”N” simply tells the emitter NOT to send EE_ (life cycle status events) trap data to the target. EE_ traps record events such as heartbeat data used by the ITM infrastructure.

Each ‘Situation’ entry defines the name of one monitoring situation for this agent that is to be sent as an SNMP trap to the target destination indicated by the named TrapDest entry.


You should only define situation names for the target agent in each xxTRAPS member. What that really means is that you should only specify the names of situations that run against say, CICS attribute groups, in the CPTRAPS member and only situations that run against the DB2 agent in the D5TRAPS member etc.

While there is nothing stopping you from putting the names of say DB2 situations into the CPTRAPS member, they will simply be ignored because those situations will never be run by the CICS agent.


You can trace the creation of the trap definition in some detail by tracing the kraaestx module in the TEMS or TEMA.

Add the following to the KDSENV member in the RKANPAR concatenation:


In the RKLVLOG you will see something like this:

    BindAddress –
Type – TRAP
Version – V2
IP   – IPv4
Stat – NO
SNMP Trap Situation Entry:
Severity – <2> Warning
Category – <0> Threshold_Events
Mode     – RC
Interval – 15
SendPred – Yes
Table: – “NULL”
TrapAttrList: – “NULL”


Categories: Mainframe Tags: , ,

New versions of OMEGAMON for z/OS and CICS announced.

February 7, 2012 Leave a comment

IBM announces new versions of IBM Tivoli OMEGAMON XE on z/OS , V5.1.0 and IBM Tivoli OMEGAMON XE on z/OS for CICS , V5.1.0.


Announcement letter

Product specific information:

Tivoli OMEGAMON XE on z/OS

Tivoli OMEGAMON XE for CICS on z/OS

Both of these products utilize the newly designed Enhanced 3270 User Interface that brings new problem solving capabilities to your tool set.


Categories: Mainframe Tags: , ,