The CICS systems programmer has a broad range of responsibilities that require many diverse skill sets, including architecture, engineering, network communications, database access, and application development.

The traditional role of systems programmers over time became focused on system administration functions. But, to extend the capabilities of CICS, the old-school, multi-role technician must reemerge and embrace the latest technologies. Although activities, such as defining CICS resources, analyzing performance, installing new releases, and applying maintenance, are essential to establishing and maintaining a stable platform, CICS systems programmers must take a technical leadership role in the organization. This leadership is not only critical in platform and middleware architecture, but equally important, in assisting application programmers with designing and developing services in a cloud-enabled environment.

CICS services are an entry point into the environment and make available IBM z/OS resources, such as IBM DB2®, Information Management System (IMS™), Virtual Storage Access Method (VSAM), and other CICS managed resources to applications across all platforms within your enterprise, and to the Internet and mobile clients.

This chapter provides insight from the experiences of Walmart’s CICS systems programmers who also filled the roles of architect, systems engineer, and software developer, to deliver a cloud model in a z/OS IBM Parallel Sysplex using CICS.

This chapter includes the following topics:

CICS adapted to the many different access channels that were introduced over the years: from 3270 and SNA to TCP/IP based protocols and APIs, such as IBM MQ, TCP/IP sockets, and HTTP. HTTP evolved from primarily providing HTML to delivering SOAP services that support SOA, to enabling ReST services, which widely support the cloud delivery model. Hosting the services in CICS within a z/OS Parallel Sysplex helps to enable the essential characteristics of the cloud delivery model, such as broad network access, resource pooling, metered service, and rapid elasticity.

The cloud services that were developed at Walmart were designed to be accessible from any platform or language via HTTP and ReST API calls. CICS resources for each user or service instance are created through provisioning services. The CICS resources that are required to support the services were identified by the service developer, while the automated provisioning services were created by the CICS systems programmer. In this case, the z/OS cloud services team at Walmart is composed of engineers that fill the roles of service developer and CICS systems programmer for the different services, which enables a DevOps environment.

The remaining sections of this chapter review the concepts and features that the CICS systems programmer uses to provide services that exhibit the essential characteristics of the cloud delivery model.

The concept of resource owning regions, such as terminal-owning regions (TOR), application-owning regions (AOR), file-owning regions (FOR), and queue-owning regions (QOR) provide high availability (HA) for CICS applications by using various input channels, such as 3270, SNA, and IBM MQ channels. More recently, CICS HA facilities were considerably improved through the provision of shared data facilities, such as VSAM record-level sharing (RLS), temporary storage (TS) server regions and coupling facility (CF) server regions. The result is that traditional FOR and QOR designs now have less relevance because it is possible to access shared data directly from AORs.

With services (whether SOAP, ReST, or cloud), two methods of resource owning configuration were considered.

The first method involves multiple web owning regions (WOR) and multiple AORs, where the WOR receives the HTTP request and a distributed program link (DPL) is issued to the AOR to run the program. Sysplex distributor and workload manager (WLM) provide HA to the WORs, and IBM CICSPlex® System Manager (CICSPlex SM) workload management provides HA to the AORs.

The second method includes multiple regions with combined WOR/AOR responsibility that Walmart refers to as service owning regions (SOR). Each SOR shares the IP endpoint, with TCP/IP port sharing and sysplex distributor providing HA with WLM to these regions.

The configuration that was selected to host the caching services and other services was the SOR model. This configuration reduced the number of CICS servers and the overhead of DPLs between WOR and AOR. It also reduced the number of calls to WLM.

An architectural view of the SOR configuration is shown in Figure 4-1. For more information about the supporting z/OS Parallel Sysplex configuration, see Chapter 5, “The z/OS systems programmer” on page 45.

To provide HA for Walmart cloud services, multiple SORs were defined within a cluster by using a common shared port that was assigned to each server in the cluster across the sysplex. The CICS resource definitions that were created to host this environment are listed in Table 4-1 on page 30.

The only mandatory parameters are TCPIP=YES and a TCP/IP service; however, consideration should be given to defining all of the other resources that are listed in Table 4-1 on page 30 to provide for more security and control.

Service resources are defined by automated processes when a consumer requests a service through a self-service provisioning portal that was developed by Walmart. The portal calls numerous CICS ReST services that drive the automation. The automation creates the resources by using standard EXEC CICS API and SPI commands and standard z/OS utilities, such as IDCAMS.

To share workloads, all logical components that comprise a cloud service must be defined in all CICS regions within a cluster. Whether through manual or automated processes, all resources for a service instance should be defined in their own (CSD) group, and then defined to the appropriate servers. Because the services are defined in individual groups, moving a service from one cluster to another (whether it is within the same LPAR, to a different LPAR, or even to a different sysplex) involves porting the group to the appropriate CSD for the new cluster and installing it in the servers.

The minimum resources that are required to define a CICS cloud or ReST service are URIMAP, TRANSACTION, and TRANCLASS, as listed in Table 4-2.

The URIMAP contains the path name of the URI and associates the CICS transaction and program that are to be run when the request is received by the TCP/IP service. The CEDA panel that is shown in Figure 4-2 shows the definition of the UC01 URIMAP definition, which is used to define the first instance of a service.

More URIMAP definitions are then used to identify further instances of each service with dedicated PATH and TRANSACTION attributes for each instance. Figure 4-3 shows the URIMAP definition that was used to define the second instance of the service.

The path name and transaction ID attributes in a URIMAP resource can be used to identify each instance of a specific service while running a common program. Identifying each instance of a service enables the metered and measured aspect of the cloud delivery model, and provides multitenancy within CICS servers.

Figure 4-4 shows the UC01 TRANSACTION definition for the first instance of a service. All service requests that use the UC01 URIMAP definition run under this transaction ID and are subjected to the scheduling constraints as defined in the TCLUC01 transaction class.

More transaction definitions are then used to identify further instances of each service that references a dedicated transaction class for the service. For example, transaction UC02 defines the TCLASS attribute as TCLUC02, as shown in Figure 4-5 on page 34.

 

 

Whether cloud or enterprise, CICS services enable applications across various channels access to the wide array of z/OS resources, such as DB2, IMS, VSAM, and all CICS managed resources. CICS applications and resources then become available to Internet, mobile, non-z/OS and z/OS consumers via standard HTTP requests.

 

Security is a critical consideration when z/OS resources are made available through CICS services because the service is an entry point into the environment. The scope of the network to which CICS services are made available has a significant bearing on how security (specifically, authentication) is implemented. Basic authentication might be sufficient when access to CICS services are protected by a DMZ (a perimeter network); however, extra security layers, such as IBM DataPower® Gateway Appliance, should be considered if the services are made available directly beyond the DMZ.

CICS supports HTTP and provides encryption at the transport layer (SSL/TLS) when requests are received on a port that is defined as HTTPS. Basic Authentication, when specified for a service instance or at the port level, is provided by calls to RACF. The user ID presented for basic authentication in the HTTP header can also assist with tracking resource usage for the measured service characteristics. For example, the MNR_ID_USERID field in the CICS transaction monitoring records can be used to identify resource usage by a user.

Although there are several methods for defining and assigning SSL certificates, the technique Walmart implemented uses a wildcard certificate that is defined to the ports in the CICS servers that are hosting their cloud services.

During the processing of the SSL handshake, the server verifies the common name in the Subject distinguished name (DN) from the server’s certificate with the host name of the server. If the common name and the host name do not match, the SSL connection is dropped. This issue is problematic in scenarios where a single certificate must be shared across multiple host names, such as used in DNS aliasing.

SSL wildcard certificates offer a solution to this issue by securing access to multiple subdomains underneath a single common subdomain by adding an asterisk (*) in the subdomain area to the left of the common subdomain name. For example, creating a DNS alias that uses a naming convention in which each consumer is assigned a unique subdomain name, such as user####, and a common higher-level subdomain that represents the service type, such as cache, a single wildcard certificate for *.cache.hostname.com can secure all cache consumers, regardless of which DNS alias they originally referenced.

This technique of wildcard certificates was used to secure the SSL TCP/IP services, as shown in Figure 4-6 on page 36 and Figure 4-7 on page 37 by using the CERTIFICATE attribute to refer to a certificate label in the SSL key ring that references a wildcard certificate for the relevant subdomain.

Walmart’s provisioning automation assigns the DNS alias and URL for each service by using the following naming convention:

This naming convention ensures that all instances of each service are given a unique consumer ID for each service type. For example, the first three cache instances that are provisioned would be assigned the following URLs:

In this case, all consumers of the cache service can be secured with a *.cache.hostname.com wildcard certificate.

Another z/OS cloud service that was created by Walmart is a key-value database service, which is assigned kvdb as the service type. For this service type, the first three instances that are provisioned would be assigned the following URLs:

In this case, all consumers of the kvdb service can be secured with a *.kvdb.hostname.com wildcard certificate.

For more information about how Walmart’s provisioning automation scheme assigns the DNS aliases and URLs for each server, see 4.6, “Network access” on page 42.

Basic authentication is one of the simplest techniques for security access controls to web resources. It is based on the use of user ID and password fields in the HTTP authorization header, which are base64 encoded. It supports machine-to-machine communication where credentials are pre-supplied on each request and user interaction by using a simple challenge dialog in a web browser to prompt for input credentials, as shown in Figure 4-8.

When a port is defined to CICS in a TCPIPSERVICE resource with the AUTHENTICATE attribute set to BASIC all services are required to provide user ID and password credentials, which are validated against RACF; otherwise, the request is rejected with an HTTP status code 401.

Service consumers in Walmart can request surrogate service IDs that include randomly generated passwords by using another service that is offered through the provisioning portal. The consumer can also choose to enable authentication and network encryption (HTTPS) as options when requesting a service instance through the provisioning portal.

When the TCPIPSERVICE resource is defined with authentication disabled on an HTTPS port, transport level encryption is still provided and requests are allowed to enter through the port with or without RACF credentials.

Basic authentication at the port level requires all requests entering through that port to provide credentials. However, this method lacks the required flexibility because the consumers require the ability to determine whether authentication is required for each service instance.

To provide flexibility and reduce the number of TCPIPSERVICE definitions, the Walmart cloud service disables basic authentication at the port level and enables security at the service level for all service types. To perform this function, a custom security program was developed by Walmart to extract the basic authentication credentials from the HTTP header, perform Base64 decoding, and call RACF to authenticate the credentials by using the EXEC CICS VERIFY command.

When a consumer requires access to the cloud service to be authenticated, the URIMAP CONVERTER field for the specific service instance is defined with this custom basic authentication program name BASEAUTH (see Figure 4-9 on page 40). When the credentials are authenticated successfully by RACF, control is given to the cloud service program; otherwise, an exception program is invoked that returns an HTTP status code 401.

Another level of security is provided by Walmart’s cloud services. When a service instance is provisioned for a consumer, a custom security definition resource is created in an external data store with a list of user IDs that can access this instance and the HTTP method level access authority for each user ID. After the custom basic authentication program completes, the cloud service program receives control and compares the RACF user ID and method from the HTTP header with entries in the custom security resource table. If the user ID and method combination are not allowed, the service returns an HTTP status code 401, as shown in Figure 4-10 on page 41.

The ability to host multiple instances of the same type of service creates a multitenancy environment that supports the cloud delivery model. An important and highly recommended approach is to establish naming conventions for all resources that form a cloud service, regions that host the services, and network DNS alias names. Developing a naming convention for services and related resources enables each instance of a service to be identifiable by a common identifier. For example, provisioning the first instance of a service that requires access to a VSAM file generates a group with a transaction, transaction class, file, and URI map, and other required resources, as shown in Figure 4-11.

Tenant isolation is provided within the cluster through adherence to a naming convention where the group name is part of the resource name. More instances of the service can be defined to the cluster by using a different identifier. For example, provisioning the second instance of the same service resources generates a group that uses the same naming convention but with a different unique suffix as shown in Figure 4-12 on page 42.

The DNS alias provides an abstraction that allows the target host name or system to be changed and workloads routed to different CICS regions loaded in alternate LPARs or sysplexes without the need for clients (consumers) to change their URL. This technique allows workload to be moved for various reasons, such as load balancing, service isolation, and disaster recovery.

Table 4-3 shows an example of a DNS alias scheme and the corresponding host names that resolve to the dynamic virtual IP address (DVIPA) endpoints in a z/OS Parallel Sysplex. The accompanying port number on the z/OS IP endpoint provides the entry point into the CICS region cluster, as defined in the TCP/IP service, and is mapped by a network load balancer.

This table shows how each service type maps to a dedicated port serviced by a cluster of CICS regions with a specific TCP/IP service. Then, how each consumer instance (such as user0001) is directed to the same TCP/IP service but isolated through use of dedicated CICS resources as described in 4.5, “Multitenancy” on page 41.

Figure 4-13 shows the resolution of a request for a cache service from the service consumer through the network into the CICS TCP/IP service and the specified CICS URIMAP and transactions.

The flow of control at each point is summarized in the following process:

The CICS systems programmer role must continue to evolve to provide a robust platform for modern applications.

The CICS systems programmers should keep current their knowledge of z/OS resources, database capabilities, programming languages, network communications, and the CICS platform.

Building relationships and communications with service consumers, service providers and z/OS support teams is essential in understanding how to design and build the appropriate landscape for enterprise and cloud services.