What is IBM Cloud Provisioning and Management for z/OS?

IBM Cloud Provisioning and Management for z/OS helps you rapidly provision z/OS software subsystsems, and simplifies the configuration and deployment of z/OS components. Use it to improve the agility of your DevOps team, integrate z/OS into your hybrid cloud, and transform your IT infrastructure.

With IBM Cloud Provisioning and Management for z/OS, you can create software service templates that provision IBM® middleware, such as IBM Customer Information Control System (CICS®), IBM DB2®, IBM Information Management System (IMS), IBM MQ, and IBM WebSphere Application Server (WAS). You can track software instances that were provisioned from those templates. Users can quickly provision and deprovision an environment as needed through a self-service software services marketplace.

For an interactive starting point, and access to a variety of resources related to IBM Cloud Provisioning and Management for z/OS, see Cloud Provisioning for z/OS.

z/OSMF and IBM Cloud Provisioning and Management for z/OS

IBM Cloud® Provisioning and Management for z/OS® function is available through IBM z/OS Management Facility (z/OSMF). z/OSMF provides system management functions:
  • In a task-oriented, web browser-based user interface with integrated user assistance, so that you can more easily manage the day-to-day operations and administration of your mainframe z/OS systems. By streamlining some traditional tasks and automating others, z/OSMF can help to simplify some areas of z/OS system management.

    The IBM Cloud Provisioning and Management for z/OS tasks in z/OSMF are Resource Management and Software Services, which are in the Cloud Provisioning category.

  • Through Representational State Transfer (REST) APIs, which are public APIs that your application can use to work with system resources and extract system data. The z/OSMF APIs allow for easy-to-use services that are language- and platform-independent, stateless, scalable, and easily parsed. For more information on the REST APIs for Cloud Provisioning services, see Cloud provisioning REST APIs.

Overview of IBM Cloud Provisioning and Management for z/OS

To provide access to the Cloud Provisioning function, a security administrator defines the IDs and roles that are required, such as the domain administrator (typically a middleware system programmer), network administrator, approvers, and consumers.

For an illustration of cloud provisioning, see Figure 1.
Figure 1. Cloud Provisioning Summary
The network administrator defines the cloud configuration, systems, ports, APPLIDs, and IP address. The security administrator authorizes administrator IDs, provisioning IDs, approval IDs, and consumer IDs. The Landlord creates the doman. The domain administrator creates tenants, and associates templates with tenants and resource pools The consumer runs templates.
The steps for setting up cloud provisioning are illustrated in Figure 2. More detail about the steps and the roles follows the figure.
Figure 2. Steps for cloud provisioning
Getting started steps

1. Define access and the landlord role (Security administrator)

A security administrator is responsible for the security of the cloud configuration, including defining the landlord role for the cloud domain (typically a z/OS system programmer). Sample jobs help to simply this task.

For more information, see Steps for setting up security

2. Process a request for a development environment (Domain administrator)

The domain administrator, typically a middleware system programmer, processes a request for a new environment, which might come from an application development team. This request starts the efforts to use cloud provisioning to make the environment available.

The domain administrator can take advantage of cloud provisioning to make environments available to a development team when they are needed, while the z/OS system programmer (the landlord, described in the next step) retains control over what is provisioned and how many instances are provisioned.

3. Optional – Define a domain (Landlord)

Software services templates are associated with a domain, which defines a system or set of systems. A domain can include systems from more than one sysplex.

A landlord, typically a z/OS system programmer, decides which system or systems (LPARs) are used for provisioning and creates a domain. If the domain extends beyond one sysplex, the landlord configures a primary z/OSMF system for communicating with secondary z/OSMF systems.

To help you get started quickly, a default domain is provided. The default domain is fully operational without any further configuration, and is accessible to any z/OSMF administrator. A default tenant is associated with the default domain.

When a domain includes more than one system, the domain administrator can specify:
  • The systems that are to be used as potential targets for provisioning
  • How the target system should be selected when the software service is provisioned: either automatically, by z/OSMF, or manually, by the consumer
  • That the instance can be relocated to a system in the domain other than the system it was originally provisioned on. The instance can run on only one system at a time.

For more information, see Managing domains, tenants, and resource pools.

4. Create a software services template and define the tenant for the line of business (Domain administrator)

To make an environment available to consumers as a software service, a domain administrator creates and configures a software services template. The template describes what is provisioned. For example, a template might request that a Db2® subsystem be deployed onto a z/OS system with three databases, or might create a set of CICS regions.

To provision the middleware, templates start and run z/OSMF workflows. A template includes a workflow definition file, along with other files, including a file that defines input variables for the workflow, and a file that defines actions that can be used against the provisioned software.

The domain administrator also defines a tenant for the development team, so that they can control how many instances of the software can be provisioned by that team, and the networking resources that they can use.

For more information, see Defining software services with templates.

5. Customize the template and connect the template to resources (Domain administrator)

The template might need to be customized for the installation – for example, to conform with naming standards in your company. You might modify variables that are input to the workflow, or use a properties file that is provided with the template to configure the provisioned software. For information about customization, you typically refer to documentation that is included with the template by the software provider. In addition, the domain administrator:
  • Adds the software services template to a tenant.
  • Connects the template to network, storage, and WLM resource pools. Resource pools are sets of z/OS resources that are required by the z/OS software service, for example, ports, IP addresses, or APPLIDs.

6. Create the pools of resources for the network and WLM (Network and WLM resource pool administrators)

When a template requires resource pools, for example, when you want to dynamically allocate ports to provisioned software instances, the network and WLM resource pool administrators (typically z/OS system programmers) use the appropriate z/OSMF tasks to complete the resource pools.

For more information, see Defining workload management resource pools and Defining network resource pools.

7. Approve the template

Offering self-service provisioning to a development team might require that some steps in the template, or certain actions, run under automation IDs. Any use of these user IDs in a template must be approved. Approval records are created for a template when a workflow or action definition file contains an element that identifies a user ID under which a workflow step or action is to be performed. (The workflow element is runAsUser ID, and the ID is sometimes referred to as a runAsUser ID). Approval records can also be defined for the template in general, and for a domain. Approval records must be approved by the approvers (typically identified by user ID) before the template can be tested or published.

For more information, see Approve a template.

8. Test and publish the software services template (Domain administrator)

The domain administrator tests the template to ensure that it successfully provisions the software, that is, creates the environment. Software that is provisioned from a template is known as a software services instance. (Note that this is different than a software instance that you manage with the Software Management task. A software instance is a collection of data sets containing installed software, and other data sets that may be associated with that installed software.) You manage a software services instance by using actions such as Remove and deprovision.

Publishing the template makes it available to consumers in the tenant – the application developers who require the new environment.

For more information, see Test Run a template and Publish a template.

Tailored Fit Pricing for IBM Z

You can define a tenant as a container for Tailored Fit Pricing for IBM Z by specifying a solution ID for the tenant. Then, any software that you provision for that tenant is treated as part of the solution. This approach simplifies the setup that is required for Tailored Fit Pricing for IBM Z, because the Resource Management task does the z/OSMF Workload Management work for you, including creating the tenant resource group, tenant report class, and classifications.