Planning a target context definition

Target context definitions impose certain requirements.

This topic describes issues that must be considered as part of the overall planning of a target context definition. When you plan your target context definitions, consider the following issues:

• Verify that you are authorized to access each system.
  
  
• Ensure that cross-system communication is established between the local CAS and each remote CAS that provides data from a target context that is part of the definition. If VTAM communication links are not established between CASs, data cannot be accessed from those target contexts. For information about establishing cross-system communication, see Define-cross-system-communication.
  
  

• Determine whether you need to create a target context definition for local or remote products that monitor critical systems.

  The CAS reports products that are active. If you want to know about a product that is not active, you can create a target context for that combination of target and product. A target context allows the CAS to report on product availability through the Plex Manager views.
  
  

• Target context definitions allow you to define a unique security profile for each target even when multiple targets are monitored by the same BBI-SS or z/OS PAS.

  If you need to create a target context definition in order to apply a specific security resource definition member to a product, determine the two-digit suffix of the security resource member (created through the SERDEF view for the product) by displaying the SERDEFL view in that product.

  If a security profile for a target context is not specified, the product security resource definition 00 suffix is used. If that does not exist in the BBSECURE data set, the default security resource definitions that are supplied by BMC are used.

  The default security configuration provides security calls for all resources in your product. In a shared DASD environment where all PASs across systems share the same security parameter library, you may need to define a different security resource definition member to one or more products. For example, you might want your production system products to have different security parameters than your test system products. Because CMF MONITOR and MainView for z/OS share the same security parameter library on each system image, you can define a default security resource definition member to CMF MONITOR and a different security resource definition member to MainView for z/OS or vice versa.

  If you change the security resource parameter member for a product, you must recycle the address space that supports that product to make the change effective:

  • For Plex Manager, the CAS must be recycled.
  • For the following products, the z/OS PAS must be recycled:
    • CMF MONITOR
    • MainView for z/OS
    • MainView for Unix System Services
    • MainView VistaPoint
    • MainView SYSPROG Services
  • For the following products, the BBI-SS PAS must be recycled:
    • MainView AutoOPERATOR
    • MainView for CICS
    • MainView for DB2
    • MainView for DBCTL
    • MainView for IMS Online
    • MainView for MQ
  • For all MainView products (except MainView FOCAL POINT), the product-specific PAS must be recycled.

  By default, target context definitions are added to a BBPARM library member with a suffix of 00.

  If the default member is used, the instructions in Enabling-a-target-context-definition-member-in-the-local-CAS can be skipped.
  
  

• In a shared DASD environment, if all CASs use the same target context definition member and share the same parameter library, you need to maintain only one definition member.

  For customization or maintenance, you can

  • Define or change the target context definitions in a target context definition member for one CAS
  • Enter a single command from the TGTDEF view of all other CASs
  • Recycle the affected product PASs (necessary only if the security resource parameter has been changed)