This site will undergo a maintenance outage on Saturday, 13 September beginning at 2:30 AM Central/1 PM IST for a platform upgrade. The downtime will be ~three hours.

Reusing infrastructure components

The DBC is meant to be a long-running address space that starts shortly after an IPL and stops immediately before the next IPL. The DBC allows BMC products to be dynamically defined. You can recycle product agents within the DBC without interfering with other products that use the DBC and without requiring you to stop the DBC started task.

The infrastructure components are designed to have one release that is updated solely through applying PTFs. If a component does require a new release, the upgrade to the new release will be seamless.

Important

Although certain components might have new releases (FMID changes), their definition to the 

DBC

 retains the same version number from release to release so you can upgrade the components in place.

Related topic

Modifying-infrastructure-components

Installing infrastructure components automatically downloads the component files and the latest maintenance. Any new product agents will be defined to the DBC and started.  Some products do not have agents in the DBC but use existing component agents (such as LGCand NGL). Products that use LGC will be registered to LGC and option sets will be created or migrated from a previous release. Products that use NGL will have their piid defined at the first request from the product. If present, the DBC agents DOM and MVL will be stopped and restarted along with their PIIDs when those products are upgraded.  For other products that use an NGL PIID but that do not have an agent defined to the DBC, those PIIDs might need to be restarted manually to use the latest code base from an installation of NGL. In this manner, the components will be updated in place and the agents will be recycled in order to refresh the code. 

Reusing RTCS

In some environments, RTCS is managed by a different group in a different SMP/E zone. In this scenario, you should choose the option in the Installation System to deselect RTCS. Doing so prevents it from being downloaded in your new zone and from having more than one copy of the code, which could cause confusion over maintenance levels.

Important

When deselecting RTCS, a panel in the Installation System will indicate the PTF level required by the products that will be interacting with RTCS. Ensure that you apply this level of maintenance before using those products.

If you decide to download RTCS into your SMP/E zone, you will have the opportunity to reuse your existing RTCS. An LPAR can have only one active RTCS started task. If you already have RTCS installed and you plan to apply all the maintenance from the new zone, indicate that you want to reuse RTCS in the Installation System. Doing so prevents you from having to answer configuration questions in the Installation System for RTCS. To have RTCS use the new code, perform the following steps:

  1. Replace or update the existing RTCS load libraries referenced on the RTCS started task.
  2. If you are in a continuous operation mode, review each PTF, and proceed accordingly:
    • If none require an RTCS Cold Start, refresh the packages using the RTCS REFRESH command.
    • If an RTCS Subsystem Restart is desired:
      1. Bring down the current RTCS started task.
      2. Bring up the new RTCS started task referencing the updated libraries.
  3. Restart the RTCS started task.

Important

The products that interact with RTCS require a minimum maintenance level. If the minimum level is already present, you can delay recycling RTCS until a more convenient time. If the products do not detect the required minimum PTF level, they display an error message.

If you are installing RTCS for the first time, do not deselect it from being downloaded, and do not indicate that you want to reuse it. The Installation System will help you configure RTCS and provide instructions about how to start RTCS.

Reusing DBC

If you already have an existing DBC, compare the newly generated DBC$STC procedure and its comments with your existing procedure and make any necessary changes. The data set referenced on the DBCENV DD in the procedure will contain members that control the startup parameters for the DBC agents. The $420INF installation job will copy, replace, or update the pppvvrm members (where ppp is the 3-character product code and vvrm is the version, release, and maintenance level of the product being installed). These members are expected to change values with each installation (such as data set names or plan names). These members can be staged and will not be acted on until the $490TRIG job is run, which tells the DBC to redefine and restart the agents.

Once the DBC has started the agents, a pppOPTS member will be created if it does not already exist and will be written to the DBCENV data set. This member contains product options that are not expected to change from one release to another (such as agent startup parameters). However, if any values need to change for a DBC agent, this member can be edited and a command to refresh the agent can be issued: 

/dbcssid DBC,EXEC,ppp 

  • dbcssid is the DBC subsystem identifier
  • ppp is the product code

If a DBC repository data set (referenced in the $DBCssid DBCPARMS member) contains the agent definition for the product being installed, the existing product options will be extracted from the DBC repository and written to the pppOPTS member and the definitions will be deleted from the DBC repository. Any products not being installed will remain in the DBC repository until they are reinstalled or a new version is installed. After all products have been migrated from the DBC repository, the following message will be displayed in the DBCPRINT indicating that the DBCPARMS DD can be removed:

BMCDBC0323I ALL PRODUCT DEFINITIONS ARE REMOVED FROM DBC REPOSITORY 

Eventually, the DBCPARMS member will be deprecated.

The Installation System downloads the DBC component files along with all current maintenance. After you apply DBC maintenance, you must recycle the DBC started task to load the new code. Normally, products can be upgraded ahead of the infrastructure so that you can upgrade the products in place without stopping other products using the DBC services.

Best practice
BMC recommends deploying maintenance to the DBC during a maintenance window in cooperation with other users of the DBC services.

Reusing NGL

When an NGL PIID is started for the first time, an NGLpiid member is created and written to the DBCENV data set. Default options for PIIDs are taken from the NGLOPTS member in DBCENV and the new PIID is added to NGLOPTS, which also contains a list of PIIDs to start automatically at DBC startup. The NGLpiid member contains values that are specific to that PIID (such as its registry data set). If a PIID needs a value other than the default in NGLOPTS, the keyword should be copied to the NGLpiid member and the value changed there. A DBC,EXEC,NGL,piid command can then be issued for the PIID.

Important

We recommend using the supplied product specific NGL PIIDs. If your product does not have a specific NGL PIID, or if you are required to change the supplied product PIID, then create a unique four-character PIID for the product use.

If a DBC repository data set (referenced in the $DBCssid DBCPARMS member) contains NGL PIID definitions, all existing PIIDs will be stopped, their options will be extracted from the DBC repository and written to the NGLpiid member, and the definitions will be deleted from the DBC repository. Eventually, the DBCPARMS member will be deprecated.

The Installation System downloads the NGL component files along with all current maintenance. NGL will not be upgraded automatically; it will only be upgraded when the DBC started task is restarted or if the DBC,EXEC,NGL command is issued, which will stop and start all NGL PIIDs. However, if a product agent uses a PIID, the agent will be stopped and restarted along with its PIID. (Individual PIIDs can be restarted by adding the PIID to the end of that command). 

Normally, products can be upgraded ahead of the NGL infrastructure so that you can upgrade the products in place without taking an outage for other products using the NGL services.

Best practice
BMC recommends deploying maintenance to NGL during a maintenance window in cooperation with other users of the NGL services.

Reusing LGC

When a product that uses LGC is installed or upgraded to a new version, the new pppvvrm member in the DBCENV data set will be read. The new product version will be registered with LGC and any option sets from a previous version will be migrated and updated with new values as necessary.

LGC will be upgraded automatically when any product that uses its services is installed.

Best practice
BMC recommends deploying maintenance to LGC during a maintenance window in cooperation with other users of the LGC services.

New or updated product definitions in the DBC

All new product definitions will automatically be defined to the DBC and started when the $490TRIG job runs. This job will update the DBCPRODs member in the DBCENV data set to reflect the new pppvvrm member with the new values. The DBC will define or redefine the product agents, their registrations to LGC (including migrating any option sets from the previous version), and stop or start the DBC agents.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*