Posts Tagged ‘ITM’

Update to the Enhanced 3270 User Interface Security Requirements

December 17, 2013 Leave a comment

In this post I mentioned that the recent OB700 IF1 update had added additional security checking for KOBASE and 04SRV resources and that without suitable RACF (or other security product) profiles to give the user read access to these  resources, users would not be able to log on to the Enhanced 3270 UI.

PTF UA71750 is now available and removes the security checking on these resources. As a result, these additional security profiles are no longer required.



Securing the Enhanced 3270 User Interface with RACF and OB 700 IF1

October 16, 2013 2 comments

In this post I talked about securing the enhanced 3270 User Interface with RACF

Since then a new level of the base code (FMID HKOB700) called Interim Feature One (IF1) has arrived in the form of PTF UA69877. But before you go off and apply that, don’t! Instead apply UA70618 which fixes some issues with the original code that may impact certain users.

In the hold doc (you do read all the hold doc don’t you!) for UA70618 are instructions on setting up new RACF profiles that may be needed if you are using security to protect the Enhanced 3270 User Interface environment. These are the new resources being checked:


You could protect these with the following RACF profiles:


Recently I came across a problem where a customer needed additional RACF profiles setting up  in order to log on to the Enhanced 3270 UI. These are:


The easiest way to add these would be with a UACC or READ but your installation standards may require a different implementation. I believe a tech note will be forthcoming on the issue soon.

This particular user had a default profile of * in the RACF class with a UACC of NONE so anything that was not specifically permitted was rejected. If you do not have such a profile in the RACF class used by the Enhanced 3270 UI then the default action is to allow the request if a profile does not exist which basically allows anyone to do anything unless you specifically lock it down. That approach results in the least amount of work to secure the Enhanced 3270 UI environment.

Categories: E3270UI, ITM, Mainframe Tags: ,

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.

Using HILITE to make make the RTe member easier to read…

April 9, 2013 Leave a comment

The enhanced coloring feature of the editor is an ISPF installation  option and may not be available on your system but if it is, you can use the ISPF HILITE command to make RTE members easier to read.

This is a typical RTE display without any highlighting (think ‘sea of green’):


Entering the command HILITE in the command area of the screen will bring up this menu:


Set the language to Assembler and the Coloring option to 2 and exit (pf3) and now your RTE will look like this:


Categories: ITM Tags: ,


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: , ,

PARMGEN Strategies…

March 13, 2013 Leave a comment

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

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.




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: , ,