BMC Software Subsystem

RUV products use two BMC Software standard subsystems for resource management: the BMC Primary Subsystem (BMCP) and the BMC Consolidated Subsystem (BCSS).

A major benefit of using a subsystem architecture is that virtual storage requirements in user address spaces are significantly reduced. The RUV subsystem architecture offers an additional benefit—increased ability to ensure data integrity.

Warning

RUV products can share BMC Software subsystems with other BMC Software products. Some commands discussed in this section might affect those BMC Software products. For more information, see the documentation for those products.

The BMCP and the BCSS are maintained independently of the RUV products; their maintenance levels do not correspond to the maintenance levels of the RUV products. When you install a new or updated product that uses the BMCP and the BCSS, use the Installation Check program to determine the level of the existing subsystems against the level of the subsystems from the distribution tape. For RUV products, always use the highest level of subsystem code available.

This topic contains the following information:

BMCP

The BMCP establishes supervisory services for the BCSS, RUV, and many BMC Software products. It allows interception of open, close, attach, and link requests in the system.

Several products share the BMCP; however, you can have only one copy of the BMCP on a z/OS system.

Note

If you are running the BMC Software DATA ACCELERATOR Compression product, the BMCP is already installed.

All associated products continue to operate normally even if the BMCP terminates; however, it is recommended that you leave the BMCP running at all times.

BCSS

The BCSS manages I/O to the registration data sets (collectively called the REGISET or repository), manages APF-authorized functions, and performs processing for intercepted open, close, attach, and link requests.

The BCSS performs most of the I/O to the repository during initialization and termination of the step. A small amount of I/O is performed during application program execution.

The BCSS must be active on the z/OS system where you want to execute application programs that use RUV and where you want to access records in the repository through the ISPF interface. You can use the RUV Status Check utility RUVZVML to ensure that required RUV products, components, and functions are available for application execution.

Multiple BCSSs

More than one BCSS can be active on a z/OS image. Non-RUV products, such as DATA ACCELERATOR, can share a BCSS (and the repository) with RUV products or use a separate BCSS (and repository). The BMCP ensures that each BCSS receives control at the proper time for the products using that BCSS.

Whether you use the same BCSS or different ones depends mainly on how you want to manage repository access. To isolate the I/O effects of the products, use multiple BCSS subsystems. If the repository activity is not an issue, multiple products can use the same BCSS.

You must use the MODE parameter in the startup procedure to designate one (and only one) BCSS on a z/OS image as the public BCSS. All others must be designated as private subsystems. The BMCP allows the public BCSS first access to an intercepted request.

A default BCSS can be designated for all RUV products on each z/OS; this default is for use in migration from an earlier version of RUV products. The BCSS identifier (ssid) identifies the subsystem (and repository) in commands and interfaces that work with the BCSS.

Subsystem procedure names

The RUV Install System provides two subsystem procedures, one to start the BMCP (default procedure member name BMCP) and one to start the BCSS (default procedure member name BCSSRUV$). Each procedure contains the required parameter and statements for the subsystem. If either default name conflicts with the name of another procedure member, you can use a different member name during installation.

Note

SYS1.PROCLIB is not usually a shared procedure library. If the procedure name and the subsystem ID are identical (which they are if you use the installation defaults for the BMCP) and the procedure is in a non-shared library (such as SYS1.PROCLIB), z/OS runs the subsystem under the master scheduler. After the first attempt to start the procedure, any subsequent attempts to start it result in a “procedure not found” error unless you specify the SUB=jesid parameter (jesid is the JES2 subsystem ID) on the subsystem start command. For example, use the following command to start the BMCP if your JES2 subsystem ID is JES2:

S BMCP,SUB=JES2

Subsystem identifiers

You must use a four-character name to identify the BMCP and the BCSS to z/OS. The RUV Install System uses the default names BMCP and BCSS. If either name conflicts with a non-BMC Software subsystem installed on your system, you can use the SUBSYSID parameter in the BMCP or BCSS startup procedure to change the subsystem names. If you change a subsystem name after the subsystem starts, you must perform an IPL.

Specifying general BMC Subsystem parameters

There are two types of BMC Subsystem parameters, required and optional. Unless a required parameter is not specified or incorrectly specified, there is no difference in the processing of these options. An operator PROMPT is issued regardless of the NOPROMPT setting.

The BMC subsystem offers many parameters to tailor the operation and function of the subsystem. For example, you can cause a reload of executable modules in common storage to effect maintenance changes without an IPL.

You can select parameter values in the following ways:

Specify them in the PARM field of the procedures JCL EXEC statement for the BMC subsystem start up
Specify them in the actual START command during BMC subsystem start up

You can specify the parameters in any order. If a conflicting parameter is requested like PROMPT and NOPROMPT then the last (or right-most) parameter is utilized.

If two or more parameters are specified, the list of parameters must be enclosed in single quotation marks or parentheses. Commas must separate each parameter. The parameter list can be no longer than 100 characters, including commas.

CPU authorization passwords

For RUV products, the BCSS validates CPU authorization passwords. For more information about CPU authorization, see BMC-Software-product-authorization.