Creating tenant definitions in PDS members

Define the customer and the relationships between the customer and the MSLs using PDS members.

About this task

For each tenant, you must define the customer and the relationships between the customer and the MSLs. This process requires the definition of the following components: customer, group, users. Each of these components is defined in a PDS member. By default, the PDS members are located in the UKOBDATF data set that is allocated to the enhanced 3270 user interface address space (allocated to the RKOBPROF DD name). Template members are provided in data set RKOBDATF and must be copied to data set UKOBDATF for customization.
Note: You can change the location of the PDS members using override embed member MULTI_TENANCY_DDNAME.

The following list describes the definitions to be made.

Note: The definitions described in this topic can also be made in RACF for greater security. For more information, see Creating tenant definitions in RACF.
  • Customer. Customers definitions are in member KOBCUST. Each customer entry defines the customer ID, title, and associated MSLs for the customer. The following example shows the format for the customer definition:
    CUSTOMER:customerID,
    CUSTNAME:"customerTitle",
    msType="msl",
    msType="msl",
    msType="msl"
    Where:
    • customerID is the customer ID, which can be up to 10 characters.
    • customerTitle is the unique customer descriptive title, which can be up to 50 characters.
    • msType is the managed system type. A separate definition is made for each type. Valid values: ZOS, CICS, IMS, DB2, CTG, MQ, QSG, IIB, STOR, MFN, TCP, VTAM, MFAD, JAVA.
      Note: With APAR OA59694, managed system type MFN has been replaced with the following managed system types for IBM OMEGAMON for Networks for z/OS: TCP, VTAM, and MFAD (Administration). It is recommended that you use TCP, VTAM, and MFAD instead of MFN.
    • msl is the name of the managed system list (group) for the respective managed system type. A unique MSL must be specified for each managed system type. If the MSL name ends with ?, then the customer ID will be substituted. See Naming convention for the recommended MSL name format.
    The following example shows a customer definition. For each MSL name ending with ?, the ? is replaced by ACMECORP. For example, CICS="T_C5_?" is converted to CICS="T_C5_ACMECORP".
    CUSTOMER:ACMECORP,
    CUSTNAME:"UNIQUE CUSTOMER TITLE",
    ZOS="T_M5_ACMECORP",
    CICS="T_C5_?",
    IMS="T_I5_ACMECORP"
    DB2="T_D5_?",
    CTG="T_GW_?",
    MQ="T_MQ_ACMECORP",
    QSG="T_QSG_ACMECORP",
    IIB="T_IIB_ACMECORP",
    STOR="T_S3_?",
    MFN="T_N3_ACMECORP",
    TCP="T_N3_TCP_ACMECORP"
    VTAM="T_N3_VTAM_ACMECORP"
    MFAD="T_N3_ADMIN_ACMECORP"
    JAVA="T_JJ_?"
  • Group. Group definitions are in member KOBGROUP. This member defines the groups to which a user will belong. In each group entry, you also specify the first workspace to be displayed at logon and the OMEGAMON tabs to be displayed in the workspace for the group. The following example shows the format for a group definition:
    GROUP:group,FIRSTWS=workspace,
    SHOWEVT=n,SHOWZOS=n,SHOWCICS=n,SHOWCTG=n,SHOWIMS=n,
    SHOWDB2=n,SHOWMQ=n,SHOWIIB=n,SHOWMFN=n,SHOWSTOR=n,SHOWJAVA=n
    Where:
    • group is the group name, which can be up to 10 characters.
    • workspace is the workspace to display at logon, which is an 8-character panel ID.
    • n specifies whether the respective tab is displayed in the first workspace. Valid values are Y and N. The variables and corresponding tabs are as follows:
      Option Tab
      SHOWEVT Events
      Note: Multi-tenancy mode is not supported for the Events tab. The user will see all available resources and will not be restricted to only those resources in the user-defined MSLs for the tenant.
      SHOWZOS z/OS
      SHOWCICS CICS
      SHOWCTG C/TG
      SHOWIMS IMS
      SHOWDB2 DB2
      SHOWMQ MQ
      Note: The MQ tab displays the queue-sharing group (QSG) information. To include QSG information, you must define an MSL for the QSG managed system type for the customer.
      SHOWIIB n/a
      Note: There is not a corresponding tab for the Integration Bus (IIB) agent. To view IIB information, use the Integration Bus option on the Navigate menu.
      SHOWMFN MFN (Mainframe Networks)
      SHOWSTOR STOR (Storage)
      SHOWJAVA JVM
    The following example shows a group definition.
    GROUP:OMEGCICS,FIRSTWS=KOBSCICS,
    SHOWEVT=N,SHOWZOS=Y,SHOWCICS=Y,SHOWCTG=Y,SHOWIMS=N,
    SHOWDB2=N,SHOWMQ=Y,SHOWIIB=Y,SHOWMFN=N,SHOWSTOR=N,SHOWJAVA=Y
  • User. User definitions are in member KOBUSER. This member defines information about individual user IDs. A user can also be defined as a power user or a super user.
    Note: For more information, see OMEGAMON multi-tenancy user types.
    The following example shows the format for the definition of a user:
    USERID:user GROUP:group POWER:Y|N SUPER:Y|N CUSTOMER=customerID
    Where:
    • user is the z/OS TSO user ID, which can be up to 8 characters. A trailing asterisk wildcard is supported (for example, TD*).
    • group is the associated group name, which can be up to 10 characters.
    • customerID is the associated customer ID, which can be up to 10 characters. This parameter is omitted for super users.
    The following example shows definitions for the different types of users:
    USERID:TSUSERA GROUP:OMEGALL  SUPER:Y
    USERID:TSUSERB GROUP:OMEGCICS POWER:Y  CUSTOMER=ACMECORP
    USERID:TSUSERC GROUP:OMEGCICS CUSTOMER=ACMECORP
    USERID:TD*     GROUP:OMEGCICS CUSTOMER=ACMECORP

Use the following procedure to create the customer, group and user definitions in PDS members.

Procedure

  1. Locate and copy the KOBCUST, KOBUSER and KOBGROUP members from the RKOBDATF data set to the UKOBDATF data set.
  2. Edit the new KOBCUST, KOBGROUP, and KOBUSER members in the UKOBDATF data set to define information about the customer, groups and users. Use a file editor such as the ISPF editor to do this. For details about the definitions, see About this task.

What to do next

Because tenant definitions can exist in either PDS members or an external security system, you must indicate the location of the tenant definitions that you want to use. For more information, see Setting the location of the tenant definitions.