This chapter introduces the concepts of base sysplex and Parallel Sysplex for readers who might not be familiar with these environments. In particular, it describes the zPDT and AD/CD support for base and Parallel Sysplex.

The contents of the remainder of this document also is described.

This chapter includes the following topics:

Consider that you are in the supermarket, in the queue waiting to pay for your groceries. Then, the single cash register breaks down. You now have two choices: wait until they repair the cash register, or return your items to the shelves and go to another supermarket.

Now, take the analogy one step further. Consider that in our first scenario, each cash register had its own queue of people waiting to check out. When the cash register broke down, you move and join the end of the other queue. At least, you do not have to return all your groceries; however, all the people that joined the other queue after you are now ahead of you and are served before you.

But what if there was a single queue and the person at the top of the queue always goes to whichever cashier was available? All customers are served in the sequence in which they joined the queue. If the business does well and the number of customers in the queue starts to grow, the store can easily add another checkout as needed. At quiet times, the store can reassign one of the checkout assistants to another role. Despite the changes or failures, the customers do not get disrupted and they continue to get the best possible service.

This example shows the basic concepts of sysplex and why successful businesses use it: to avoid single points of failure, deliver high availability, and have the scalability to dynamically grow and shrink in line with their business needs.

You might be familiar with the terms base sysplex and Parallel Sysplex and wondered what is the difference between the two.

A base sysplex is a group of up to 32 z/OS systems that have a common time source and share a set of control data sets called couple data sets (CDSs). z/OS provides a software component called Cross Systems Coupling Facility (XCF) that makes it easier for peer programs in the sysplex to communicate with each other. XCF also provides management and monitoring capabilities.

Figure 1-1 shows the basic components that make up a base sysplex.

A Parallel Sysplex is a base sysplex that also contains one or more Coupling Facilities (CFs). CFs are special purpose logical partitions (LPARs) that provide for high-speed communication between z/OS LPARs. They also provide functions to actively share data with full data integrity and minimal overhead. They also provide the ability to have a single queue of work requests that can be shared and processed by multiple systems in the sysplex. Figure 1-2 on page 4 shows the components of a Parallel Sysplex.

Although a Parallel Sysplex contains only one extra component compared to a base sysplex (the coupling facility), that one extra component enables many capabilities that are not possible in a base sysplex. Because of this feature, more components are available in the z/OS systems that are shown in Figure 1-2.

Base sysplex provides the infrastructure with which you share things, such as your disk farm, performance policy (Workload Manager), and network access. This feature is often referred to as resource sharing. Base sysplex often is considered a stepping stone on the way to Parallel Sysplex.

Today’s business environment is brutally competitive. A large part of that competitiveness is a result of so much business being conducted online.

Thirty years ago, if you wanted to buy something, you drove to the local shopping center, found the item that you wanted to purchase, and brought it to the checkout. There was no easy way to determine how much you might pay for the item elsewhere. Even if price comparison was possible, you were unlikely to travel far just to buy one item. Therefore, you selected your item and waited in the checkout queue. If the cash register stopped working for 10 seconds, you were unlikely to jump back into your car and drive to another store to make the purchase.

Today, you go online to research the item that you are interested in, select the vendor that provides an acceptable level of service and price, click your item, and select “go to check out”. If you do not get a response within a few seconds, you abandon that purchase and go to the next website.

Enterprises that cannot provide continuously available service and short response times get into the death spiral of declining revenues, cost cutting (which makes the online service even worse), and further declines in income, which are followed by more cost cutting until the business is eventually taken over or closes down.

In this environment, the strengths of Parallel Sysplex (high availability and scalability) are more relevant than ever.

For software developers, a product that uses the capabilities of Parallel Sysplex can be much more attractive to prospective clients than one that does not. Rather than simply existing in the sysplex, a product that uses sysplex capabilities to contribute to the clients continuous availability requirements has real competitive advantages. However, developing such a product requires knowledge of the Sysplex Services Reference and a capability to test the new sysplex-supporting functions.

Many independent software vendors use zPDT and ADCD to develop and test their applications, but might not have the skills or experience to create a Parallel Sysplex environment of your own. These companies requested extensions to the previously available ADCD sysplex download that provide working examples of sysplex-specific functions, such as IBM CICS® Named Counters Server.

For application developers, the good news is that often there is nothing extra that you must do to get your application to work in a Parallel Sysplex. However, there are some things that an application should not do if it is to work well in a Parallel Sysplex environment.

We developed this package to enable mainframe customers and software developers to quickly and easily create a robust Parallel Sysplex that contains many examples of sysplex exploiters. Rather than many customers and vendors having to go through this process over and over, we hope that the base we provide means a significant time savings and encourages more customers and vendors to extend their support and use of Parallel Sysplex.

There are several target audiences that we believe can find value in this deliverable.

The first target is the software developer whose product uses Parallel Sysplex. People in this environment must test their functions to ensure that they work as expected. The Coupling Facility Control Code (that is, the “operating system” of the CF) that is provided with zPDT is the same code that runs on a real IBM z Systems™ mainframe. There are a few functions that can be performed on a real mainframe that are not possible with zPDT. However, generally speaking, zPDT can be used for developing and testing (including recovery testing) sysplex-exploiting products.

The next audience is application developers that use zPDT to develop programs for a production Parallel Sysplex environment. Before moving your application to the production environment, you want to test to ensure that the program is “well-behaved”. For example, it should not have any affinities to specific regions or subsystems or to other transactions.

One of the objectives of Parallel Sysplex is to improve resiliency. Therefore, if you have affinities to some resource in your code and that resource is not available, your application cannot be available. zPDT can be used to test your application to identify such affinities. zPDT does not provide the same level of activity and interaction between components that a test environment that is running on a real z Systems mainframe does, so we still recommend that pre-production testing should be carried out on a real mainframe.

Another audience is anyone that is interested in investigating the function and value of various Parallel Sysplex components. A good example might be IBM MQ Shared Queues. By using IBM MQ Shared Queues, you can place selected IBM MQ queues in a CF structure, meaning that they can now be accessed by all the members of the queue sharing group. If one IBM MQ is down, the messages can still be placed on (and retrieved from) the queue by any of the other queue managers. This feature provides a significant availability improvement; however, you might want to test this feature in an isolated test environment (zPDT) before implementing it in your real test or production systems.

The challenge of navigating changes through ever-stricter change management processes is becoming a real bottleneck in some environments. Given the real security concerns and risks, this concern is understandable. However, it does slow the evaluation of new functions and new products. Because zPDT is isolated from your real mainframe data (test and production), it should be possible to make a case to exclude your zPDT from change management. Also, because ADCD comes with many products and functions that are already installed and enabled, it might be possible to evaluate new functions in much less time and with less effort than implementing that function in a real mainframe z/OS system.

Consider the following differences between the previous zPDT sysplex support and the support that is provided by the zPDT 2016 Sysplex Extensions:

This publication includes the following remaining chapters:

There also are several appendixes that provide supporting information, sample JCL, and so on.