RTCS components
The following table describes the RTCS components:
Component | Description |
|---|---|
Kernel | RTCS runs as a z/OS subsystem. During initialization, the RTCS subsystem loads the RTCS kernel into above-the-line common storage area. All code that is directly used by products is physically located in the kernel. References to code in the RTCS subsystem address space are not allowed. After the RTCS subsystem is successfully initialized and the RTCS kernel is loaded, RTCS services are available to applications and products. Only one instance of RTCS can execute on each z/OS image. After the RTCS kernel is initialized, the RTCS subsystem control address space remains in the system as the owner of some of the z/OS resources. Products interact only with the kernel and not directly with the RTCS subsystem address space. |
Subsystem address space | RTCS functions, z/OS resources, and the RTCS kernel code are always expected to be available, therefore the RTCS subsystem address space must not be stopped. It must always start under the Master Subsystem by using the SUB=MSTR option on the START command and not under any JES as a started task. Because the RTCS subsystem address space must not be shut down after it has started, only a limited number of data sets are allocated to it. |
RTCS Subsystem SYSTEM Registry | This is a repository that holds data. For example, configuration parameters, product definitions, and PARMLIB data. The information in the registry is organized in a hierarchical tree like structure as shown in the following figure. This is similar to Microsoft Windows registry. The registry includes two basic elements – Keys and Values. The Key is also known as a Node. Registry Keys are container objects similar to folders. Registry Values are non-container objects similar to files. Keys may contain Values and Subkeys. Tree-structured repository
The registry can be shared with the RTCS subsystems on other z/OS system in the same sysplex. In shared mode, one of the RTCS address spaces becomes the local owner and manages all access to the registry. The other RTCS address spaces become remote owner and make requests to access and retrieve the data from the registry to the local owner through an XCF communications pipeline. For more information, see RTCS-Subsystem-SYSTEM-Registry. |
RTCS Subsystem MEMORY Registry | This registry is not backed by a VSAM VLDS and is intended to retain the information temporarily until the RTCS subsystem is available. All content in this registry is lost when RTCS is shut down or the z/OS system image fails. This registry cannot be shared. |
Product Registry | This registry is a repository for product-specific information. The registry is optionally backed by a VSAM LDS cluster. The data in the registry is organized in a hierarchical tree like structure. The processing of the RTCS Product Registry is similar to the RTCS Subsystem SYSTEM Registry. The RTCS Product Registry can be shared with another instance of the product address space either on the same system or on a different z/OS system in the same sysplex. In a shared mode, one of the product address spaces becomes the local registry owner and manages all access of the registry. The other product address spaces become the remote registry instance and make requests to the local owner to access and retrieve the data in the registry via an XCF communications pipeline. |
Generalized Server address spaces | Products run either in their own address space or in an RTCS Generalized Server address space that is started by RTCS. A single RTCS Generalized Server address space can run multiple products, but all the products in the address space must run in the same supported protection key (keys 0 through 9 are supported). If products that run in different protection keys need to be running at the same time, multiple General Server address spaces might be started. |
Related topic