Is the startup of CAMASTER mandatory?

Products

• COMMON SERVICES FOR Z/OS
• Common Services

Issue/Introduction

While it is understood that CAMASTER is a requirement of Common Services, and the failure to start CAMASTER will result is the failure for CAIRIM to successfully initialize, are there any plans to modify the design or will the initialization of CAMASTER continue to be mandatory? Are there any alternative methods of running CAMASTER? Can it be run as a subsystem?

 

 

Resolution

The simple answer to each question is NO. The CAMASTER address space is required.

In the IT business, the one thing that we can all agree upon is that every product on the market has some set of required components in order to function correctly. Common Services is no different and as such it too has required components that enable our services to function correctly, not only to satisfy potential requirements for other Broadcom products but also for our own services to function without error.

CAMASTER is one of those components that are required for Common Services to function. Take IBM as a comparison. Just as IBM requires *MASTER*, GRS, CONSOLE, ALLOCAS, etc. for their Operating System infrastructure, Common Services requires CAMASTER for our mainframe framework.

CAMASTER runs as a system address space. It cannot be started as a SUBSYS under IEFSSN. CAMASTER provides services to all Broadcom mainframe products including the security products, ACF2 and TSS. Because the security products initialize at a point in the IPL timeline before IEFSNNxx is processed, it is not possible to establish the CAMASTER services as a z/OS subsystem. Furthermore, there are many Broadcom mainframe products that have the ability to initialize as z/OS subsystems thereby the functions supplied by CAMASTER must be in place before being needed by this category of products or components.

One design consideration for creating a permanent CAMASTER address space is the exploitation of program call (PC) routines to eliminate the need for Broadcom products to define user SVC numbers. There is a limited number of SVCs that can be supported by z/OS. Furthermore, use of an SVC number typically requires installation specifications to identify a given SVC number to and for a product, either in the product's configuration options or in the IEASCVCxx member of PARMLIB. Exploitation of PC routines eliminates the need for installation configuration work as well as eliminates the constraint of limited SVC numbers.

As PC routines are bound to an active non-swappable address space by architecture, the need for the permanent CAMASTER address space is a requirement. For this reason, once the CAMASTER system address space has performed all necessary initialization, it enters a wait. No other task mode code executes in the CAMASTER address space as the home ASID after the wait to avoid any scenario that might bring down the address space. At this point, CAMASTER is more or less an anchor address space.

For additional details about CAMASTER, please refer to the Common Components and Services - CAMASTER Address Space.