RTCS components
RTCS services are established and maintained on each target z/OS image by a dedicated z/OS subsystem control address space.
This address space is intended to run under the Master Subsystem (MSTR) and remain active for the life of the IPL, but it can be started under the primary JES and shut down when desired, provided that there are no dependent address spaces still executing.
The RTCS infrastructure comprises the following 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. All code that is directly used by products is physically located in the kernel; references to code in the RTCS address space are not allowed. After the RTCS subsystem has been successfully initialized and the RTCS kernel has been loaded, RTCS services are available to applications and products that have been written to use the services. 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 certain z/OS resources. Other than responding to operator commands and remote requests for local system registry data, plus hardening any updates made to the system registry (which are infrequent), it is essentially idle, executing very little code. Products interact only with the kernel and not directly with the RTCS subsystem address space. Only operator commands that are directed specifically to RTCS (such as MODIFY) and RTCS system registry activity will cause any instructions to be executed in the RTCS subsystem control address space. Operator commands are normally only required when you want to start RTCS Generalized Server (product) address spaces or to control RTCS system registry operations. |
Subsystem address space | The main responsibilities of the RTCS subsystem address space are to initialize the kernel and to provide the point of ownership for certain z/OS resources. z/OS exits and cross-memory resources that are established by the RTCS subsystem are used by functions and code in other permanent z/OS system address spaces, which never terminate. Because these RTCS functions, z/OS resources, and the RTCS kernel code are normally expected to be available for the life of the IPL, the RTCS subsystem address space should not be shut down. Because the RTCS subsystem address space should not be stopped, starting it under any JES as a started task is not recommended. Instead, it should be started under the Master Subsystem by using SUB=MSTR on the START command. Because the RTCS subsystem address space should not be shut down after it is started, only a limited number of data sets are allocated to it. The RTCS system registry VSAM linear data set (LDS) is the only data set that normally remains allocated. The RTCS subsystem program library is a separate, dedicated SMP/E target library that is not shared by any other product. It is dynamically allocated by the RTCS subsystem address space and is deallocated after the RTCS kernel is initialized. The RTCS subsystem program library is required to be a partitioned data set extended (PDSE) program library. |
System registry | The RTCS system registry is a repository for configuration parameters, product definitions, and other typical PARMLIB-type data. The RTCS system registry can be seen as read/write auxiliary storage for the RTCS subsystem and all products that use the registry. Data in the RTCS system registry is accessed as if it were in virtual storage, but it is actually stored on DASD in a VSAM LDS. The RTCS system registry is managed and accessed much like an z/OS page data set, except that it is organized in a tree-like structure, similar to the Microsoft Windows registry. This structure speeds up the process of locating data in the registry because complex, self-defining structures can be stored as easily as a single byte or a string of characters. The RTCS system registry can optionally be shared with additional RTCS subsystems on other z/OS images in the same sysplex. In the shared mode, one of the RTCS address spaces becomes the local registry owner and manages all access to the RTCS system registry. The other RTCS address spaces become remote registry accessors and make requests to put data into the registry and to retrieve data from the registry to the local owner through an XCF communications pipeline. For more information about the RTCS system registry, see Understanding-the-RTCS-system-registry. |
Memory registry | The RTCS memory registry is not backed by a VSAM VLDS and is intended to retain information temporarily as long as the RTCS subsystem is available. All content in the RTCS memory registry is lost when RTCS is shut down or the z/OS system image fails. The RTCS memory registry cannot be shared. There is one for each RTCS subsystem on each z/OS system image. |
Product registry | The RTCS product registry is a repository for product-specific information. It is defined by the products and is optionally backed by a VSAM LDS cluster. All processing activity uses the same access techniques as the RTCS system registry, and like the RTCS system registry is organized in a tree-like structure. The RTCS product registry can optionally be shared with another copy of the product address space either on the same system or on a different z/OS image in the same sysplex. In the shared mode, one of the product address spaces becomes the local registry owner and manages all access to the RTCS product registry. The other product address spaces become remote registry accessors and make requests to put data into the registry and to retrieve data from the registry to the local owner through an XCF communications pipeline. |
Generalized Server address spaces | Code for products does not execute in the RTCS subsystem address space. Instead, products execute either in their own address space or are started by RTCS in an RTCS Generalized Server address space. A single RTCS Generalized Server address space can run multiple products, but all of the products in the address space must execute in the same protection key (keys 0 through 9 are supported). Multiple General Server address spaces might be started if products that execute in different protection keys need to be running at the same time. |
Related topic