Validate Runtime Component System data sets

The Runtime Component System (RTCS) improves the reliability of products based on z/OS by providing support for component-based programming. RTCS must be configured and started on each z/OS system image where BMC AMI Ops products that require a CAS are to be executed.

Only one RTCS subsystem, regardless of its release level, or the MVS SSID and CSCB name selected for use for operator command entry, can be executing on any one z/OS system image. Unlike the BMC AMI Ops CAS, you will not be able to start multiple RTCS subsystem address spaces. This consideration may be important when you select the data set names for the production libraries that will be used by the RTCS subsystems on all of the members of any particular sysplex.

For complete information about RTCS, see theBMC Runtime Component System Configuration and Administration.

This step describes how to validate the following production data sets, which are required for RTCS:

RTCS subsystem program library (POSZRTCS)
RTCS product program library (POSZLINK)
RTCS hypertext document library (POSZHTML)
RTCS Product Authorization Table Library (POSZPSWD)
RTCS system registry

You can use your SMP/E target libraries, but BMC recommends that you allocate production libraries so that your high-availability z/OS system images do not use the same data sets to which you would normally directly apply maintenance through SMP/E. The POSZRTCS and POSZLINK data sets contain IBM DFSMS program objects and must be allocated as a PDSE library. The POSZHTML data set is an ordinary RECFM=VB partitioned data set containing XML and HTML text document members; it should be allocated as a PDSE library, but does not have to be. The content of each library is identical to the corresponding target library maintained by SMP/E.

The RTCS system registry is a VSAM Linear Data Set (VLDS). There is no SMP/E target library provided whose contents could be copied to a production RTCS system registry VLDS. The contents of the registry data set is initialized automatically by the RTCS subsystem each time an empty VLDS is provided for use as the RTCS system registry. The registry can also be initialized by the RTCS OSZRGIMP batch utility program.

It is possible to share all of these data sets among all members of a sysplex, including the RTCS system registry VLDS. Because RTCS is not expected to be updated frequently, only one RTCS subsystem can be running on a single z/OS system image at a time. All RTCS subsystems within a sysplex should be maintained at nearly the same maintenance level (especially with a sysplex-shared RTCS system registry); therefore, BMC recommends that you use a single set of production data sets within any one sysplex shared by all RTCS subsystems on every z/OS system image in the sysplex. To facilitate this configuration, RTCS initialization automatically determines the appropriate default for the DSNAME of every production library in a shared sysplex configuration based on the DSNAME of the RTCS subsystem program library that is indicated in the STEPLIB DD statement in the JCL for the RTCS initiator address space started task PROC (usually, OSZINIT).

You might, instead, want to allocate and use a separate, dedicated set of production libraries for each RTCS subsystem address space on every z/OS system image in a sysplex. This approach is typically used by customers who normally deploy SMP/E maintenance to z/OS system images individually. The DSNAME defaults determined by the RTCS Initiator can be used with this approach too because the default data set names depend only on the DSNAME of the RTCS subsystem program library. The name of the registry data set, however, will not be determined correctly if you use this approach and you are sharing a single RTCS system registry, because the default registry VLDS DSNAME will be unique for each z/OS system image. If you share a single RTCS system registry among all members of the sysplex, but do not want to share all of the other RTCS production libraries, you will need to explicitly specify the DSNAME of the registry VLDS in your RTCS Initialization member. In this case, you can still have a single, shared RTCS Initialization member (or separate members whose contents are identical) for all system images in any one sysplex, but still have a unique set of dedicated RTCS production libraries for each system image.

The above type of flexibility, while still retaining operational and administrative simplicity, is just one example of some features that have been intentionally designed into most RTCS functions.

Although not recommended, instead of sharing a single RTCS system registry among all members of a sysplex, you can indicate that RTCS is to use a dedicated (that is, unshared) RTCS system registry VLDS. BMC does not recommend this approach, because you will not be able to share certain information among all BMC AMI Ops CASs within a single sysplex. Instead, BMC recommends that you use a shared RTCS system registry for all members (z/OS system images) of each sysplex.

The BMC AMI Ops CAS now stores a certain amount of plex-wide configuration information in the RTCS system registry. By sharing the system registry, this configuration information is automatically made available to all CASs on all z/OS system images in the sysplex. The RTCS system registry VLDS cannot be shared by z/OS system images which are not members of the same sysplex, because the z/OS facility used to implement registry data sharing is XCF. XCF does not communicate with z/OS system images that are not members of the same sysplex.

Subsystem program library—TOSZCNTL member OSZINJ71

The RTCS subsystem program library contains the program objects used by the RTCS Initiator and RTCS subsystem address spaces. They include programs for initialization of the address spaces, Dynamic Link Libraries (DLLs) and other programs that are loaded into the Dynamic Link Pack Area (DLPA), and the RTCS subsystem kernel. The RTCS subsystem program library is dynamically allocated by the RTCS subsystem address space. After all required program objects have been loaded, this library is dynamically deallocated so that normal data set activities can be performed when necessary (such as the application of maintenance, backups, and DASD management). This data set is not permanently allocated by the RTCS subsystem address space. It is dynamically allocated when necessary, such as when a REFRESH operator command is entered to cause any updated program objects it contains to be loaded again so that RTCS-dependent address spaces will be able to use that new level of code.

Use member OSZINJ71 as a model to create a separate production RTCS subsystem program library. This sample JCL allocates and copies the SMP/E target subsystem program library into a new (by default, non-SMS-managed) partitioned data set extended (PDSE) library. The low-level index of the DSNAME selected for this production library should be POSZRTCS or OSZRTCS.

The following considerations apply:

BMC recommends that you create a production copy of the TOSZRTCS target library for each sysplex on which RTCS is to run, so that all RTCS subsystem address spaces that run on each member of the sysplex will share the same library.
The subsystem program library that you create must be a PDSE library. BMC recommends that it be allocated as a non-SMS-managed PDSE (that is, no STORCLAS specified), but it can be SMS-managed if desired.
Because it will be dynamically allocated by the RTCS Allocator (OSZMOSYS, the first program to run in the RTCS Subsystem address space), this library must be cataloged. The catalog must be available when RTCS is STARTed.
The name of the data set that you create must be specified in the STEPLIB DD statement of the RTCS Initiator started task procedure (usually, OSZINIT), as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.

This is the only RTCS production library whose DSNAME needs to be specified in a DD statement in a started task PROC. If each of the remaining RTCS production libraries are allocated with a DSNAME prefix that matches this library, along with its recommended low-level index, the RTCS Initiator will be able to derive a matching, default DSNAME for them, which the RTCS subsystem will then use to dynamically allocate these data sets. If not, then the DSNAMEs of the non-conforming production libraries will need to be specified by the appropriate parameters in the RTCS Initialization member (which is usually, OSZINI00) of the MVS Logical PARMLIB data set.

Product program library—TOSZCNTL member OSZINJ73

The RTCS product program library contains program objects used by product address spaces, including batch address spaces, which are managed by the RTCS Generalized Server. For example, the RTCS batch utility programs, such as the Registry Import Utility, are contained in this library. The RTCS product program library is dynamically allocated by the RTCS Generalized Server in each address space in which it executes, whether started task or batch. The data set remains allocated to the Generalized Server address space as long as it continues to execute. This data set is dynamically allocated by the RTCS Initiator address space to verify its existence and contents, but it will not be allocated by the RTCS subsystem address space.

Use member OSZINJ73 as a model to create a separate production RTCS product program library. This sample JCL allocates and copies the target product program library into a new (by default, non-SMS-managed) PDSE. The low-level index of the DSNAME selected for this production library should be POSZLINK or OSZLINK.

If the DSNAME prefix for this library does not match that of the RTCS subsystem program library or it does not have the recommended low-level index, the data set name that you create must be specified by the POSZLINK parameter in the RTCS initialization member from the Logical PARMLIB data set that is used by the RTCS Initiator started task procedure, as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.

Hypertext document library—TOSZCNTL member OSZINJ75

The RTCS hypertext document library contains variable-length record files used by RTCS utilities and product address spaces, including batch address spaces. RTCS batch utility programs, such as the Registry Import Utility, reference members of this library. The RTCS hypertext document library is dynamically allocated by the RTCS Generalized Server, but only when it is known to be needed, whether in a started task or in batch. It is also used in a DD statement in the JCL used to execute certain RTCS utility programs in batch. The data set remains allocated to the Generalized Server or batch address space as long as it continues to execute. This data set is dynamically allocated by the RTCS Initiator address space to verify its existence and some of its contents, but it is not allocated by the RTCS Subsystem address space.

Use member OSZINJ75 as a model to create a separate production RTCS hypertext document library. This sample JCL allocates and copies the target RTCS hypertext document library into a new (by default, non-SMS-managed) PDSE. The low-level index of the DSNAME selected for this production library should be POSZHTML or OSZHTML.

If you do not select a DSNAME prefix for this library that matches that of the RTCS subsystem program library or does not have the recommended low-level index, the name of the data set that you create must be specified by the POSZHTML parameter in the RTCS initialization member from the Logical PARMLIB data set used by the RTCS Initiator started task procedure, as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.

Product authorization table library—TOSZCNTL member OSZINJ84

The RTCS Product Authorization Table library is a PDS or PDSE that contains product license members. Although this library is used for RTCS-based products only (never for BMC AMI Ops CAS-based product), this library is required because it will be dynamically allocated during RTCS initialization to ensure that one is available for the OSZPATLU batch utility program to update and for the RTCS subsystem and RTCS Generalized Server address spaces to dynamically allocate should an RTCS- based product ever be executed.

For customers that have installed RTCS-based products, the POSZPSWD library can be allocated as a PDSE if it will never be used for program objects. If it will be used for ordinary program load modules as well, it must be allocated as an ordinary PDS. This restriction is for z/OS SMS. The sample JCL that is provided to allocate a new, empty POSZPSWD data set allocates a PDSE.

There is no SMP/E TOSZPSWD target library (TLIB) that corresponds to this data set. Its contents (product authorization members) are created by the RTCS OSZPATLU batch utility program (or some other BMC product password management facility).

Because no BMC AMI Ops CAS-based product will ever reference the POSZPSWD library, sites that have only RTCS-dependent products installed (such as BMC AMI Ops CAS-based products) will not need to populate the POSZPSWD library with product license members. Such sites could, therefore, merely specify the DSNAME of any existing PDSE program library or PDS load module library (even one that contains no members), or allocate a new, empty PDS or PDSE that is to be used for the POSZPSWD library. For example, the DSNAME of the RTCS product program library (POSZLINK) could be specified in the RTCS initialization member as the DSNAME of the POSZPSWD library if it is desirable to avoid allocating even a one- track, empty PDS or PDSE library for this purpose.

Use member OSZINJ84 as a model to create a new, empty production RTCS Product Authorization Table library. This sample JCL allocates a new (by default, non-SMS- managed) PDSE library. The low-level index of the DSNAME selected for this production library should be POSZPSWD or OSZPSWD.

If you do not select a DSNAME prefix for this library that matches that of the RTCS subsystem program library or does not have the recommended low-level index, then the name of the data set that you create must be specified by the POSZPSWD option in the RTCS initialization member from the Logical PARMLIB data set used by the RTCS Initiator started task procedure, as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.

RTCS system registry—TOSZCNTL member OSZINJ80

The RTCS system registry is a VLDS that contains RTCS, z/OS system image, and BMC AMI Ops product configuration information that needs to be retained across IPLs and restarts of the CAS and certain product address spaces. Access to the RTCS system registry is managed by the RTCS subsystem address space, but the data contained in the system registry can be read and updated by all (appropriately authorized) address spaces.

Although you can use a separate, unshared, dedicated RTCS system registry VLDS on each z/OS system image, BMC recommends that you share a single VLDS for the RTCS system registry within each sysplex on which RTCS and BMC AMI Ops products will be used.

Access to the data contained in the VLDS is managed by the MVS Data-In-Virtual (DIV) service. As a consequence, the RTCS system registry VSAM cluster can be allocated by only one RTCS subsystem address space in a sysplex (because it must be allocated DISP=OLD). To enable sysplex-wide access to data in a shared registry VLDS, the RTCS subsystem address space that is the Local Owner of the registry VLDS uses the z/OS XCF facility to expose it to other address spaces on the sharing, Remote members in the sysplex.

Use member OSZINJ80 as a model to allocate a VSAM LDS cluster for the RTCS system registry, whether it is to be unshared and unique for any given z/OS system image, or shared among all system images in a given sysplex. The low-level index of the cluster name selected for the RTCS system registry should be REGISTRY.

Because it is dynamically allocated by the RTCS Allocator (OSZMOSYS, the first program to run in the RTCS subsystem address space), the system registry VLDS cluster must be cataloged. The catalog must be available when RTCS is started.

If you do not select a DSNAME prefix for this VSAM cluster that matches that of the RTCS subsystem program library or the DSNAME does not have the recommended low-level index, REGISTRY, the cluster name you define must be specified by the SREGVLDS parameter in the RTCS initialization member from the Logical PARMLIB data set used by the RTCS Initiator started task procedure, as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.

Note

This VSAM LDS cluster must be allocated so that the RTCS Subsystem can back up the primary RTCS system registry partition by using the DIV service. Because it is a VSAM cluster and is dynamically allocated to the RTCS Subsystem address space by the RTCS Allocator using only its cluster name (DSNAME), this library must be cataloged. The catalog must be available when RTCS is started.

To allocate a VSAM LDS cluster for the RTCS system registry

Select a VSAM LDS cluster DSNAME to be cataloged. Use the following considerations to determine what DSNAME to select:
- If you are not going to share the RTCS system registry VLDS sysplex-wide, select a VSAM LDS cluster DSNAME that will be cataloged in an image-specific catalog that is available when the system image is IPLed (such as the z/OS system image’s Master Catalog or a catalog that contains data sets that are referenced by critical system address spaces during IPL). The system registry VLDS can be cataloged in any catalog that will be available when the system image is IPLed.
- If you are going to share the RTCS system registry sysplex-wide, select a VSAM cluster DSNAME that will be cataloged in a shared catalog that is available to all sysplex members during IPL or when RTCS is started. Because the RTCS system registry sharing mechanism is XCF, it is not necessary for the VSAM cluster to be available from all members of the sysplex (only the one that will actually dynamically allocate it), but this would limit the number of systems that will be able to take over ownership of the system registry (for example, when the z/OS image on which the RTCS subsystem address space that does own the VLDS needs to be shut down for maintenance or re-IPLed).
- If you do not select a DSNAME prefix for this VSAM cluster that matches that of the RTCS subsystem program library or it does not have the recommended low- level index, REGISTRY, the cluster name you define must be specified by the SREGVLDS option in the RTCS initialization member from the Logical PARMLIB data set used by the RTCS Initiator started task procedure, as described as described by "RTCS Initiator—TOSZCNTL member OSZ$INIT" inAdd RTCS entries to system parameters.
The minimum amount of space you should allocate for the system registry VSAM LDS is 17,472 blocks (68.25 MB), which requires 98 cylinders on a 3390. The RTCS system registry is not likely to require more than 260.25 MB of space, even in very large configurations, so an allocation greater than 371 cylinders is pointless. For most customers, 98 cylinders of space is adequate.